kubotaの日記: Unicode vs ISO-2022 5
日記 by
kubota
なんでみんな、こんなに感情的になるんだろうね。もっと具体的に事務的に、こっちにはこんな問題があり、あっちにはこんな問題があり、それぞれどれくらい改善される見込みがあり、どんな回避法が考えられ、ということを議論しなきゃ。「いろんな問題がある」とか「クソ実装」とか「よく分かってない人」とかの言葉は、情報量ゼロだし参考にならない。
けっきょく、具体的な内容の議論から逃げているように思えるのだが、どうだろうか。
ぼくとしては、そんな「理想的」なシステムよりも、われわれ日曜プログラマが現実的な手間で実装できる、そこそこ使えるシステムに興味があるのだが。そのための手段は、なんでもいい。
日本語について言えば、いま普及しているさまざまなシステムで使える程度と同程度のものができれば、それでいい。もちろん、それ以上のものであってもいいし、そのほうがいいが。そして、Unicode に基づく国際化ソフトウェアが、現在の日本語ソフトウェアと同等のレベルに達するための要件として、
- 漢字統合に基づく、フォントのデザインの問題
- JIS ←→ Unicode 変換テーブルの問題
- 全角・半角の問題
を挙げたのだが。
Unicode 対 ISO 2022 (スコア:1)
Unicode 絡みになると宗教戦争になるのは昔からですので, いまさら驚きはしません. 何にも考えていない欧米人がいるのも,昔からのこと. といって日本人のレベルだって大して高くないのは, 何年か前に盛り上がった JIS 漢字コード批判でわかるとおりですが.
漢字のフォントについては,Unicode は 「上位レベルで言語指定をつけてフォント切り替えをすればよい」 という立場だし, 「必要ならば言語タグを使えばいい」 といって言語タグ用コードポイントも追加したから, それでいいということなのでしょう. 「ISO 2022 の時は区別できていた」といっても, だいたい ISO 2022 のときは JIS X 0208 の日本の漢字と GB 2312 の中国の漢字との間に, 「この文字とあの文字とは同じ文字である」 という関係すらなくて, まったく別の文字扱いだったから, フォントも別々にならざるを得なかったわけです. その結果,「日本語であると中国語であるとにかかわらず, ある文字を検索したい」という処理は逆に難しかった. (「『毛沢東』が一発検索!」じゃないけれど, その点では Unicode の方が便利.)
「プレーンテキストでも日本語と中国語とが区別できる」 というのは,そういう意味では,ISO 2022 という 枠組みを使っていた結果 たまたま 出てきた特質であって, Unicode にした結果,こんどはその特質がなくなって 別の特質が出てきただけのことです.
たとえば,ISO 646 では ASCII に相当するコード表 (ここでは「符号化文字集合」のことをそう呼ぶことにします) に 「各国版」があって,たとえば「ISO 646 の英国版」では ASCII の # の位置に £ を置いていました. ISO 646 の米国版 (ASCII) と英国版とを ISO 2022 の制御シーケンスを使って切り替えて使えば, 「プレーンテキストでもイギリス英語とアメリカ英語とが 区別できる」わけですが, それで便利になるのはスペルチェッカーくらいのものです. しかし,ISO 646 のケニヤ版なんてないから, 「スワヒリ語を区別したい」なんて言われてもできない. ISO 2022 でできる言語識別なんて,その程度のものです.
漢字に話を戻せば,日本・中国・台湾・韓国は ISO 2022 の 枠組みのコード表があったから区別できるけれど, たとえばベトナム語漢字のコード表はないので 区別はできないのです. たとえば「胡志明」という名前のベトナム人指導者がいましたが, この人の名前をベトナム風 (というのがあるかどうかも知りませんが) に表示したいといっても ISO 2022 では無理なわけです.
一般論ばかりで済みませんが, 与えられた環境の制約のなかでなんとかするしかないので, どうしても日本語と中国語とでフォントを区別したければ, それを識別できる情報をどこかに埋め込むしかありません. (デフォルトを日本風フォントにするか中国風フォントにするかを 選べるようにするとか,選択を許す必要もあるでしょう.) プレーンテキストでやりたいと言われれば, 「できない」としか言えません.
ISO 646 問題 (スコア:1)
Unicode における漢字統合の最近の動向について、 新 しい日記項目 [srad.jp]に書きましたので参照ください。Unicode の重要なところは、文句を言えばなんとか対応してくれる、 ということです。対応すればするほどどんどん規格としては汚くなっていきますが。
にしても、ぼくは文字コード問題に足をつっこんで まだ 1、2 年程度の新参ですが、ぼくみたいなぺーぺーが Unicode Consortium に対してまだ文句を言う余地がある (そして、その文句に対して改善が行われる)、という現実があります。 これは、Unicode の不完全さを物語るよりは、 Unicode に対して文句を言う人がいかに少なかったか、 ということを物語っているのではないかと思います。 Unicode に対する正しい批判は、日本国内でこそこそ陰口をたたいたり アジテーションするだけではなく、 正々堂々と Unicode Consortium に対して言ってほしいものです。 ところで、ISO-2022 に対する批判を、陰口じゃなく言いたいときは、 どこに言うのが正しいのでしょうか?
ところで、ISO 646 といえば円記号問題ですね。 ISO 646 日本版では 0x5c がバックスラッシュではなくて円記号であり、 シフト JIS の構成部分として現在も広く使われています。 (ちなみに、シフト JIS と EUC-JP を変換するとき、 0x5c は互いに変換できないはず、なんです。かたや JIS X 0201 の円記号、かたや ASCII のバックスラッシュなので。 それを「そのままのコードポイントを保存する」という方法でやりすごしている、 あらゆる変換ソフトウェアは間違いなのですが、 このへんをソフトウェアの側ではいかんともしがたく、 人間の側に読みかえるなり解釈でなんとかしてくれ、 というあたり、この問題の解決の難しさが見えているようです。)
ヨーロッパ諸国は ISO 646 から ISO 8859 に移行するとき、 当然のこととして文字化けを伴う移行の苦しみを経験しているはずなんですが、 どうやって、それを切りぬけたんでしょうか。興味があるところです。 (それとも、ISO 646 など最初からほとんど普及していないとか、 現在でも DOS/Windows の世界では ASCII 非互換なエンコーディングが 使われているとかで、大がかりな移行は一度も行われていないのでしょうか?)
[unicode.org]Re:ISO 646 問題 (スコア:1)
ISO/IEC 2022 を規定しているのは ISO/IEC JTC1 SC2 なので, これに対して言いたいことがある場合,対応する日本委員会である 情報処理学会 情報規格調査会 [ipsj.or.jp]に設置された SC2 専門委員会に言うことになります. 委員長は慶応大学の石崎先生です. 「文字コード標準体系専門委員会」という委員会もあるようですが,こちらは,中間報告を見る限りでは,JIS X 0208 や 0213 のような規格に文字を選定する際の基準とか,手順とかの話をしているようです.
「シフト JIS」というのを JIS X 0208:1997 の「附属書1 (規定) シフト符号化表現」のことだとすれば,そうでしょうけれど, Microsoft Windows 3.1 以降の「コードページ 932」のことだとすれば,そうとも言えないわけです (あれは,表示上は円記号にして,Unicode に変換すると U+005C [バックスラッシュ] になるので).
同様に,「日本語 EUC」についても,円記号問題については曖昧にしています. これについての正式の規定は「UI-OSF-USLP 共同技術資料: 日本語EUC の定義と解説(1991年12月12日)」です. UI-OSF 日本語環境実装規約 [li18nux.org]に附属書 C として再録しています. たしかに,定義の部分では ANS X3.4 (ASCII) になっていますが,後ろの解説の部分では JIS X 0201 ローマ文字でもよいと読めるように書いたし,さらに言えば JIS X 0208 については,何年版かをはっきり書いていないし.(日付を見ていただければわかる通り, Unicode 以前のものなのですが.)
10年以上前に, 英国で印刷された C プログラムを見たことがありますが, #include が £include になっていて, なんとも奇異な感じを受けたものです. Keld Simonsen が ISO 646 互換をうるさく言っていたくらいだから, ISO 646 は使われていたのでしょう. それ以外にも,IBM PC 互換機 + MS-DOS の時代に コードページ 437 や コードページ 850 もあったでしょうし,他の機種も入れれば, DEC-MCS や HP-ROMAN8 や MacRoman なんかもあったので, 文字化けもあったでしょう. [参考資料 [kostis.net]] (それとも,それだけ混乱していれば 「とにかくコード変換する」 で一本槍の方針も採りやすかったのか.)
Re:ISO 646 問題 (スコア:1)
書き漏らしていたので,少々補足します.
円記号問題を標準化の立場から解決できないか, という話が何年か前に (いや,もう何年も前に) 出たことがあり,反対した覚えがあります.
というのも,規格としては JIS X 0201 ラテン文字集合の 0x5C は円記号で,ASCII の 0x5C はバックスラッシュで,それらの間に何ら関連付けはないということで完結していて, 新しく規格として解決するとなると,
標準化に閉じた世界ではたしかに解決になるだろうけれど, 誰も使わなさそうな規格が出てくるだけにしかおもえませんでしたから.
それから, これまでシフト JIS と日本語 EUC との間でコード変換するときは, 0x5C のコードポイントはお互い同じものとして扱っていたのに, Unicode との対応表が出てきたとたんに 「厳密な定義を見れば違うから,その変換は間違いだ」なんて いわれても,困りますよね. なんか,あとから小手先で問題を解決しようとして,かえって墓穴を掘っているような気がするのですが.
Re:ISO 646 問題 (スコア:1)
なるほど、「円記号問題」はほっとくのがよさそうですね。
でもわれわれはバックスラッシュと円記号を読み替えるのに慣れているけど、日本のパソコンユーザのほとんどはそうではない。というわけで、MS の、「CP932 の 0x5c は Unicode の U+005C で、U+005C は円記号」という、ワケワカだが実はそれしか方法がない、ということになるわけだ。でもじつは MS は 0x5c を特別な意味 (パス名の区切り) に使っているという事情があるということにも重要な意味があって、実際、Apple のマッピングテーブル [unicode.org]は 0x5c を U+00A5 に対応づけています。