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

25年くらい前に、MZ-2500というシャープから発売されていた8ビットパソコンがありました。この機種は8ビット機の割には漢字VRAMを登載していて、テキスト画面に漢字を表示することができました。フォントは内蔵のROMで提供されていて、JIS第1・第2水準が登載されていました。年代からいえば83JISだった筈です。

この機種には光栄 (現コーエー) から三国志のゲームが発売されていました。MZ-2500版のゲーム画面では、他の8ビット機版とは違って、メッセージが仮名漢字まじりの日本語で、それも通常の文字の大きさ(16×16ドットの正方形)で表示されていました。今となっては想像が難しいのですが、これは当時としては画期的なことです。大抵の8ビット機ではテキスト画面に漢字を表示できず、かつ、グラフィック画面は640×200ドットという縦長のドットになっています。そのため、16×16ドットで漢字を描画すると縦方向に2文字ぶんの長さをとる、縦長の字になってしまうのです。

したがって、通常のアルファベット等と同等のサイズの正方形で漢字を表示できるMZ-2500のゲーム画面は大変見栄えがしたものです。しかしこの三国志のゲームについては、人名だけが他機種と同じように縦長の字で表示されてしまっていました。「諸葛亮曰く、」というメッセージが表示されるときには、人名の「諸葛亮」だけが、縦に2文字分の高さをとる縦長の格好をしていたのです。当時の私にはその理由がさっぱり分かりませんでした。

後に理由を想像したところでは、MZ-2500に登載されているJIS第1・第2水準では、表記できない人名が三国志には多数あったのです。なので、テキスト画面への表示を諦め、人名だけは一律にグラフィックとして表示するという方法がとられていたようなのです。JIS X 0208に文字が足りないばかりに、光栄の人も苦労していたんだろうと思います。

という思い出話は前置きです。

当サイトの配布物のセクションに、JIS第3・第4水準漢字を用いる三国志人名リストというデータを公開しました。第3・第4水準の必要な人名の読みと漢字表記を並べたCSV形式のデータです。このデータの元になっているのは、おなじみ、SKKのJIS第3・第4水準漢字辞書です。

まだ検証の足りていない点もありますが、とりあえず公開してしまうことにしました。

NHKの歴史番組「歴史秘話ヒストリア」を見ていたら、JIS第3水準漢字が目に飛び込んできました。

幕末、薩摩藩の医師、「小田原瑞哿(ずいか)」という人名の「哿」です。面区点番号1-15-03、SJISでは8842です。この字は、聖徳太子の師とされる覚哿にも使われます。

番組の中では、西郷隆盛に関連して出てきました。

小樽オルゴール堂の写真

北海道に行ってきました。

今回、小樽や函館、江差といった海沿いの街を回ってきました。その際、食堂や食品売り場といった所で、JIS第4水準の「𩸽」(ほっけ、面区点2-93-44)という字を3回も見かけました。

別段文字を探しに行ったわけではないのですが、それでも3回も出会うということは、かなり頻繁に使われている字なのだろうと推測できます。

文字の写真を撮っていなかったので記憶が薄れているのですが、私の頭にあるところでは、1つは小樽の食堂に貼ってあったポスター、1つは函館のスーパーの食品売り場、もう1つはやはり何か食品の売り場であったと思います。

これまでのこのブログの記事にも例を色々挙げているように、第3・第4水準漢字は意外と身近にあるものです。もっともそれは不思議なことではありません。現代日本で現に使われていることを基準として第3・第4水準が決められたからです。

第3・第4水準漢字を符号化できる文字コードには以下のようなものがあります。

  • EUC-JIS-2004
  • ISO-2022-JP-2004
  • Shift_JIS-2004
  • UTF-8
  • UTF-16
  • UTF-32

一方、第3・第4水準漢字を符号化できない文字コードは以下のようなものです。

  • EUC-JP
  • ISO-2022-JP
  • Shift_JIS
  • Windows-31J

これからは常に第3・第4水準漢字を符号化できる文字コードを使うべきだといえるでしょう。

ちなみに今回函館では、通常は焼いて食べるホッケを、煮付けにしたものを美味しくいただきました。鮮度が良くないといけないので東京はもちろん札幌でもなかなかお目にかからないものです。やはり海の街は違いますね。

写真は小樽・オルゴール堂にて。

日経BP社のWebサイトのコラム「伊藤洋一の『BRICsの衝撃』」の「中国が内包する弱点----(3)"内部矛盾"が頻発させる学校襲撃」に、第3水準漢字を外字扱いして片仮名表記しているものがありました。

山東省の地名「濰坊」を「イ坊」と記しています。「濰」はJIS第3水準、面区点番号1-87-26で、EUCならF7BA、SJISならEC59というバイト値になります。

このページはEUCで符号化されています。JIS X 0213が普及していれば「濰坊」ときちんと表記できたのに、残念でした。

ちなみにコラムの内容は、中国ではこのところ立て続けに小学校を襲撃する事件が起きていて、その背景として所得格差の拡大があるというものです。

ISOの国際規格の一部を無料公開しているサイト(Publicly Available Standards)で、ISO/IEC 10646:2003の追補7が公開されました。10646というのはUnicodeと同等の国際標準です。この追補の発行は2010年7月15日付となっています。

この追補ではいくつも文字の追加がありますが、日本語に関係あるものとしては、新たに「Kana Supplement」というブロックが面01に追加され、2文字だけ、KATAKANA LETTER ARCHAIC E (符号位置U+1B000) と HIRAGANA LETTER ARCHAIC YE (符号位置U+1B001) というのが追加されています。

この2文字は、どうやらア行とヤ行の「え」の区別に関するもののようですが、私にはよく分かりません。元の提案者だという人のWebサイトもあったことを付記しておきます。

用意されたKana Supplementブロックは256文字分確保されています。今後、変体仮名でも入るのでしょうか。

電子メールはISO-2022-JPで符号化するというのが、インターネットで日本語をやり取りするようになってから長く続いてきた習慣でした。しかしISO-2022-JPでは使える文字が限られていて、問題があります。現代日本の文字にちゃんと対応するには、JIS X 0213の文字に対応する必要があるのです。

で、細かい背景や議論は拙著『プログラマのための文字コード技術入門』の第6章を参照していただきたいのですが、結論からいうと、ASCII + JIS X 0208の組み合わせで済む場合はISO-2022-JPで、それを超える範囲の文字(JIS第3・第4水準とか)を含む場合にはUTF-8を使う、というのが、最も受け入れられやすそうに考えられます。異論もあるかもしれませんが、ここではそういうことにしておきます。

この方針は、Emacs上のメーラのMewで実現できます。Emacsでは既にJIS X 0213の文字コードを扱う方法が確立されていますし、文字入力にSKKやAnthyを使うことで、JIS X 0213の全文字を自由自在に入力できます。そしてMewはそうした文字の送受信にも対応しています。

Mewで上記の方針の通りの動作をするには、以下のように、Emacs Lispファイルを書き換える必要があります。デフォルトでは後述するとおりちょっと違った動作になってしまうので、動作の定義を変更してやるのです。

Mewを構成するEmacs Lispファイル mew-mule3.el の中に、下記のような記述があります。

    ((ascii japanese-jisx0208 japanese-jisx0213-1 japanese-jisx0213-2)
                            iso-2022-jp-3 "7bit"             "B")

この2行目を、下記の内容に置き換えます。

	utf-8 ,mew-charset-utf-8-encoding ,mew-charset-utf-8-header-encoding)	

以上です。

この変更によって、JIS X 0213の文字が含まれる場合はUTF-8で符号化されます。①のような丸付き数字や♡のような記号、あるいは「氐」「𩸽」のような第3・第4水準漢字が含まれていたら、UTF-8で符号化のうえ送信されるということです。一方、ASCIIとJIS X 0208の文字しか使っていない場合には、従来どおりにISO-2022-JPが使われます。

mew-mule3.elに上記の変更を施さない場合には、JIS X 0213の文字があるとMewはISO-2022-JP-3で符号化して送信します。これはこれで正統なやり方ではあるのですが、残念ながらこの符号化方式を解釈できるメーラはごく限られます。現時点では、UTF-8にした方が読んでもらえる可能性は高まります。

UTF-8は8ビットのコードなのでContent-Transfer-Encodingが問題になりますが、私が試したところではbase64になりました。これは上記のmew-charset-utf-8-encodingという変数で決まるようです。

ちなみに、私はMew 5.2で試していますが、上記変更箇所は最新版6.3でも変わっていないようなので、同じ手順でうまくいくと思います。

最近、インドの通貨ルピーの記号のデザインがインド政府から発表されたというニュースがありました。例えば時事ドットコムの以下の記事。

この記事には記号の画像も載っています。

それを受けて、ISO/IEC 10646 UCS (Unicode)にこの記号を入れようという提案が早くも出ているようです。10646を作っている作業部会、ISO/IEC JTC 1/SC 2/WG 2のサイトの文書番号N3862にあります。

新興国の勢いのようなものを感じます。

テレビで放送していた映画「踊る大捜査線 THE MOVIE」を見ていたら、エンディングのスタッフロールにJIS第3水準漢字があるのが目に入りました。

「棈木」という人名の1文字目、棈です。面区点番号1-85-73です。EUCではF5E9、SJISではEB89になります。読み方は分かりません。あおきとでもいうのでしょうか。画面では旁の「青」が常用漢字体の青と同じになっていました。

JIS漢字字典には「棈木」であぶきという読みの人名が載っています。ただこの場合にどうかは分かりません。

昨日の記事に関連して、JIS X 0213の必要性を理解しない人がどうして出てくるのだろうと考えました。それでふと気付いたのは、JIS X 0208では文字が足りないということを理解していないのではないか、ということです。JIS X 0208では文字が足りないということに気付いていなければ、JIS X 0213が必要だという認識にも至らないのではないか。

JIS X 0208に文字が足りないというのは自分の中ではほとんど常識になっていたので、これは盲点でした。

以前97JISとJIS2000にかかわった人が書かれていたと思うのですが、1990年代に、JIS X 0208には文字が足りないから拡張できないかという話が出た。検討したところ、X0208に手を入れて変更するのは良くないという結論になって、別規格として上位互換のX0213を作ることになったと。つまりX0213というのは実質的にX0208の改正のようなものであるわけです。

X0208に文字が足りないというのはだいぶ前からの了解事項であって、X0213によってその問題はほぼ解消された、ということです。ここ重要なので繰り返します。

  • JIS X 0208には文字が足りない。
  • その問題は、JIS X 0213によってほぼ解消された。

「ほぼ」というのは、特に漢字についてはあくまでも「ほぼ」なのですが、コストとの兼ね合いでどこかで線引きしないといけないので、ある程度割切りが必要です。

実際にどんな文字が足りなくてX0213で追加されたのかは、『プログラマのための文字コード技術入門』をお読みいただければいいと思います。

ここでいう文字とは、現代日本で使われている普通の文字のことなので、従来の文字コードと分け隔てなく扱えることが重要です。だから、JIS X 0213では、SJIS、EUC、ISO-2022-JPという、従来の符号化方式によって符号化できるよう設計されました。

したがって、「X0213はUnicodeで実装します。従来の文字はWindows-31Jで扱います」というのは不適当なのです。これでは、X0213で追加された文字をいつでもどこでも扱えるようにはなりません。

なぜかというと、この方針では依然としてWindows-31Jのみを使う場面が残ってしまい、そのときはX0213で追加された文字は扱えないからです。いわば、Windows-31Jに含まれる文字が一級市民で、アイヌ語用片仮名などは二級市民扱いになってしまうということです。これでは駄目です。そしてこれは現に起こっていることです。

だいたい、「X0213はUnicodeで実装します」というのなら、Windows-31Jの文字だってUnicodeで実装すればいいということになるではないか。筋の通らない話です。

今後はUnicodeの使用が増えていくことでしょう。しかし、依然としてEUCやSJISといったJIS系の符号化方式が便利な場面も残る筈です。そのとき、EUC-JIS-2004やShift_JIS-2004を使えば現代日本の文字をきちんと扱えるというのが、JIS X 0213の利点なのです。そしてこの利点を、私を含め一部の人々は既に享受しています。

朝のNHKニュースを見ていたら、字幕に「活痧」(かっさ)という字が出ていたのが目を引きました。「痧」なんて字はJIS X 0213にあったろうかと思って調べたら、第4水準、面区点番号2-81-51にありました。さすがです。

「活痧」自体が何なのかは忘れてしまいました。この字幕が出た後で顔のマッサージのような動作が映っていたので、そういうことに関係する言葉なのだと思います。Webを検索してみると、字が少し違って「刮痧」という言葉が出てきます。これもやはりマッサージに関係があるようです。

JIS漢字字典』でやまいだれの部首を眺めていると、第3・第4水準は「こんな字もあるのか」といった見慣れない字が並びます。もちろんこれはやまいだれに限らないのですが、なぜかやまいだれについてはその感を強くします。

最近のブログ記事

全角と半角について誤解している人
少し前のことですが、拙著『プログラマのた…
MySQLの"UTF-8"にご用心
拙著『プログラマのための文字コード技術入…
卓球ニュースの第3・第4水準漢字
世界卓球のニュース記事に、JIS第3・第…
ゴルフニュースの第3水準漢字
女子ゴルフのニュース記事にこんなのがあり…
冗長なUTF-8を試す: iconv, nkf、その他は?
拙著『プログラマのための文字コード技術入…