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

アイヌ文化交流センター「サッポロピㇼカコタン」のWebサイトには、アイヌ語を記すのに使われる特別な片仮名がふんだんに使われています。

といっても、JIS X 0213やUnicodeを使っているのではありません。HTMLのタグで文字を小さくしたり、はたまた画像として作ったり、あるいは所謂「半角」の片仮名で表現したりと、苦労がしのばれます。

名称の「ピㇼカコタン」にしても、「ピㇼカ」の「ㇼ」は日本語の「リ」とは違う発音なので、小書きの「ㇼ」が適当なのです。

ただ、このサイトでは、文字をどういう方法で表すかが不統一なだけでなく、肝心のアイヌ語表記そのものにも方針の不統一が目立ちます。

例えば、pで終わる語について、小書きの「ㇷ゚」で表す箇所もあれば、普通の「プ」を用いている箇所もあるという具合です。

さらに、私はアイヌ語に詳しくないので断定は避けますが、ローマ字綴りもアイヌ語としてあっているのかどうかちょっと疑問に思う箇所があります。楽器の「ムックリ」をこのサイトでは片仮名で「ムックㇼ」ローマ字で「mukkur」と書いていますが、これは怪しい。ローマ字でmukkurが正しいとするなら「ムックㇽ」になる筈で「ムックㇼ」にはならない。そもそも、私の理解が正しければ、「クㇼ」という綴りになるケースはないのではないかと思います。ここは、片仮名で「ムックリ」ローマ字で「mukkuri」が妥当なのではと推測されます。アイヌ語の辞典の著作もある中川裕氏の「アイヌの物語世界」(平凡社)には「ムックリ」と記されています(p.260)。

というような議論をするためにもやはり、JIS X 0213なりUnicodeなりでアイヌ語表記用の片仮名を自由に交換できるようにする必要があるのです。しかしUnicodeを使った場合、一部の文字に符号位置が与えられていないために面倒なことになります。拙著を書くときに遭遇したこの種のトラブルについてはこぼれ話にも書きました。

2000年の時点でベンダが覚悟を決めてJIS X 0213対応を進めていればこういうことにはならなかったのでしょうが(少なくとも、今よりもマシな状態になっていたのでしょうが)、残念なことです。

韓国関連ニュースの第3水準漢字

産経新聞のWebサイトに掲載の記事「「親日」に対抗して「親北人名辞典」の名簿発表 韓国保守団体」に、人名に関連してこんな記載がありました。

統一相を務めた李鍾●(大の左右に百)、

「大の左右に百」とは、「奭」のことでしょう。日本語では「せき」と読みます。この漢字はJIS第3水準、面区点番号1-15-74にあります。Shift_JIS-2004では888A、EUC-JIS-2004ではAFEAというコード値になります。UnicodeではU+596Dにあります。

JIS X 0213は韓国語の人名を網羅することを意図して文字を収集したわけではないので、JIS X 0213外の漢字もあるのだと思いますが、ニュースを見ている限りではだいぶカバーできそうに思えます。

ちなみに同じ記事の中には「黄皙●(日へんに英)」という記載もあったのですが、日へんに英つまり「暎」という字は、JIS第2水準、1-58-85にあります。第2水準にあるのになぜ探せなかったのでしょうか。

中国関連ニュースの第4水準漢字

産経新聞のWebサイトに掲載の記事、「パンチェン・ラマの副主席選出見送り 中国政協閉幕」の中に、人名についてこんな記載がありました。

「何(か)厚●(=金へんに華)(こうか)」

「金へんに華」という字、すなわち「鏵」は、JIS第4水準、面区点番号2-91-28にあります。Shift_JIS-2004ではFB5Bという2バイト、EUC-JIS-2004では8FFBBCという3バイトになります。UnicodeではU+93F5にあります。

JIS X 0213は中国語の人名を網羅することを意図して文字を収集しているわけではないので、JIS X 0213外の文字も当然あるのですが、ニュースなどを見ている限りでは結構カバーできるような印象を受けます。

ちなみにこの記事のパンチェン・ラマ11世は、先代の死去した後にダライ・ラマ14世の指名した後継者に対抗して中国政府が擁立した方の(いわばニセモノの)11世でしょう。本物の方は中国政府に連れ去られて今も行方は明らかでないそうです。パンチェン・ラマについて詳しく書かれたページがあります。

iPod TouchではJIS X 0213で初めて符号化された漢字を、単語として入力できることに今ごろ気付きました。

例えば、地名の例でいえば、「ほうのきざく」から「𣖔木作」(福島県)が、「きびなごあじろ」から「𩸕網代」(長崎県)が、「なぎのした」から「𡵢下」(愛知県)が、「ろほう」から「𡉴豊」(徳島県)が入力できるのです。それぞれ、「𣖔」(2-15-10)、「𩸕」(2-93-57)、「𡵢」(2-08-27)、「𡉴」(2-04-67)は JIS X 0213で初めて符号化された漢字です。面区点番号からわかるように、いずれも第4水準です。Unicodeではバージョン3.1で面02のCJK統合漢字拡張Bに入りました。

人名の「𣟿良(なぎら)」などというのも変換できます。「𣟿」(2-15-73)は同様に拡張Bにあります。

Unicodeで拡張Bにあたる漢字以外の第3・第4水準もあります。以前このブログでもとりあげた例として、「とかられっとう」から「吐噶喇列島」が、iPod Touchで変換できるのです。「噶」はJIS第3水準です。

ここではiPod Touchと記していますが、これは私の持っている機械がたまたまそれだからのことで、多分iPhoneでも同様なのでしょう。

JIS第3・第4水準漢字の普及は案外iPod Touch/iPhoneから始まるのかもしれないと思いました。

国会中継の第4水準漢字

NHKの国会中継でJIS第4水準漢字を見ました。「𥱋」という字です。「𥱋瀬」という名字として字幕に映っていました。面区点番号は2-83-61で、Shift_JIS-2004ではF77C、EUC-JIS-2004では8FF3DDというコード値になります。UnicodeではU+25C4BというBMP外の位置にあります。

ただ、誰の名前なのかはわかりませんでした(記憶できなかった)。国会議員の名前を検索すると参議院に簗瀬進という人がいて、「議員氏名の正確な表記」というページでは「𥱋」の字体が指定されているので、もしかするとこの人だったのかもしれません。

それにしてもこの「議員氏名の正確な表記」というのはちょっと考えものです。「鈴」の右下部分の違いとか、「保」の最後の2画が点かどうかとか、書き方のちょっとした違いあるいは書体による違いのようなものを「正確な表記」と指定するのはいかがなものかと思います。これによって誰が得をするのかと疑問に思います。

北道邦彦「アイヌ語地名で旅する北海道」(朝日新書)は北海道の様々な地名のアイヌ語語源を考察している本です。単にこの地名はこういう意味だと説明するだけでなく、アイヌの地形把握の方法にまで踏み込んでいて、なるほどと思わせます。アイヌにとっては川が重要で、川を遡った先にある山の名前は川に関係がある、といったことなどです。

また、間違って認識しやすい地名も取り上げられています。例えば、知床はアイヌ語で「地の果て」だとする説を結構見かけますが、これには問題があって、「地の先」と解釈する方が適切だそうです。あるいは、山名のニセコアンヌプリというのは「ニセコ・アンヌプリ」と分けられると思いがちですが、アイヌ語の文法に即していうなら「ニセイ・コアンヌプリ」となるのだそうです。

さて、この本ではアイヌ語を片仮名で表記しているので、通常の日本語表記用とは異なる片仮名が頻出します。例えば、小さく書くㇻㇼㇽㇾㇿなどです。コンピュータ上の文字コードとしては、2000年制定のJIS X 0213において、これらの字のコードが決められています。JIS X 0213に対応したソフトウェアならこうした字が使えるのです。

同書のアイヌ語の片仮名を見ると、必要に応じて小書きの片仮名を使っています。しかし、字のサイズが、「ッ」のような普通の小書きの片仮名と釣合いがとれていないのが気になります。

例えば、p.115で「シレトコ アナㇰ シレトッコㇿ!」(知床は美しい!)と書かれていますが、後半の「ッ」と「ㇿ」を見比べると明らかに「ㇿ」の方が小さく、バランスを損なっています。「ㇿ」などの小さな字を特別に用意したのでこうなったのでしょうか。

また、「ト゚」(半濁点付きのト)における半濁点は、妙に大きくなっています。用意されていない活字なので何か間に合わせで作字したのでしょうか。例えばp.213に「パンケ ト゚エ ピラ」と書いてありますが、「パ」や「ピ」の半濁点と比べて「ト゚」の半濁点が明らかに大きく、バランスを損なっています。

印刷にいつでも使える文字として、JIS X 0213の文字が網羅されていれば、「ㇿ」や「ト゚」なども他の文字とのバランスを考慮してデザインされ、読者に違和感を与えずに済んだかもしれません。やはり、JIS X 0213をサポートすることが大変大事であるように思えます。

なお、Unicodeでサポートしようとすると、上記の「ト゚」や、ほかにもアイヌ語で頻出する「ㇷ゚」などは単一の符号位置でなく、結合文字を使って2つの符号位置の組み合わせによって1文字を表現する必要があります。「ト゚」ならU+30C8 U+309Aという列になるという具合です。プログラミング上、注意が必要です。

「しいな塚」の用例

宮城県角田市に「𥼣塚(しいなつか)」という地名があるようです。米へんに無という「𥼣」の字は、JIS第4水準、面区点番号2-84-04。UnicodeではU+25F23という、BMP外の位置にあります。UTF-16ではサロゲートペア、UTF-8では4バイトのUTF-8が処理できる必要があります。SJISならShift_JIS-2004、EUCならEUC-JIS-2004で扱えます。

この地名はJIS漢字字典にも載っています。ネット上の地図サイトでは、「しいな塚」と、平仮名をまぜて書かれるようです。

この字の用例をWebで探してみたところ、角田市のWebサイトにありました。

角田市市税条例のページの後ろの方、「別表」の中に、「字𥼣塚」と、「𥼣」の字を画像にして表現しています。

市のサイトに漢字で書かれているということは、役所の発行する印刷物ではやはり漢字で書かれているのではと想像します。

大修館書店の「大漢和辞典」では、「しったげきれい」や「しっせき」などの熟語に使われる「しかる」という漢字、口へんに七という字は、3247番にあります。

ところが、Unicodeの漢字のデータを揃えているUnihanデータベースを見ると、大漢和辞典の3247番を参照している文字は存在しません。口へんに匕のように書く「叱」U+53F1は大漢和辞典の3247でなく3248番ということになっています。大漢和辞典ではこの字は「しかる」ではなく、「か」という読みの、「口を開くさま」という意味の字だとされています。また、近頃一部で話題のU+20B9Fという符号位置(口へんに七、「𠮟」)についても、大漢和の3247番への参照はついていません。

なんと、「しかる」という特に珍しいわけでもない字がUnicodeには存在しなかった!

......まあ勿論、単にUnihanデータベースの整備不良なのでしょうけど。

本来は、U+20B9FかU+53F1に大漢和辞典の3247番への参照があるべきでしょう。U+53F1につけていいかどうかは微妙ですが、大漢和の3247番の説明には俗に「叱」の形に作るともあるので、まあいいんじゃないでしょうか。それに、U+53F1の元になっているJIS X 0208の28区24点が「しかる」でないとは考えにくいですし。

Unihanを更によく見ると、読みを記したファイルにはU+53F1の日本語の読みとして「しち」「しつ」「しかる」を掲げているので、大漢和辞典の3248番だという参照とは矛盾しています。3248番だとするのなら読みは「か」でなければならず、あるいはU+53F1が「しかる」という読みだとするのなら大漢和辞典の3247番でなければなりません。

ちなみに、大漢和辞典における3248番の「か」という読みだとする字の説明は、昔の字書の説明を引いているだけで、熟語も用例もありません。現実の言語表記において、「か」という読み、「口を開くさま」という意味として、実際にどれくらい使われた実績があるのかは、大漢和辞典の説明からだけでは想像がつきません。

文字コード変換プログラムのiconvでは、文字コード「UTF-8」において、入出力ともにBOMを用いません。

出力においてBOMを使わないということは、すぐに納得がいくことと思います。UTF-8として出力されるバイト列の先頭にBOMがつかないということです。

かたや、入力においてというのがどういうことかというと、BOMに相当するバイト列を 見ても、それをBOMとは認識しないということです。

つまり、データ先頭にEF BB BFという3バイトがあったら、それをBOMとして消費するのでなく、単なる普通の1文字のように扱うのです。

ちょっと実験してみましょう。

UTF-8にBOMを付けて出力するプログラムとしてポピュラーなのはWindowsのメモ帳です(XPで確認)。メモ帳でUTF-8としてテキストを保存するともれなくBOMがついてきます。

例えば、メモ帳で「あ」とだけ書いて改行し、UTF-8で保存する。すると、EF BB BF E3 81 82 0D 0A というバイト列になる。

これをiconvでShift_JISに変換しようとする。「あ」と書いてあるだけなのだから問題ない筈と思いきや、これがうまくいかない。

 $ iconv -f UTF-8 -t SHIFT_JIS a.txt > a-s.txt
 iconv: illegal input sequence at position 0

なんと、エラーでとまってしまいます。

なぜかというと、先頭のEF BB BFをBOMとみなすのでなくテキストの一部と解釈し、U+FEFFの文字をShift_JISに変換しようとして、Shift_JISには該当する文字がないので、当然のごとく失敗しているわけです。

この場合、iconvにオプション -c を付けて、変換できない文字を無視するようにすればエラーなく通ります。

また、上のUTF-8テキストをUTF-16に変換しようとするとこうなります。ここではUTF-16BEやUTF-16LEでなく、UTF-16を指定します。つまり、BOMを用います。

 $ iconv -f UTF-8 -t UTF-16 a.txt | hd
 00000000  ff fe ff fe 42 30 0d 00  0a 00                    |....B0....|

なんと、BOMが2つ並ぶという残念な結果になってしまいます(先頭のff feがBOM)。もう説明の必要はないと思いますが、UTF-8テキストの先頭の3バイトがBOMとして解釈されず、UTF-16を出力するときに改めてBOMを付けようとするので、こういう結果になっています。

上で使った出力のUTF-16はBOMを用いますが、ではBOMを付けないつもりでUTF-16BE を指定するとどうなるか。大体想像がつくと思いますが、こうなります。

 $ iconv -f UTF-8 -t UTF-16BE a.txt | hd
 00000000  fe ff 30 42 00 0d 00 0a                           |..0B....|

iconvの入力にUTF-8を指定するときは、入力データにBOMがついていないことを確認しておくのが良さそうです。

goo辞書の発音記号

以前は確か違ったと思うのですが、goo辞書の英和辞典では、発音記号をUnicodeで表現しています。例えば、「cache」という単語について〔kæʃ〕という発音記号を画像でなしに文字データとして表現しています。

ふーん、そうなんだ。と思って、ではこれはどうだろうかと「acrobat」という単語を引いてみました。すると、第2強勢のある二つ目のaに当たる母音の発音記号「æ̀」(æの上に`) という字だけは文字データでなく画像で表現しています。

この字はUnicodeに単一の符号位置が用意されておらず、æの後に合成用の` (U+0300) を続けることで表さなければなりません。JIS X 0213ならば1-11-36という単一の符号位置が与えられています。

goo辞書の人がどう判断したのかは不明ですが、Unicodeで合成の必要な文字は正しく表示されないかもしれないと考えたのでしょうか。このブログの読者の環境ではどうでしょう。〔ǽkrəbæ̀t〕という発音記号が、アクセント記号を上に乗せた形できちんと表示されているでしょうか。

ちなみに、強勢を表すのに母音の上に「´」や「`」をつける形は日本の英語教材や英和辞典ではポピュラーですが、英英辞典では音節の前に「 ˈ 」や「 ˌ 」を置くものが多いようです。

「きびなご網代」の用例

魚へんに長、すなわち「𩸕」という珍しい字は、JIS X 0213の第4水準、面区点番号2-93-57にあります。UnicodeではU+29E15というBMP外の位置にあります。長崎県は五島列島にある𩸕網代(きびなごあじろ)という地名に使われる字です。この地名は「JIS漢字字典」にも載っています。

Webに、この字が実際に使われている用例の画像がありました。下記のページに画像があります。

また、長崎新聞のWebサイトに、「𩸕」を外字扱いして書かれた記事があります。「〓網代(きびなごあじろ)」のように書き、「【編注】〓は魚ヘンに長」と注釈しています。JIS第3・第4水準が使えれば外字扱いする必要がなかったのに、残念ですね。

個人のWebサイトでも、この字が使えれば使っていた筈のページがあります。例えばここここです。

私の住む南関東から五島列島に行くのは大変なので、もし行く方がいたら現地調査してきてWebで公開していただければと思います。

なお、SKKではJIS第3・第4水準漢字辞書を使うと、「きびなごあじろ」から「𩸕網代」が変換できます。

拡張Bの必要な地名

愛媛県松山市の𧃴川(つづらかわ)の「𧃴」の字は、JIS第3水準、面区点番号1-19-75です。Unicodeには元々なくて、CJK統合漢字拡張Bの一部として追加されたものです。U+270F4にあります。UTF-16ではサロゲートペア、UTF-8では4バイトの領域を処理できるプログラムでないと扱えません。

この字は、「つづら川」などとしてWebで検索すると、結構需要のあることが分かります。この地名を冠したトンネルがあるためのようです。𧃴川トンネルの写真もあります。ばっちり「𧃴」の字が写っています。

(Firefoxのルビ拡張では、「𧃴川」にルビタグで「つづらかわ」とルビをふったら𧃴の字が正しく表示されなかったので、ルビをやめて括弧書きにしました。BMP外の文字は何かと不具合があるようです)

テレビで見た第4水準漢字

何週間か前のテレビ朝日のクイズ番組「Qさま!!」だったと思いますが、 JIS第4水準漢字がクイズに出題されていたのを見ました。

「𩸽」という字の読みを答えさせるものです。この字はホッケと読みます。 出演者が正解していたので、漢字に詳しい人にはよく知られているのでしょう。

「𩸽」の字はJIS X 0213では2面93区44点にある第4水準漢字です。Unicode ではU+29E3Dにあります。符号位置から分かるように、BMPではなく、面02にあ る字です。BMP外の字は、常用漢字がらみで話題の「𠮟」ばかりでなく、テレビ のクイズ番組の画面に映るようなものにも存在するということになります。

livedoor Reader 直った?

少し前の記事でlivedoor Readerではフィードの中にUnicodeのBMP外の字があるとそこで切れてしまうということを書いたのですが、先日他のブログのフィードを見ていたら「𠮟」がきちんとフィード表示の中に入っていたので、最近直ったのかもしれません。

ということでこの記事はテスト用です。livedoor Readerできちんとここまで表示できていれば、直ったことになります。

もっともこの場合、「直った」というべきか「新たに対応した」というべきか微妙かもしれません。

【追記2009/12/27】この記事のフィードをlivedoor Readerで表示したところ、前と同じく「𠮟」の前で切れてしまいました。変わっていないようです。上記の「他のブログのフィードを云々」というのは、調べてみたら、このブログのように文字そのものを記すのでなく、フィードの中にHTMLの文字参照の形式で記述されていました。「𠮟」の文字そのものを記すと問題になるようです。結局、「直った?」に対しては「直っていない」が答えのようです。

「叱る」は間違いか?

安岡先生の「新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能」は、気になる点がふたつありました。ひとつは、「シフトJIS」では対応不可能としている点、もうひとつは、「𠮟」や「剝」がJIS X 0208で表現不可能であるかのように書かれている点です。

JIS X 0213:2004にはShift_JISの上位互換であるShift_JIS-2004という符号化方式がありますから、これを使えば「叱」0x8EB6に対する「𠮟」は0x9873というコード値で見事に表現可能です。『「シフトJIS」では対応不可能』という文言は、第2水準漢字までしかサポートしないShift_JISに限定すれば成り立つとしても、第3・第4水準漢字を表現可能なShift_JIS-2004という上位互換のコードを使えば(私は毎日使っています)あたりません。Shift_JIS-2004はEmacsでもサポートされています。

第2の点としては、JIS X 0208:1997が実際には、28区24点に対応する文字として「叱」と「𠮟」の両方を表現可能だと規定しているということです。つまり、Shift_JISの0x8EB6を出力する際に「叱」としても「𠮟」としてもいいのです。「𠮟」が「叱」とは別の区点位置としてJIS X 0213:2004に追加されたのは、例示字形を表外漢字字体表にしたがって改める際に、Unicodeがバージョン3.1で導入した「拡張B」において「𠮟」をもともとあった「叱」とは別の字として追加してしまっていたため、単純に28-24の例示字形を変えるとUnicodeとの変換表を変えなければいけなくなるということで、「表外漢字UCS互換」として特別に追加されたものです。その際、面区点位置1-28-24は「叱」専用に変更されました。これはJIS X 0213に対する変更であって、JIS X 0208に対してではありません。したがって、JIS X 0208としては今でも28-24で「𠮟」を表現可能なのです。(今後のJIS X 0213への移行のしやすさを考えると28-24を「叱」専用のようにみなした方が話が単純にはなります。単純ですが、正確ではありません)

もっとも、安岡先生が上のような事実をご存じでないはずはないので、意図的に話を単純化して書かれたものでしょう。

「しかる」の意味の漢字の字体として、現代の日本では「叱」も「𠮟」も両方使われています。漢和辞典には「しかる」が「𠮟」であり、「叱」は別字であるとするものがありますが、実際の文字運用とは合致しません。JIS X 0208:1997もそのことに言及しています(規格票p.276)。仮にJIS X 0208の28区24点が「叱」にしか対応しないと決めると、「𠮟る」などと印刷された文字が符号化できないことになり、大変不便になってしまいます。

JIS X 0208:1997に説明されているところでは、JIS X 0208の規格票の例示字形としては、第1次規格(78JIS)ではもともと「叱」の字体で印刷されていたものが第4刷への正誤票において「𠮟」に変更したのですが、のちの改正ではまた「叱」に戻っています。

また、同じくJIS X 0208:1997の説明では「新字源」と「大漢和辞典」では「しかる」の字は「𠮟」であり、「叱」は大漢和辞典では「カ」と読む別字扱いになっていることが説明されています。そのうえで、コンピュータのフォントや活字や、あるいは手書きでも、「しかる」の意味で「叱」が実際には多く見られることが述べられています。

漢和辞典的には「しかる」を「叱る」と書くと間違いだとして𠮟られてしまうのかもしれませんが、現実の文字運用上は「叱」と「𠮟」に区別がないといってよいでしょう。解像度の低いコンピュータの画面では区別がつきづらいということもあるので、区別しない方が本当は便利だと思います。

配布物の一環として、「JIS X 0213の文字のUnicode合成表現のためのSKK辞書」を公開しました。先日のブログ記事のものを少々拡張したものです。

当Webサイトの編集にも、ここで公開している辞書を活用しています。

用途が分かりづらいものなので、説明を書くのに少々苦労しました。EmacsとMule-UCSとSKKでJIS X 0213の文字を使ったHTML文書を書いてUTF-8にしようとすると、必要性が自然と分かるものなのですが、いちから言葉で説明するのはなかなか難儀です。

この辞書によって、アイヌ語や鼻濁音などの文字を使ったHTML文書をEmacs + Mule-UCS + SKKの環境で入力しやすくなるというものです。

先の記事のAtomフィードをlivedoor Readerで表示させたところ、ちょっとおかしい結果になりました。本当は本文全部が表示されるはずのところが、途中で切れて終わっていたのです。切れていた箇所は、「𠮟」の字の直前です。試しにGoogle Readerでも同じフィードを表示してみましたが、そのような問題はなく、全文表示されます。

想像ですが、livedoor ReaderではUnicodeでBMP以外の面にある文字の扱いに問題があるのではないでしょうか? (違ったらごめんなさい)

先の記事では、「𠮟」という文字がUnicodeではBMP外なので使用に問題を生じるかもしれない、ということを書いたわけですが、問題の実例が早速発生してしまったようです。

先の記事に「ㇷ゚」などアイヌ語特有の片仮名を書きましたが、私のこのブログの入力環境では、こうした文字の入力には少々問題があります。

このブログの入力環境というのは、ブラウザはFirefoxで、アドオンのMozExを使って外部エディタとしてEmacs 22を呼び出してテキストエリアを編集するというものです。EmacsにはMule-UCSをインストールしています。

この環境では、JIS X 0213の文字を自在に入力することができます。Mule-UCSのJIS X 0213サポートのおかげです。Emacsのバッファ上での入力・編集だけなら何の問題もありません。過去の記事に第3・第4水準漢字や「゠」(ダブルハイフン)のような記号を書いているようにです。前にも書いたように、私はSKKを使ってこれらの文字を入力しています。

しかし問題になるのは、編集したテキストをFirefoxに渡すためにはバッファをUTF-8で保存する必要があることです。Mule-UCSでは、JIS X 0213の文字のうちUnicodeで表現する際に結合文字を使って二つの符号位置によって表す必要のある25文字は(例えば「ㇷ゚」)、Unicode系の符号化方式では正しく保存されないのです。EUC-JIS-2004のようなJIS X 0213の符号化方式なら問題ないのですが。

そこでどうすればいいかというと、仕方ないので結合文字はHTMLの文字参照で表すことにします。「ㇷ゚」ならば「ㇷ゚」のように書くのです。せっかくUTF-8を使っているのに文字参照を使うのは何だかなあという感じですが、致し方ありません。

文字参照で表すといっても、手で打つのは面倒ですから、これもSKKで変換してしまえ、ということになります。SKKの第3・第4水準漢字辞書では「ぷ」から「ㇷ゚」を入力できますが、それに加えて「ㇷ゚」という文字参照付きの表現も辞書に登録してしまうのです。「゚」というのが合成用の半濁点だと覚えておけば、格好は悪いですがともかく入力・編集することはできます。

ただし、SKKの辞書形式では「;」はアノテーションを示す区切り文字として意味を持っているので、ちょっと特別な書き方をしてやる必要があります。

下記に例を示します。私はこれをSKK-JISYO.ucscompという名前で保存して、SKKの辞書のひとつとして読み込ませています。

;; -*- mode: fundamental; coding: euc-jisx0213 -*-
;;
;; okuri-ari entries.
;; okuri-nasi entries.
nga /(concat "か&#x309A\073")/(concat "カ&#x309A\073")/
nge /(concat "け&#x309A\073")/(concat "ケ&#x309A\073")/
ngi /(concat "き&#x309A\073")/(concat "キ&#x309A\073")/
ngo /(concat "こ&#x309A\073")/(concat "コ&#x309A\073")/
ngu /(concat "く&#x309A\073")/(concat "ク&#x309A\073")/
が /(concat "か&#x309A\073")/(concat "カ&#x309A\073")/
ぎ /(concat "き&#x309A\073")/(concat "キ&#x309A\073")/
ぐ /(concat "く&#x309A\073")/(concat "ク&#x309A\073")/
げ /(concat "け&#x309A\073")/(concat "ケ&#x309A\073")/
ご /(concat "こ&#x309A\073")/(concat "コ&#x309A\073")/
せ /(concat "セ&#x309A\073")/
つ /(concat "ツ&#x309A\073")/
と /(concat "ト&#x309A\073")/
ぷ /(concat "ㇷ&#x309A\073")/

これによって、アイヌ語用に必要な文字と、鼻濁音用の半濁点付きカキクケコは、文字参照を使った表現が入力可能になります。ほかにも同種の措置の必要な文字が発音記号等にあるので、もうちょっと整備が必要かもしれません。

と、ここまで書いて気付いたのですが、環境によっては「ㇷ゚」などが正しく見えていないと思います。JIS X 0213対応のフォントを使って、新しめのブラウザを使えば表示できると思いますから、「ㇷ゚」が小書きのプに見えていない方はこの機会に環境をアップグレードされることをおすすめします。

ことえりでアイヌ語を試す

Mac OS Xのことえりを触ってみて面白かった、かつ感心したのは、アイヌ語の入力方式が実装されていたことです。

単に文字が入力できるというだけでなく、アイヌ語の一般的なローマ字つづりにしたがって打鍵すると片仮名に変換されるというものです。

たとえば、ローマ字で「akor␣itak⏎」と打鍵すると片仮名の「アコㇿ イタㇰ」になるのです。最後にリターンが必要なのは、後に母音がつくのでなくそこで終わりであることを示すためです。リターンを押すまでは未確定の状態になっています。スペースの前のrも同様で、直後にスペースを打つことによってㇿに確定されます。

また、「sirpopke」と打鍵すると「シㇼポㇷ゚ケ」と入力されます。標準添付のエディタ「テキストエディット」であれば、この文字列をShift_JIS-2004 (テキストエディットの画面では「Shift JIS X0213」)やUTF-8で保存することができます。

UTF-8で保存すると、Emacs 22 + Mule-UCSの環境では正しく表示できない文字があります。Unicodeで結合文字を使う必要のある文字がそれです。アイヌ語関係では、セ゚、ツ゚、ト゚、ㇷ゚の4文字です。よく使う「ㇷ゚」についてこの問題があるのはかなり痛いです。

Shift_JIS-2004であればこの問題はないので、Emacsとの間で自由に交換することができます。

「吐噶喇列島」が表示できますか

前の記事に「吐噶喇列島」という言葉が出てきましたが、2文字目の「噶」が正しく表示されているでしょうか。口へんに葛という字です。これはJIS第3水準漢字で、面区点番号は1-15-20、SJISでは0x8853というコード値になります。

Windows Vistaであれば表示されていることでしょう。XPでは、インストールされているフォント次第です。

この文字が表示できるためには、JIS X 0213の文字に対応したフォントが必要です。例えば以下のようなフォントなら大丈夫です。当サイトはこうしたフォントをインストールした上でご覧になることをおすすめします。

当サイトは、文字コードとしてUTF-8を使っていますが、文字のレパートリーとして従来のJIS X 0208でなくJIS X 0213相当の集合を用いています。本当はUTF-8でなくてEUC-JIS-2004やShift_JIS-2004でもいいのですが、Webではあまり一般的でないのでUTF-8にしています。

  1 2 3 4

最近のブログ記事

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

広告