文字コードに関する雑記

2002年03月29日（金）   よく見てみたら 昨日Unihan-3.2.0.txtについて、今回からはじめてJIS X 0213-2000のマッピングがあるように書きましたが、前のUnihan-3.1.1.txtを見てみたら、すでにありました。    で、タグつけについても、0213については、「kIRG_JSource」を見るより、「kJIS0213」を見た方がよいとおもわれます。そこには「1,14,03」のような形式で「面,区,点」が記述されています。  つまり、Unihan-3.2.0.txtで新しい所は「kCompatibilityVariant」タグで記述された部分であると思われます。    また、「kCompatibilityVariant」として新しく振られたコードの一つにU+FA5Cという文字があります。字面としては「臭」に似た字で「自＋犬」を合わせたものです。Unicode側ではこれはU+81EDの異体字として考えられているようですが、PDFで見る限りどちらも「自＋犬」という字面になっています。    U+81ED　kIRG_JSource　0-3D2D    なので区点でいうと「29-13」です。でもこのコードにあたる字を0213側のPDFで見ると「自＋犬」ではなく「自＋大」に割り振られています。0213のPDFは汚くて見づらいのですが、0213では「自＋犬」を「1-90-56」に割り当てて区別しようとしているようです。    つまり、Unicode主体で見るとメインはU+81EDで、これは「自＋犬」。今まではこれ一つしかなかったので、それを「自＋大」（1-29-13）に割り当てていた。それが今回Compatibilityということで、U+FA5Cを用意した、という感じでしょうか。では0213を主体として考えるとどちらにどちらを割り当てればいいのでしょうか。    「自＋大」　1-29-13　・・・・　U+81ED ? U+FA5C ?  「自＋犬」　1-90-56　・・・・　U+81ED ? U+FA5C ?    いままでしかたなく「自＋大」を「自＋犬」に割り当てていたことを考えると、「1-90-56」をU+81EDに、「1-29-13」をU+FA5Cにするのが素直かと思いますが、じゃあ今までの割り当てはどうするんだ、という問題もあるかと思います。ややこしい話です。    もちろんUnicode側ではJIS X 0213との対応を厳密に規定しているわけではなく、「対応できるようにコードを開けておいたから、あとはご勝手に」という姿勢なのでしょうが。    【今日の日経平均】　11,024 -308

2002年03月28日（木）   Unicode 3.2 久しぶりにwww.unicode.orgを見たらUnicode 3.2がリリースされていました。いくつかのファイルをダウンロードしてざっと見てみた感じではJIS X 0213との親和性が高まっているように思えます。    SourceとしてJIS X 0213-2000が明記され、Unihan.txtの中でもJISコードとのマッピングが（サロゲートペアの部分も含めて）ちゃんと記述されているようです。「kIRG_JSource」というタグで    J0　JIS X 0208-1990  J1　JIS X 0212-1990  J3　JIS X 0213-2000  J4　JIS X 0213-2000  JA　Unified Japanese IT Vendors Contemporary Ideographs, 1993    とあり、    U+20089　kIRG_JSource　4-2121    のように書いてあるのでU+20089が0x2121となっています。このHexコードはいわゆるJISコードで区点コードからそれぞれ0x20ずらしたものなので、結局U+20089は第四水準（＝二面）の1-1という区点コードであることがわかります。  X 0213で前のJISのユーザー定義域をつぶした部分がどうなっているのかはまだちゃんと見ていないのでよくわかりませんが。    あと、Unicode 3.2のドキュメントの中で、ちょっと気になったのは、U+FA30からU+FA6Aの「Private Use Area」に「to provide full round-trip compatibility with the ideographic repertoire of JIS X 0213:2000」という理由で５９文字が割り当てられていることです。    PDFファイルで実際にその字面を見てみると、例えばU+FA33には「勉」の字（に似たもの？）が割り当てられていますが、これをUnihan.txtで見ると、    U+FA33　kCompatibilityVariant　U+52C9    となっています。そこでU+52C9の字面を見てみると、これも「勉」の字です。なんとなくU+52C9の方が「カ」の部分が狭いような気がしますが。ちなみにU+52C9は0-4A59（区点番号4257）で「勉」の字です。    なんでこんなことをしているのか、そしてこれがなぜ「round-trip compatibility」になるのか、その真意がまだよくわかりません。    【今日の日経平均】 11,333 +9

2002年02月27日（水）   Unicodeの改行 Unicodeのテーブルを作るプログラムは今までのものとほとんど同じなのですぐできましたが、さてUnicodeのファイルを読み込むルーチンを作るにあたって、Unicodeでの改行マークって何だろう、というところでひっかかりました。    調べてみるとUnicode Newline Guidelines(www.unicode.org/unicode/reports/tr13/)では次のものを改行として識別することが望まれているようです。    CR(carriage return)　　U+000D  LF(line feed)　　　　　U+000A  CRLF(CR+LF)　　　　　　U+000D,U+000A  NEL(next line)　　　　　U+0085  VT(vertical tabulation)　U+000B  FF(Form Feed)　　　　　　U+000C  LS(Line Separator) 　　　U+2028  PS(Paragraph Separator)　U+2029    面倒くさいですね。一応UTF-8とUTF-16(little)の二つに対応しようと思っているのですが、では上記のNEL,LS,PSはUTF-8ではどう表わされるのでしょう。前に作ったUTF-32をUTF-8に変換するプログラムを使って調べてみると、    NEL(U+0085)　　0xC285  LS(U+2028)　　　0xE280A8  PS(U+2029)　　　0xE280A9    となりました。LS,PSだと改行ひとつに３バイトですか。UTF-8の第１バイト目には0x0a〜0x0dのコードはこないのでそれだけならチェックが楽なのですが。    【今日の日経平均】 10,573 +370

2002年02月26日（火）   Unicode再び 昨日の文字化けの原因はすぐにわかりました。区点の１点が0x40なのだから、0x40引く１で、点に0x39を足して・・・なんてことをしていました。もちろん0x40-1=0x3Fですね。    これでとりあえずEUCとCP932は揃ったので、次はUnicode（UTF-8/UTF-16)の変換ルーチンにとりかかることにしました。これはJIS系とUnicode系の違いがあるので、その橋渡しをASCIIコード部分を除いて全面的にテーブルで行なわなければいけません。    幸いにも「jisx0213 infocenter」というサイトでテーブルを公開しているので、ダウンロードさせていただき、それを元に見ています。windows系の変換で、U+02225／U+0FF0D／U+0FF5Eがやっかいです。  別のUnicodeから同じJISを出すのはいいのですが、同じUnicodeから別のJISは生やしたくないからです。結局この３つのコードに関してはwindowsとの互換を切り捨てることにしました。    あと、www.unicode.orgを見るとUnicode 3.2が来月（2002/03）リリースのようです。    【今日の日経平均】 10,202 -93

2002年02月22日（金）   チェック よく考えてみたら昨日のチェックの方法ではやっぱり甘いことがわかりました。CP932からJIS X 0213への変換の場合、次のようにすることにしました。    ［レイヤ１］コード範囲によるCP932不適格データの排除  -------------------------------------------------------  ［レイヤ２］テーブルによるCP932不適格データの排除  -------------------------------------------------------  ［レイヤ３］式あるいは変換テーブルによる面・区・点への変換  =======================================================  ［レイヤ４］テーブルによるJIS X 0213不適格データの排除    コード範囲でしばってもまだその中には文字がアサインされていない部分があるので、それをまとめたテーブルを持ってレイヤ２ではじきます。例えばこんな感じです。    [E]　0x81AD  [E]　0x85*    0x85*は0x85ではじまるすべてのコードを表わします。    また特定のコードは式では変換できないので、次のようなテーブルでレイヤ３で変換します。    [C]　0x8790　1-2-66  [C]　0x8791　1-2-65    このレイヤ２とレイヤ３で使うテーブルは一つのファイルにまとめておきます。で、レイヤ３を通過したデータはCP932としては適格ですが、それがJIS X 0213として適格かどうかはわかりません。    そこでレイヤ４用に別ファイルで次のようなテーブルを持って不適格データをはじきます。    [E]　1-4-92  [E]　2-2-*    やはりこの場合も2-2-*は２面２区のすべての点を表わします。    とりあえず２つのテーブルファイルの作成と、それをメモリにsetやmapに組み立て、そこから（検証用に）テキストファイルに戻すところまではできました。    【今日の日経平均】 10,356 +61

2002年02月21日（木）   not assigned CP932の外字をJIS X 0213に変換するテーブルを作るプログラムを作ってみましたが、範囲がばらけているので、変換するデータだけのテーブルではダメなことがわかりました。変換したくないデータもnot assignedという情報つきでテーブルに入れておかなければいけません。    CP932から面・区・点への変換は今のところはこんな感じです。    1) テーブルにある最小CP932より小さければ式で変換する  2) そうでなければテーブルを引く  3) テーブルにヒットすればそれを変換後のデータとする  4) not assignedとしてマッチすれば、エラーデータとする  5) テーブルに見つからなければ式で変換する    式の変換でもコード範囲チェックはしていますが、ちょっと甘いかなという気もします。本当は「CP932-面・区・点」の対応を全部テーブルにすればシンプルなのでしょうが、テーブルサイズが大きくなるので。    とりあえず、簡単なテスト・データで通る／はじくのテストまではできました。    【今日の日経平均】 10,295 +461

2002年02月20日（水）   CP932の外字っぽいもの 今つくっているプログラムは内部コードをJISの面・区・点で持っています。今まではEUC-JPのファイルだけを見ていましたが、CP932（MSのShift-JIS）の処理を入れるために、あやしそうな以下の部分を主にJIS X 0213との比較で再度調べて見ました。    ・NEC 拡張記号 83文字　　　　(0x8740-0x879C) - 13区  ・NEC 拡張漢字 374文字　　　　(0xED40-0xEEFC) - 89区〜92区  ・IBM 拡張漢字 388文字　　　　(0xFA40-0xFC4B)    NEC 拡張漢字とIBM 拡張漢字の漢字の部分  --------------------------------------  なんだか同じ漢字が別のコードにアサインされているだけのようです。  漢字以外はローマ数字などの記号がちょろちょろあるだけです。  ただ360種類ある漢字のうち、JIS X 0213にない文字が85種類もあったのは意外でした。あと記号ではUnicodeでいうところの「FULLWIDTH NOT SIGN」と「FULLWIDTH BROKEN BAR」もJIS X 0213にありませんでした。    13区  --------------------------------------  いわゆる丸数字などの記号がある部分ですが、なぜかUnicodeでいう  「N-ARY SUMMATION」がJIS X 0213にはありません。区点13-84はJIS X 0213ではReservedになっています。「GREEK CAPITAL LETTER SIGMA」があるのだから、いらないや、ということなのでしょうか。    複数文字コードの変換を許すとすると、内部コードも面・区・点というだけではなく、JIS X 0213などの特定の文字体系にしないとダメですね。ということはEUCもEUC-JPではなく、EUC-JISX0213であること、という前提にしないと、コード間の変換をした時にまずそうです。    CP932については、JIS X 0213にない文字は捨てて、それ以外のここにある部分の文字はテーブルを持ってJIS X 0213に変換しようかな、と考えています。変に振り替えるとややこしくなりますから。    【今日の日経平均】 9,834 -13

2002年02月03日（日）   JISとUnicode JISとUnicodeのマッピングは両者が共にまだ動いているため、今の時点で確定的な基準を求めるのは無理のようです。    Unicode側（www.unicode.org）では、日本語のソースとのマッピング・ファイルは1990年のJISX0208とJISX0212で止まっており、さらにそれはObsolete（廃止）扱いになっています。    JIS側ではUnicode 1.1とのマッピングがJISX0221-1995としてあり、去年の４月ごろそれの改定版らしいJISX0221-1:2001というのが出ているようです（JISX0221-1995は今では廃止扱いになっています）。    これの対Unicodeの対照部分がテキストファイルで配布されれば、基準として使えるように思えますが。

2002年02月01日（金）   UTF内での変換 UTF-8/16/32を相互に変換するプログラムを書いてみました。www.unicode.orgにあったharness.cを参考に    UTF-32→UTF-16→UTF-8→UTF-16→UTF-32と、  UTF-32→UTF-8→UTF-32    を0x0〜0x10FFFF（ただしUTF-32の0xD800〜0xDFFFは除く）の範囲でテストしてＯＫであるところまでは確認しました。    次はJIS圏とUnicode圏の変換ですが、これは何を基準テーブルとすればいいのかむずかしいところです。とりあえず22MほどあるUnicode 3.1.1のUnihan.txtをダウンロードしてきて中を見ているところです。    あとAdobe Acrobat Readerを4.05から5.05に更新しました。4.05ではAcrobat Accessというplug-inを入れないとテキスト化できなかった（しかも日本語はダメだった）のが、5.05では（データにロックがかかっていない限り）単体でテキストに出力できるようになっていました。    【今日の日経平均】 9,791 -206

さらに過去へ >