文字コードの最近のブログ記事

拙著『プログラマのための文字コード技術入門』(技術評論社刊)の増刷が決まったとのことです。これで第7刷になります。年明け頃に出るそうです。読者の皆様はじめ、販売いただいている書店それにもちろん版元の技術評論社の皆様に御礼申し上げます。

電子書籍版もあり、PDFとEPUBが販売されています。紙の本でも電子書籍でも、お好きな方をどうぞ。

電子書籍版は第5刷がベースになっています。第7刷と違いはないはずです。

季節は年末。帰省のおともに、あるいは冬休みの自由研究に(?)、ぜひ「プログラマのための文字コード技術入門」をご活用ください。

第6刷のときとほぼ同じ文面になってしまいました。

先日テレビを見ていたら、人名の名字にJIS第3水準漢字が映っていました。

「野㞍」と画面に映っていました。「のじり」という名字だそうです。この「㞍」はJIS X 0213の第3水準、面区点番号1-47-63です。「尻」の異体字ですね。UnicodeではCJK統合漢字拡張AのU+378Dにあります。最初に作ったCJK統合漢字にはなくて後から追加されたということになります。

漢字において点の有無は別字になることもあればならないこともあります。単に運筆の調子を整えるために点を打つこともあるそうで、そういう習慣を知らないと特に意味のない形の違いで悩んでしまいそうです。今回の「㞍」がどういう経緯で成立したかは知りませんが、そうしたものの一種かもしれません。

JIS X 0208の幽霊漢字についてTwitterで興味深いツイートを見ました。

朝日新聞デジタルの記事で、JIS X 0208の出所不明の幽霊漢字「彁」らしく見える文字が大正12年の印刷物に見えたという話です。

内容について詳しくは記事(2011/09/05付)そのものを読んでいただければ良いのですが、備忘として概要をかいつまんで紹介しておきたいと思います。

JIS X 0208の幽霊漢字とは

JIS漢字コード規格JIS X 0208にはいくつか出所不明の漢字が含まれていて幽霊文字と俗に呼ばれています。拙著『プログラマのための文字コード技術入門』第3章にも説明しているので詳細は省きます。中でも55区27点の「彁」は手がかりがまるで存在しないものとして知られています。

新聞社の記事データベースでヒットした

この記事によると、朝日新聞社の記事データベースでキーワードに「彁」を含む記事がヒットしたということです。1923 (大正12)年2月23日付の朝日新聞朝刊に「埼玉自彁会」として入っていたとのこと。

リンク先には画像も掲載されています。文字がだいぶかすれていますがなるほどそのように見えます。

「彊」の誤認か

この記事で推測されているところでは、「自彊会」という言葉の「彊」の字がかすれて、データベースへの入力の際に「彁」として入力したのではないかということです。同じ記事のより良い状態の復刻版紙面を確認したところ、「彊」と読み取れたということです。画像を見ると確かに「自彊會」と見えます。

さらに記事では、JIS X 0208に「彁」が入ったのも同じ字のかすれたものを誤認したのが理由かもしれないという、ご存じ笹原宏之先生の推測を紹介しています。また、今後も同じ誤りが生じるかもしれないという懸念も示され、疑問があれば、もとの紙資料に立ち戻るべしとしています。

JISに入った理由が同じかどうかは決定的な証拠があるわけではなく推測の域を出ませんが、なかなか本当らしい説だと思えます。

(もし間違えることが多いならいっそのこと「彁」を「彊」の略体として採用するとなかなか愉快なのでは......とちょっと思いました。冗談ですよ!)

一昨日のことですが、中国・四国地方から文字化けのニュースがありました。IT系のメディアではなくNHKです。

Jアラートとは「全国瞬時警報システム」なのだそうで、最近北朝鮮のミサイル発射の問題のニュースに出てくることがあります。この緊急情報の送受信訓練で、メールでテスト電文を配信したところ文字化けして読めないものだったというニュースです。

上記リンク先には画像があり、携帯端末上で文字化けした文面が写っています。ぱっと見た感じでは、UTF-8のテキストをシフトJISとして解釈しようとしたように見えますが、冒頭の「発表」と末尾の「しまね防災情報」は見えています。前後の定型文がシフトJISで用意されていて、間に挟む本文もシフトJISでなければいけないところにUTF-8のバイナリを入れてしまったといった可能性が考えられます。

まあ、訓練で問題が見つかったのだから良かったとはいえるでしょう。プログラム自体は変えていなくても、そこに外部から与えるデータとして元々の想定とは異なるものを入れてしまったということもあり得るので、通しでやってみるのは重要なことです。

それにしてもIT系でない一般のニュースで「文字化け」という言葉を見るのはなかなか感慨深いものがあります。これをきっかけに拙著『プログラマのための文字コード技術入門』にも注目が集まる......かな?

ユーモラス、と言っていいのか分かりませんが、興味深いニュース記事がありました。

この記事の伝えるところによると、「「任●(にんきょう)団体山口組」(●は「侠」の旧字体)が、組織名を「任侠(にんきょう)山口組」に変更する通達を流していた」のだそうです。その理由として、「表記される際、「侠」の旧字体が正しく表記されないケースがあったことに不満を募らせたとみられる」と書かれています。

「「侠」の旧字体」は、当ブログ記事の題にあるように「俠」です。この字はJIS第3水準、面区点番号1-14-26にあります。人名用漢字にも入っています。

SKKの第3第4水準漢字辞書では「にんきょう」から「任俠」に変換できます。Macでも入力できます。もうこうした第3第4水準を避ける必要はないでしょう。

UTF-8のようなUnicodeの符号化方式で扱えるのはもちろん、JIS X 0213の符号化方式、EUC-JIS-2004Shift_JIS-2004で問題なく符号化できます。PythonやPHP, libiconvなどのコード変換はこれらの符号化方式に対応しています。

もっとも、上記のリンク先でもいまだに「●は「侠」の旧字体」のような読みにくい注釈を施しているのは残念なことです。JIS X 0213の全ての文字を扱えることがこれからの日本語処理の必須条件だという硬派な思想でビシッと筋を通して、第3水準漢字の組織名をいつでもどこでも使えるようにするのが良いのではないかと思います。

Java 9では国際化機構で用いられるリソース文字列のファイル表現の文字コードとしてUTF-8がデフォルトで使用されることになるそうです。従来、ISO/IEC 8859-1がデフォルトであるためにUnicodeエスケープが必要となり、外部ツールで日本語テキストを「\u3042」のようなエスケープ文字列に変換する煩わしさがありましたが、ようやく解消されることになります。

Javaには古くから国際化のための枠組みが用意されています。その最も基本的な機構となる、多言語のメッセージ文字列を用意する仕組みとしては設定ファイルなどに用いるプロパティファイルという形式が用いられています。ところがこのファイルはデフォルトの文字コードがISO/IEC 8859-1という西欧向けの1バイトコードなのでした。

このため、JDKではnative2asciiというツールが提供されて、Shift_JISやEUC-JP等の文字コードからUnicodeエスケープを用いる形式に変換できるようにされていました。また統合開発環境のEclipseにはプロパティエディタというプラグインが開発され、コマンド操作なしにあたかも直接漢字を記述できるかのような操作が可能になっています。とはいえリソースファイル自体はもちろんUnicodeエスケープなので、普通のテキストエディタで表示すると欧文以外は全く読めないものになります。

Javaのプロパティファイル自体はUTF-8で記述されても読み込めるように既になっていたのですが、その重要な用途である国際化のリソースファイルとして読み込むResourceBundleクラスではなぜかISO/IEC 8859-1がデフォルトという状態が長く続いていました。実は自分でクラスを定義して一工夫してやるとUTF-8にできるという裏技(?)もあったりしたのですが、そういうのはデフォルトで提供してほしいものです。(この辺のことは拙著『プログラマのための文字コード技術入門』第7章に記しています)

オープンソースのWebアプリケーションフレームワークであるPlay Frameworkではリソースファイルにわざわざ別の仕組みを用意してUTF-8で直に書けるようにしています。リソースファイルがもっと早くUTF-8で符号化できるようになっていたらこのような措置はとられれなかったかもしれません。

遅きに失した感はあれども、ともかく改善されることになって良かったです。

Unicode 10.0が2017年6月20日にリリースされました。今回は8,518文字が追加されています。

日本語話者にとって最も関係しそうなのは変体仮名の導入でしょう。

変体仮名とは

現在、平仮名は1音につき1文字ですが、以前は同じ音に対して複数の書き方がありました。例えば、平仮名の「か」は漢字「加」が元になっているもので、これ以外に「か」と読む平仮名はありませんが、かつては「可」を元にした仮名も使われていて同じく「か」と読まれました。そうした複数のバリエーションがあった仮名を明治時代に標準化したものが今の平仮名です。このとき採用されなかった異体が変体仮名と呼ばれるものです。

変体仮名は今日では文章を綴るのには使われませんが、そば屋の看板などで装飾的に用いられることがあります。

Unicodeにおける変体仮名

変体仮名はUnicodeではBMPでなく面01に配置されました。U+1B000-1B0FFのKana SupplementブロックおよびU+1B100-1B12Fの Kana Extended-Aです。例えば先ほど例に挙げた「可」に基づいた「か」は符号位置U+1B019にあり、文字名はHENTAIGANA LETTER KA-3とされています。読みを「KA」のように示して、複数ある異体は数字で区別されています。全部で285文字の変体仮名が収録されています。

符号化の方式としては、単純にひとつの符号位置にひとつの文字が対応する形になっています。複数の読まれ方をする字がありますが(例えば「惡」に基づく字、「あ/を」)、こうしたものもひとつの符号位置にのみ置かれ、読みが違うからといって重複して配置されてはいません。標準化の途中の段階では、音価に相当する符号位置を与えて異体字セレクタのようなもので変種を示すといった案もあったようですが、最終的には扱いやすい形式に落ち着いたことになります。

漢字の追加も

今回、CJK統合漢字拡張Fが追加されています。7,473文字と結構大きな追加です。使う機会があるかどうかはまた別の話ですが......。

拡張Fのコード範囲は2CEB0-2EBE0となっています。

Pythonとlibiconv, nkf, Javaのコード変換を比較した記事がありました。

ASCIIとJIS X 0201の違いに起因する円記号問題とチルダ・オーバーライン問題、それにUnicodeのFTPサイトが原因と思われる全角ダッシュの件という既知の問題が多いので目新しくないのですが (『プログラマのための文字コード技術入門』をお読みいただければわかります)、Pythonについて目新しげな話がありました。

Pythonでは他と違って、二重(白抜き)の括弧をU+FFxxの位置にあるものでなくU+29xxに割り当てているそうです。うむ。そうか、そうきたか。

JISの公式な対応表ではU+FFxxの方になっています。文字名でいうとFULLWIDTH {LEFT|RIGHT} WHITE PARENTHESISです。

ただ、ここで「なぜFULLWIDTHなのか」という疑問を持った方もいるでしょう。本来UnicodeのFULLWIDTH/HALFWIDTH云々というのは、シフトJISのように1バイトコードと2バイトコードとの間で重複符号化のある符号化方式との往復変換の救済用に設けられたものです。ところがこの括弧記号はJIS側の符号化方式(Shift_JISやEUC)で重複符号化されているものではないので、本来FULLWIDTHになるきちんとした理由はありません。にもかかわらず、UnicodeにJIS X 0213の文字を追加する作業でなぜかFULLWIDTHの方に入れてしまいました。

一般に用いられている変換表は、(多少ヘンだと思ったかもしれないにせよ)このUnicodeの作業を反映したものになっています。JIS X 0213の追補1でもそうなっています。Pythonのような判断をしたものは私はほかに見たことがありません。

Pythonがこうしたのは、強い信念のもとでの判断なのか、そうでなく何か行きがかり上そうなっただけなのか、ちょっと興味を惹かれるところではあります。

UnicodeにはのちにU+2E28, 2E29に{LEFT|RIGHT} DOUBLE PARENTHESISというのが追加されて(バージョン5.1らしい)、どうもこっちがいいんじゃないかという気もしてくるのですが、後から出してこられるのはつらい。3.2の時にあれば良かったのですが。

ちなみにこの二重の括弧は、文章や辞書において文中に入れる注記の類に用いられることのある記号です。

【追記 2017年6月7日】 JISとUnicodeの間のコード変換表はこちらから入手できます。JISの公式な定義と同等です: JIS X 0213のコード対応表

北海道南部の松前町は、20世紀日本の書家・金子鷗亭の出身地であり、その影響で書道教育の盛んな町として知られています。

その松前で高校生の書道パフォーマンスの大会が開催されたニュースがありました。

上記のうち、函館新聞の方は記事の中にちょっと残念な部分があります。書家の名前が「金子鷗亭」と、「鷗」の字がHTMLの文字参照になってしまっています。40407は16進表記で9DD7にあたります。UnicodeでU+9DD7は第3水準漢字「鷗」の符号位置です。

人手で40407のような数字を入力したとは考えにくい。私の想像ですが、テキストエディタなどで「鷗亭」と入力したあとで、工程上の何らかの段階でシフトJISに変換することがあったのではないでしょうか。その際に、第3第4水準漢字まで対応しているJIS X 0213Shift_JIS-2004ではなく、第1第2水準までしか対応していないJIS X 0208ベースのShift_JIS (ないしはその誤った実装であるCP932) に変換しようとして、このような結果になったのではないか。

SJISとの変換が必要な時には、Shift_JIS-2004 ないしは Shift_JISX0213 を指定すれば、こうした問題は起きなくなります。Python, PHP, Java, libiconv等を用いるとUTF-8とShift_JIS-2004との間でコード変換ができます。

この鷗(かもめ)という字は、常用漢字には入っていませんが、人名用漢字には入っています。文化的な分野ではこの金子鷗亭や森鷗外といった人名に使われますし、白鷗大学 (栃木県) という大学名や鷗島 (北海道江差町) といった地名にもあります。いつでも使えるように、第3第4水準漢字に対応した符号化方式 (第3第4水準文字コード) を常に用いることが肝心です。

なお、上記ニュース記事のもう片方、毎日新聞の方では、「鴎」という略字体を使っています。これはJIS X 0208の1983年改正で大きく字体の変えられたものとして有名ですが、元は新聞による使用の方が83JISよりも先だったのだそうです。その意味では、新聞がこの略字を使うのは一貫していると言えなくもない。ただ、表外字の部分字体にも略字体を適用しようとするなら鴎の一字だけでなく全ての表外字が対象になるのか、そうでないのなら鷗が適用対象になる理由は何なのかと、方針がなかなか難しくなってくるので、元来の字体 (鷗) にあわせるのが無難であろうと思います。

GNU libiconvはJIS X 0213の符号化方式、Shift_JIS-2004 (Shift_JISX0213) や EUC-JIS-2004 (EUC-JISX0213) に対応していますが、コマンドを実行した際にこれらが入っていない場合もあり得ます。入っているかどうかはiconvのコマンドラインオプション --list で確かめられます。

これらの符号化方式に対応するには、ビルドする際にconfigureのオプション --enable-extra-encodings を指定しておく必要があるようです。インストールされているiconvコマンドでShift_JIS-2004が使えないときはこれが指定されていなかった可能性があります。もしこれらの符号化方式が入ってなかったら、管理者に相談するか、そうでなければ、自分でソースをダウンロードして上記のオプションを用いてビルドしてみるのもいいでしょう。

SJISやEUCと変換するときは常にShift_JIS-2004, EUC-JIS-2004を使いたいので、これらに対応した iconv コマンドを用意しておきたいものです。

参考: GNU libiconv

最近のブログ記事

「2バイト文字」という言い方
「2バイト文字」という言い方につっこみを…
EUCが国際標準化されていれば良かった
すごい後知恵なんですが、1980年代に「…
酒で顔が赤くなる人の第3水準漢字:「酒皶」
日経新聞のサイトに気になる題の記事が載っ…
書家の第3水準漢字:「金子鷗亭」
書家・金子鷗亭の作品の特別展が北海道立函…
福原愛選手の結婚会見に見る台湾の言語事情、そして第3水準漢字
台湾語を使った結婚会見 リオ五輪でも活躍…

広告