タグ「Unicode」が付けられているもの

それをIVSと呼ぶのか

Unicodeの「IVS」というものの普及を目指す協議会が設立されたというニュースが出ていました。例えば、ITmedia Newsの「「書き手と読み手の字体の一致」を保証する「IVS」普及へ、MSやアドビなど協力」などの記事があります。

内容以前に気になったのが、IVS という用語の使い方。Ideographic Variation Sequenceという名のとおり、これはsequenceを表す言葉です。どういうsequenceなのかというと、UnicodeのCJK統合漢字の後ろにU+E0100のような符号位置 (variation selector) を付けたものです。これによって漢字の異体字 (とひとまず呼んでおくが、異体字というより活字のデザイン差程度のものが多い) を示すものです。

つまり例えば 「U+4E08 U+E0100」 のような列のことを本来はIVSと呼ぶわけです。

ただし、「variation selectorによってCJK統合漢字の形のバリエーションを示す技術」のことも(便宜的に?) IVSと呼ぶことがあって、上記記事の見出しではこの意味で使われています。

細かいことをと言われるかもしれませんが、これはちょっと気持ち悪いなあと思います。

私の本では、これをどう書くか迷った結果、「異体字セレクタ」という言葉で表しておきました。同書ではIVSという言葉は、上記のごとく、「U+4E08 U+E0100」のような(sequence)を表すものとして使っています。でも私の主観としては、それを書いた後くらいから、IVSという言葉で「variation selectorを使う方式」のことをも示す言い方が広まってきたような感じがします。ううむ。

まあ、あまり気に病むようなことではないのでしょうか。そんなことよりも、IVSが本当に使いものになるのかどうか、運用上の問題はどうか、などを気にした方がいいのかもしれません。

改定常用漢字表と文字コード

改定常用漢字表がこの11月30日に内閣告示されました。それと同時に、経済産業省からは、「改定常用漢字表に対するJIS漢字コード規格の対応状況について」という発表が出ています。常用漢字表の改定に文字コードがどう対応しているかをまとめた資料です。

詳しくはリンク先の資料、特に「改定常用漢字表に関する規格検討報告書」というPDFを読むと良いです。

私なりに超簡略化していうと、文字コード的には、

  • JIS X 0213を使っていればオッケー。
  • JIS X 0208は大体いいけど一部の文字に字体の問題がある、

というところです。

JIS X 0213の符号化方式に対応したソフトウェアでは改定常用漢字表の文字は何の問題もなく扱えます。また、JIS X 0213の例示字形に則って設計されたフォントは字体上の問題もありません。

JIS X 0208にしか対応していない場合に文字コード的に問題になるのは何かというと、「塡」「剝」「頰」「𠮟」の4文字です。これらが、JIS X 0208ではそれぞれ「填」「剥」「頬」「叱」という字体になってしまう(「互換包摂」まで適用すればX0208の包摂規準で救済できるけど、JIS X 0213ができてから10年も経っているのに互換包摂というのも残念な感じが強い)。改定常用漢字表ではこれらX0208の方の字体でもいいことになってはいるのですが、表に掲出されている字体としては第3水準の方の「塡」「剝」「頰」「𠮟」であるわけです。

「𠮟」については、『プログラマのための文字コード技術入門』にも書いたとおり、Unicodeで表したときにBMPでなく面02の文字であるという点が、多分いろいろな問題を依然として引き起こすと思います。UTF-8として3バイトまでしか対応していないMySQL 5.1とかを使っているとその時点で駄目です。そういう問題があることが意識されてかどうかは知らないけれど、改定常用漢字表では「𠮟」と「叱」は「特定の字種に適用されるデザイン差」ということになっています。他の字種に一般化することのできない個別のデザイン差ということです。この種のデザイン差は5字種について挙げられているのですが、中でも「𠮟・叱」については、「本来別字とされるが、その使用実態から見て、異体の関係にある同字と認めることができる」というただし書きまである念の入れようです。

経済産業省によると、「常用漢字表の改定を契機に今後一層JIS X0213が普及することが期待されます」だそうです。そうなると本当にいいですね。それはひとり常用漢字表のためだけではありません。先日述べた仏教の用語の件もあるし、アイヌ語の件もあるし、地名の件もあるし、その他このブログで度々取り上げている様々な文字への対応も含めてのことです。

iOS 4.2でチベット語

iPhoneやiPod Touchに最近配信されたiOS 4.2では、チベット語の扱いが改善しました。

チベット語はチベット文字で書き表します。チベット文字はインド系の文字の一種であり、ベースとなる文字の周囲に記号を付ける、複雑な構造をとります。Unicodeでチベット文字を扱うには文字合成の処理が必須です。

以前のiOSでは確かチベット文字の合成ができていなかったと思うのですが、4.2ではきちんと合成されて表示されます。

ソフトウェアキーボードも用意されています。設定画面から、各国語のキーボードを追加する機能の中に、チベット語もリストアップされているのです。チベット語を選んで追加してやると、チベット文字の入力が可能になります。

UTF-8で符号化されたチベット語のウェブページとしては、ダライ・ラマ14世のチベット語のホームページがあります。チベット文字の表示を試しに見てみるのに使えるでしょう (読解できるかどうかは別にして!)。また、日本語のブログ「チベットNOW@ルンタ」には、時折チベット文字が(HTMLの文字参照の形で)使われることがあります。

IVD更新

最近、Unicodeのいわゆる異体字セレクタの新しいグリフコレクションが登録されました。今までは、Adobe-Japan1というコレクションが登録されていたのですが、今回それに加えて汎用電子と呼ばれる日本の政府関係から提案されていたコレクションが追加されました。追加されたコレクションは、異体字データベース (Ideographic Variation Database; IVD) に累積的に追加されています。

IVDの文字表をちょっと見ると分かることですが、Adobe-Japan1と汎用電子とで、どう見ても同じようなグリフに対して別々のIVS (Ideographic Variation Sequence; IVS) が割り当てられています。例えば、「与」(U+4E0E)を見ると、Adobe-Japan1は長い横線の突き出ているグリフと突き出ていないグリフとにそれぞれ別のIVSを割り当てていますが(それぞれU+E0100とU+E0101)、同様に汎用電子も同じグリフ (としか見えない) に、それぞれU+E0102とU+E0103を割り当てています。

これは、IVDの技術仕様 (UTS #37)において "The Ideographic Variation database ensures that a given variation sequence is used in at most one collection" (IVDはあるIVSが高々1つのコレクションにおいて使われることを保証する。引用者訳) と書かれているのでそんなものかと思うのですが、これがどう運用されることを念頭に置いているのかがいまひとつ分かりません。

考えられるのは、IVSを利用する場合はどのコレクションに従ったIVSを使うのかを事前に決めておくということです。自分はAdobe-Japan1を使うんだ。あるいは、汎用電子を使うんだ。ということを予め決定しておく。IVD全体ではなくひとつのコレクションのみを相手にするということです。UTS #37を読むとそういう前提があるような雰囲気が漂っています。そうでないと、「『与』の横線が突き出ていないグリフ」を指定しようとしたときにどのIVSを使えば良いのかが決定できないことになってしまいます。

そうすると、次の疑問として、「基本的にAdobe-Japan1を使うつもりなんだけど汎用電子に良さそうなグリフがあったらそっちも使いたい」というような運用はありやなしや、ということが出てきます。そういうことについてUTS #37は何も言っていないのですが、まあ、お好きにどうぞということなのかもしれません。

IVSは、文字の符号化というよりも字形出力の微調整のようなものという位置付けであることが、今回のIVD改訂ではっきりしたように思います。UTS #37にも "variation selectors are default ignorable" と書いてあるので、テキスト処理上は異体字セレクタを無視してベースのCJK統合漢字だけで処理され得ることになります。そうでないと検索などで不都合が生じそうです。

もっとも、IVSを何も意識しないプログラムは、IVSを無視するなんていう処理が入らないので、もし本当にIVSを使おうとしたらこの先いろいろトラブルがありそうだなあという予感がします。

IVSは全般に、どのように運用されるべきかが曖昧な感じがします。あと、登録されているコレクションが今のところ日本関係のものしかないのだから、仕様書の日本語版も提供してくれればいいのにという気もちょっとします。

先週まで川崎市民ミュージアムで開催されていた、「アイヌ 美を求める心」という、アイヌの工芸品の展示を見てきました。

アイヌの衣類や生活用品、工芸品等の、美術的な側面をとりあげた展示です。

いかにもアイヌらしい模様の衣類をはじめ、生活に密着した品物や、儀式のときに使う物、本州からもたらされたものを利用した物、など、様々な展示物がありました。

展示品には片仮名書きのアイヌ語で名称が記されています。したがって、この展示はJIS X 0213の必要性が強く認識できる展示でもありました。

この企画展のチラシから一部抜粋した画像を掲げましょう。これだけでも一端が伺えるというものです。

アイヌ工芸展のチラシの一部

この小さな画像だけでも、異なり字数で10字、総計12文字も、JIS X 0208になくJIS X 0213で追加された文字があります (丸付き数字も数えています)。なお、④のところに小書きの「ㇵ」があるのが目を引きます。これはアイヌ語の中でも樺太方言の表記にしか使われない字です。この展示には樺太アイヌの物も多く出ていたので、あまり見かけないこうした字も出てくるわけです。

この展示で印象的だったことの一つに、現代のアイヌ工芸の作品があります。21世紀になった今でも、アイヌ工芸は受け継がれて、新たな作品が産み出されているのです。その中にはアイヌの伝統的なものもあれば、新たな発想で作られた必ずしも伝統的には見えないものもあるといいます。また、北海道ではアイヌ語のラジオ講座が放送されるなど、アイヌ文化を継承する動きがあることが紹介されていました。アイヌ語は母語話者が消滅の危機に瀕している一方で、それを受け継ぐ努力もなされているのです。

そうしたことから、『プログラマのための文字コード技術入門』の著者として考えることは、アイヌ語は日本において現代そして未来に生きる言語であり、それを表記するための文字は現代・未来の日本に欠かせないものだということです。JIS X 0213がアイヌ語表記用の片仮名を収録したことは100%正しい判断であり、画期的な功績である。そしてインプリメンタはその判断を正しく理解し、アイヌ語用の文字を扱える文字コードを実装しなければならない。アイヌ語に敵対的な間違った実装であるWindows-31J (CP932)を排し、UTF-8、Shift_JIS-2004、EUC-JIS-2004といったAinu-friendlyな文字コードを使うことは我々の義務である。ただしUnicodeの場合には結合文字の処理がちゃんとできなきゃ駄目(なぜなら、「ㇷ゚」の問題があるから)。そういうことなのです。

Unicode 6.0.0

Unicode 6.0.0が発表されました。

日本の利用者にとって最も影響が大きいのは携帯電話の絵文字の収録でしょうか。『プログラマのための文字コード技術入門』に書いたとおり、多くの絵文字はBMPでなく面01に入っているので、UTF-16ではサロゲート・ペアの、UTF-8では4バイトのUTF-8への対応が必須です。Unicode対応を謳いながらこれらの機構に対応していない時代遅れのプログラムは改善が必要です。

ただ、Unicodeに絵文字が入ったからといって、それを張り切って使うのが本当に良いことなのかどうかは、文字コード以前の問題として、考えられるべきではないかと思います。「絵文字」というものの、それは言語表記に用いる文字ではなく、ただの絵にすぎません。文章の中に絵を散りばめるのは、文章力のなさを非言語的なシンボルによる印象で糊塗しようとしているだけではないのかという疑いを消すことが私にはできません。

さて、新規追加の漢字としては面02にCJK統合漢字拡張Dというのが追加されています。ブロックはU+2B740〜U+2B81Fです。これらを使う機会はほとんどの場合ないでしょう。コード表を見ていると、書体の違いや書き方の癖のようなものを無理矢理明朝体化したようなものが見受けられ、Unicodeとしてどういう基準で収録しているのか疑問を抱きます。例えば、U+2B746は「今」という字の手書きの書体でよく見られる形でしょう。岡山県の倉敷美観地区にある今橋という橋(大原美術館のすぐ前)に彫られている「今」という字はこの形です。康煕字典の(康煕字典体ではなく楷書で書かれている)序文の「今」もこの形だといいます。ほかにも沢山あるでしょう。「解説 字体辞典」を見ると、「今」の伝統的な楷書の形であることが分かります。こうしたものに別のコードを振るというのが本当に適切なのか疑問に思います。

前に少し記した、インドの通貨ルピーの記号も早速入りました。U+20B9です。

バージョン6.0.0での変更点はUnicodeコンソーシアムのWebサイトから見ることができます。

辞書サイトの発音記号

英和辞典などを提供しているウェブサイトで、発音記号の表記をどのように行っているか、気になりました。ある程度Unicodeの文字を活用しているかと思えば、文字によってはなぜか画像を使っていたりと、どういう方針なのかが見えづらいのです。

例えば、Yahoo!辞書の英和辞典では、ASCIIで表せる以外の発音記号はほとんど画像に頼っているように見受けられます。試しにalthoughなんていう言葉をひいてみると、[ɔːlðóu] と発音が記されているうち、l と u 以外は全部画像です。ただ、thoughtをひくとthの音にあたる記号がθで記されています。これはギリシャ文字シータで、JIS X 0208で表せるので使っているものと想像できます。してみると、ASCII + JIS X 0208で表せるかが、文字か画像かの基準となっているのかもしれません。ちなみにYahoo!辞書のウェブサイトの文字コードはUTF-8です。

これがgoo辞書になると、画像に頼らず文字として表している程度がもう少し高くなります。例えば、compassionという語をひくと、ASCIIにもJIS X0208にもないǽが文字で表されています。ただし、əやʃは画像を使っています。また、先に例示したalthoughについてYahoo!辞書と比較すると、ðとóを画像でなく文字にしているところが違います。ただし、ɔːはやはり画像です。この辺の、画像か文字かの分かれ目がどこにあるのか、goo辞書については私には見出せませんでした。

goo辞書もYahoo!辞書も、文字コードはUTF-8です (ちなみにInfoseek辞書はEUC-JP)。せっかくUTF-8を使うのなら、Unicodeにある発音記号を使えばもっとすっきり綺麗に表示できるのにと思います。Unicodeのどこまで対応すればいいか分からないというなら、JIS X 0213にある文字という基準で対応すれば、大体の用は済むはずです。

北海道で見た第4水準漢字

小樽オルゴール堂の写真

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

今回、小樽や函館、江差といった海沿いの街を回ってきました。その際、食堂や食品売り場といった所で、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水準漢字を符号化できる文字コードを使うべきだといえるでしょう。

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

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

ISO/IEC 10646:2003 Amd. 7 無料公開

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でも変わっていないようなので、同じ手順でうまくいくと思います。

Anthy用辞書 更新

先月公開したAnthy用JIS第3・第4水準漢字辞書を更新して第0.2版としました。Anthyをお使いの方は試してみていただけると嬉しいです。

この版では、(c)から©が変換できたり、あるいは ! から ¡ が、(1) から ❶ が、といったように、仮名文字以外の記号・英数字から変換できる語彙が多数含まれています。非漢字の入力のバリエーションが増えているということです。

また、SKK-JISYO.JIS2004の内容をマージしているので、JIS2004で追加された所謂「表外漢字UCS互換」の10文字も新たに変換できるようになりました。ただし相変わらず用言には対応していません。

インドの通貨ルピーの記号

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

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

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

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

JIS X 0213の必要性

昨日の記事に関連して、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の利点なのです。そしてこの利点を、私を含め一部の人々は既に享受しています。

先日、「iPod Touchの漢字変換はJIS X 0213の成果を取り入れていた」という記事を書きました。JIS X 0213の文字が単語として入力できるという話です。このときは、てっきり、iPod Touchは (iPhoneも?) JIS X 0213の文字全部に対応しているのだと思っていました。

ところが、昨日のブログ記事紹介したページをiPod Touch (第2世代) で見てみたら、一部の文字・記号に、表示できていないものがありました。

例えば、将棋の駒の記号☗☖や、白抜きの丸付き数字の⓴、二重の丸付き数字⓵・⓾は表示できていませんでした。また、Unicodeでは合成の必要な文字、か゚やセ゚などは、半濁点の部分が間延びして表示されています。

iPod Touchのフォントはどういう基準で文字を揃えているのか、ちょっと不思議に思いました。

やはり、JIS X 0213の文字はいつでもどこでも使いたいものですね。

MySQLの"UTF-8"にご用心

拙著『プログラマのための文字コード技術入門』にも一言だけ書いたのですが、オープンソースのデータベース管理システムとして有名なMySQLのバージョン5.0とか5.1とかは、UTF-8として3バイトまでしか対応していません。

これは今どき考えられないくらい古い仕様です。3バイトのUTF-8というのは、Unicodeの基本多言語面(BMP) という、16ビット固定で世界中の文字を符号化するんだと(誤って)言い張っていた、古き良き時代のUnicodeの範囲しか扱えません。

MySQLの5.5.3というバージョンではようやく4バイトのUTF-8への対応が図られたようです。5.5.3の変更点を記したページに記されています。

これを使えば、魚の名前の𩸽(ほっけ、U+29E3D)だとか、偏旁の𧾷(足偏、U+27FB7)だとか、あるいは日本の地名として𣖔木作(ほうのきざく、福島県)の「𣖔」(U+23594)や𣗄代(たらのきだい、山形県)の「𣗄」(U+235C4)などといった、JIS X 0213に含まれる漢字がようやく扱えるようになります。一部の人が希望しているであろうIVSや(今後のバージョンのUnicodeに入る予定の)携帯絵文字に対応するにも4バイトのUTF-8は必要です。

ただし、文字コードの指定として、従来の "utf8" とは別に、"utf8mb4" という名前を持つ別の文字コードとして定義されているようなので注意が必要です。

ちなみに、同じくオープンソースのDBMSであるPostgreSQLは、既に4バイトのUTF-8に対応しています。それだけでなく、JIS X 0213の符号化方式のEUC-JIS-2004やShift_JIS-2004にも対応しています。

拙著『プログラマのための文字コード技術入門』で説明した、冗長なUTF-8の問題についての話です。

拙著p.168では、iconvとnkfについては、冗長なUTF-8がチェックされ、そのまますり抜けることはないことを記しておきました。ではiconvやnkfのようなコード変換以外のプログラムではどう扱われるかを、少し検証してみます。

拙著p.168に記した方法で、冗長なUTF-8のファイルを作成し、いろいろなプログラムに(適宜UTF-8を指定のうえ)読み込ませてみました。読み込ませるファイルは「!」という文字を冗長なUTF-8で表現したものです。

以下に調査結果を記します。ファイルが文字「!」として認識されなければOKです。つまり、「不明な文字となる」や「表示されない」というのは妥当な動作です。使用したソフトウェアにはバージョンの古いものもありますがあしからずご了承ください。また、本当に冗長性への対処を保証したい場合は、ここに記している結果を鵜呑みにせず、必要に応じて自分で調査することをおすすめします。

Ubuntu Linux 9.04上のソフトウェア:

Firefox 3.0

不明な文字となる。

Firefox 3.5

不明な文字となる。

GNOME端末 2.26.0

不明な文字となる。

Eclipseのエディタ

不明な文字となる。

mlterm 2.9.4

表示されない。

gedit

開けない (UTF-8として認識されない)。

Emacs 22

「!」という文字になる。編集してセーブすると、正しい(冗長でない)UTF-8のバイト列になる。

OpenOffice.org Writer 3.0

「!」という文字になる。編集してテキストとしてセーブすると、正しい(冗長でない)UTF-8のバイト列になる。ちなみにBOM付きUTF-8になる模様。

Windows XP上のソフトウェア:

Internet Explorer 7

不明な文字となる。

Firefox 3.6

不明な文字となる。

メモ帳

表示されない。

「ゆるキャラ(R)」という表記

Intercross Creative Centerのサイトに掲載の「コアックマ」に関するインタビュー記事を読んでいて気になったのは、「ゆるキャラ(R)」という表記でした。この(R)は商標登録の®記号の代用なのか、それとも本当に「括弧にR」として何らかの意味を持つものなのか。

記事を最後まで読んでも分からなかったので適当に検索したところ、「ゆるキャラ」という名称が「扶桑社とみうらじゅんによって2004年11月26日に商標登録されている(登録番号 第4821202号)」というWikipediaの記述があったので、やはり®の代用として使っているのでしょう。「ゆるキャラ®さみっと協会」のWebサイトでは、画像では®記号にして、テキストでは(R)という表記になっています。

しかし、ICCの記事にせよ、「ゆるキャラ®さみっと協会」のサイトにせよ、文字コードとしてUTF-8を使っているにもかかわらず(R)のような代用表記に頼っていることは何とも残念です。Shift_JISで表現できる範囲の文字しかまともに使えないというのなら、UTF-8を使う意味は何なのでしょうか?

このような状況を打破するひとつの方策としては、JIS X 0213の符号化方式、つまりShift_JIS-2004やEUC-JIS-2004の実装を広めて、いつでもどこでもJIS X 0213の文字が使えるようにすることだと思います。実際、私がこのブログで文字参照などを使わずこともなげに®記号を書けているのはひとえに、JIS X 0213の符号化方式を実装したソフトウェアのおかげなのです。

少数派に優しいITを

先日ご紹介したブログ記事に、こういうくだりがありました。

本書では、アイヌ語について所々で触れています。JIS X 0213に触れる以上当然かなというぐらいで読んでいたのですが、著者が札幌出身ということもあるんでしょうね。

確かにそういう面はあるのかもしれません。が、そればかりではもちろんない。

拙著で私はなぜアイヌ語を取り上げなければならなかったか。それを説明するのに、どういう状況ならば取り上げる必要がなかったかを挙げてみましょう。

  • アイヌ語を書くための片仮名がJIS X 0208に含まれていて既に広く実装されていたら、敢えて取り上げる必要はなかった。
  • JIS X 0213の符号化方式が広く実装されていて当たり前のものになっていれば、敢えて取り上げる必要はなかった。
  • Unicodeで結合文字の処理なしにアイヌ語用の文字が処理できれば、敢えて取り上げる必要はなかった。

端的にいえば、日本国内の言語、それも消滅の危機にある言語にもかかわらず、アイヌ語情報処理環境が悲惨な状況にあるからにほかなりません。規格上のサポートは2000年に至るまで存在しなかったし、実装面ではJIS2000以降も実に惨憺たる状況でしかなかったのです。(ただ、最近のMac OS Xのようにアイヌ語のローマ字仮名入力方式やShift_JIS-2004を実装する製品があるなど、例外もあることは付け加えておきます)

ではこの悲惨な現状を少しでも良くするにはどうすればいいか。考えるに、手っ取り早いのは、JIS X 0213の符号化方式、つまりShift_JIS-2004やEUC-JIS-2004を実装することでしょう。

なぜかというに、Shift_JIS-2004やEUC-JIS-2004を実装すれば、いやでもアイヌ語用の片仮名が含まれてくるからです。もしShift_JIS-2004やEUC-JIS-2004を謳うにもかかわらずそれらの文字を正しく扱えないなら、それは単にバグだといえます。

一方、Unicodeだとそうはいかない。「UTF-8に対応しています」といったところで、結合文字を含んだテキストをきちんと扱えるかどうかは分からない。アイヌ語に頻出する「ㇷ゚」のような文字が正しく処理できるかどうかは、UTF-8という表明からは伺い知ることができないのです。Unicode対応のソフトウェアなのに結合文字を使ったテキストの表示が壊れている例は拙著第3章の終わりの方でも取り上げました。

アイヌ語テキストの処理をしたいという要求が少数派のものであることは確かでしょう。しかし少数派だから切り捨てていいかというと、もちろんそんなことはない。多数派が便利になるように設計することは当然のように思われるかもしれないけど、やや大げさにいえば、多数派というのは実はどうでもいい。多数派はその定義上、マンパワーが大量にあるのだから、不便なままほっておいても誰かが解決策を作ってしまう。でも少数派はそうでないのだから、少数派に不便を強いることは、単に不便なだけでなくそれを解決する人もいないという、いわば不便の2乗になってしまう。多数派に便宜を図って少数派に不便を強いることは、少数派をますます少数派にしてしまうことになるのです。

日本の文字コードがアイヌ語の表記に必要な文字を含むことは、当然の義務とさえ言えるでしょう。規格上は既にできているのだから、あとは実装です。

柔道ニュースの第3水準漢字

Web上のニュース記事で、第3水準漢字が外字扱いになっているのを見かけました。

この記事の中に、「北京五輪女子78キロ超級金メダリストの●文(中国)が3連覇した〜」とあり、「●=にんべんに冬の二点がにすい」という注記があります。

「にんべんに冬の二点がにすい」とは「佟」のことでしょう。JIS X 0213の第3水準、面区点位置1-14-17にあります。Shift_JISでは表現できませんがShift_JIS-2004なら表現可能です。コード値はSJISで87AF、EUCでAEB1になります。Unicodeの符号位置はU+4F5Fにあたります。

記事の内容は、この佟文選手がドーピング検査で陽性反応になって金メダルを剝奪されたという残念な話です。

短歌番組の第4水準漢字

NHK教育の短歌番組を見ていたら、第4水準漢字を見かけました。「漢字」といっても実際には字体記述要素の「艹」です。JISの面区点番号2-85-86、SJISではF896です。UnicodeではU+8279にあたります。

投稿作品として、「(くさかんむり)の下に早いと書くからに〜(以下略)」という歌を紹介していました。ルビとして「くさかんむり」を振っていました。こういう使い方もあるんですね。

SKKのJIS第3・第4水準漢字辞書では「くさかんむり」から変換できます。

  1 2 3 4  

最近のブログ記事

仮名合字・合略仮名の文字コード
合字とは 合字というものがあります。複数…
なぜ『プログラマのための文字コード技術入門』の改訂新版にはSKKと Emacsの話が入っていないのか
拙著『[改訂新版] プログラマのための文…
朝鮮半島の訃報の第3水準漢字
朝鮮戦争で韓国軍として活躍した白善燁氏が…
テレワークの環境改善〜CO2濃度をチェックする
テレワークの問題点 新型コロナウイルスの…
エンジニアHubにて「文字コード再入門─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう!」公開
「エンジニアHub」にて記事を執筆しまし…

広告