T.MURACHIの日記: Unicode と機種依存文字 12
昨日の日記で機種依存文字と UTF-8 (Unicode) に絡むコメントがあったので、仕事そっちのけで Unicode 周辺の基礎知識と雑感をちろっと。
Unicode を使えば機種依存文字を気にしなくて済むようになるのか? 理論的には、それは可能です。なぜなら、機種依存文字を使用しているプラットフォームで、それらの文字を Unicode 内の該当する文字が存在する番地にマップしてあげれば良いからです。表示上、同じ形・意味合いの文字 (および記号文字) が Unicode に存在しさえすれば、プログラムが機種依存文字を適切な Unicode に変換することは可能です。Unicode に対応したフォントマップを持っている環境同士であれば、もはやそれらの文字は機種依存文字ですらない、共通に使用可能な文字ということになります。
理論的にはね。
実際にはいくつかの問題があります。日本語の一般的なコード体系である JIS と Unicode の相互変換について、その問題点を簡潔にまとめられたサイトがあります。まず大前提として、現状、JIS と Unicode の相互変換を実現する為の、規格化された正式な変換表というのは存在しません。 Unicode Consortium で配布されている変換表も正式なものではないということになっています。
機種依存文字について、該当する文字をマップに追加することはできるけど、それに伴って行なうべき変換プログラムの実装についてまでは世話は焼ききれないよ、と言うのが Unicode のスタンスなのかもしれません。
プラットフォームを隔てた文化的な考え方の差異と言う問題もあります。例えば JIS 規格には 1 バイトの文字を定めた JIS X 0201 と、2 バイトの文字 (漢字等) を定めた JIS X 0208 が存在します (本当は第3水準漢字などを設定した JIS X 0212 なんてのもありますし、EUC-JP や ISO-2022-JP では使用可能だったりしますが、Shift-JIS が対応していないからか、あんまり使われていません)。 この中で、 JIS X 0208 は ASCII 文字セットの 0x5C ("\" / バックスラッシュ) と 0x7E ("~" / チルダ) を、それぞれ円記号 ("¥")、オーバーライン (" ̄") に置き換え、さらに半角カタカナを加えたようなものとなっていますが (詳しくは こちらのサイト などを参照ください)、現状、ほとんどのプラットフォームで 0x7E は ASCII 本来のチルダとして表示されていたりします。しかしこの古臭い規格を信用してしまった Unicode Consortium が配布した変換表では、 0x7E を、確実にオーバーラインが表示されてしまう U+203E に変換してしまいます。
逆に、Microsoft が日本語版 Windows に実装した Shift-JIS との変換表である CP932 を使用した場合、ASCII 文字セットの 0x5C は、そのまま ASCII 互換の Unicode である U+005C に置き換えます。これが意味するところは何かというと、Windows で半角円記号を含むテキストを Unicode に変換すると、変換したテキストの円記号は全てバックスラッシュで表示される。。。のではなく、Windows が Unicode 用に用意しているフォントセットの U+005C に割り当てられた文字が半角円記号である、と言うことです。なんということでしょう、バックスラッシュが表示されることを期待して Unicode 化されたテキストを配布しても、日本語版 Windows では円記号として表示されてしまうのです。これでは、 Unicode が Unicode として存在する意義の一部が失われてしまうことになってしまいます。
# IE が Unicode のテキストを表示する際に使用するフォントでは、 U+005C はバックスラッシュであったような気もします。良く覚えていませんが。
日本語のUnicodeベンダ依存文字表 というサイトがあります。これなんかは非常に参考になるのですが、Windows 95/NT (おそらく CP932) が Fullwidth (全角) の文字を積極的に使用しているのが非常に特徴的です。ここにも、プラットフォームを隔てた文化の違いが見て取れるのではないかと思います。
で、一般的に言うところの機種依存文字と言うのは、ここまで書いてきたような、プラットフォームによっては微妙に扱いが異なる文字のことではなくて、Shift-JIS で言うところの IBM 拡張文字や NEC 拡張文字などと言った類のものを指します。代表的なものに、囲み数字や数学記号などが挙げられます。そもそも機種依存文字ってなんなのよ、という話は こちらのサイトなんかが詳しいです。
んで、そのサイトなんかにも終わりにちろっと書かれていますが、基本的にはこれらの機種依存文字は全て Unicode に収録され、フォントとアプリケーションさえ対応すれば、 Unicode を使用することで、今まで機種依存文字とされてきた文字は全て機種依存ではない文字として扱うことができるようになりました。やった!
ならそれで大体問題ないんじゃないの? と言いたいところなのですが、 Windows の CP932 と Unicode の間で往復変換ができない 問題なんてのもあったりします (リンクは Perl で CP932 を適切に扱う為のモジュール ShiftJIS::CP932::MapUTF のドキュメント日本語版…最近は CP932 にもちゃんと対応した Encode.pm なんてモジュールもあるから、Jcode.pm の代わりにそれを使うことになるのかな?)。もっとも、Unicode だけを使うことを考えれば相互変換の問題というのはあまり気にならない部分だとは思うのですが、Unicode への移行を難しくしている部分ではあると思います。
その他、参考リンクをいくつか無責任に貼り付けて見ましょう。こちらのサイト では、Unicode における「CJK 統合漢字」「CJK 互換漢字」について扱われています。全角英数字が互換領域に割り当てられていることなどにも触れられています。 こちらのサイト は日本語の Unicode におけるマッピングルールについて実に多彩な情報が網羅されています。他にもこの問題について触れられているサイトはいろいろあるみたいで、探してみると結構面白いですよ。
Unicodeと言えば思い出す~ (スコア:1)
時代が違うので参考にはならないかもしれませんが, むかーしの情報処理学会の学会誌のエッセイ(誌面討論会と言う方が正確か?)で こんなの [teu.ac.jp]がありました. 誌面の一部なPDF版もあるようです.
今みたいにUnicodeが流行る前(今も流行ってるかはアレですが)のお話なのですが, 当時は『ふーん』って感じで読んでました.
久しぶりに探して読み返したのですが, 外来語云々で話題の国立国語研究所の方も意見を述べてますね:-p
Re:Unicodeと言えば思い出す~ (スコア:1)
非っ常に興味深い資料のご提示ありがとうございます (^_^)。本当はこの辺の事柄についても突っ込んでみたかったのですが、そこまで触れられるほど知識・経験共に豊富ではなかったもので。。。
紹介されている記事からはもうだいぶ時が経ち、既に Unicode を用いたシステムが動き始めてしまっている現状において、これと同じ議論を再び繰り返すことが有益であるとはさすがに思えなくなってしまいましたが、既存のコードからの移行ということを考えた場合に、このような議論があったことを知っておくというのはとても重要なことではあると思います。
ぶっちゃけ、 Unicode っていう考え方は、文字体系の国際化っていう観点では必要なんだけど、解決手法が必ずしも効率的ではないというか、設計がなっていないといわざるを得ない部分は多々あったわけで。 CJK 一絡げという問題もそうですが、 JIS という過去の資産がないがしろにされ、マンパワーで変換マップをでっち上げるというやり方は、情報処理技術のあり方としてそもそもスマートではないわけで。
しかしそんな一時の言いがかりも、ひとたび広まっちまえば後の祭り、勝てば官軍。悪貨は良貨を駆逐し、良貨が駆逐されちゃえば、悪貨も良貨に見えてきちゃう。いま、 Unicode が存在して、ふつーに動いている現実だけを目の当たりにしている人たちからすれば、「なんでみんな Unicode にしないんだろー??」となるのはアタリマエなわけで。。。知らないって、シアワセだよね ;-p 。
紹介してくださった記事の中では、三菱総研の新部氏のご意見が最も共感できます。もっとも、Mule は使ったことがないので (もっと早くから UNIX に積極的に触れていればとつくづく。。。;_;/) 実体験に基づく賛意ではないのですが、システムによって使える文字が制限される状況にユーザーが甘んじるのではなく、使いたい文字 (が収録された文字コード) をユーザーが自由に選択できるような「システムを作る」ことが大切なんだ、という方向性はまったくその通りだと思います。
例えば、XML のようなメタ言語を使う方法でも、それは実現できるんではないかなぁとか思わなくもなかったりするんですけどね。国際化対応テキストとでも称した XML フォーマットがあって、DTD が定義されていて、要素の属性で文字コードの種類などが指定できて、要素にはさまれた CDATA に、指定した文字コードを使ったテキストを入れてあげちゃうとか。属性には文字コードの種類だけでなくて、ベンダー情報なんかも入れられれば、機種依存文字にも対応できちゃったりして、かなり幸せかも。 Web でやり取りする情報も、こういうレイヤーで行われれば、必ずしも決めうちの万国共通文字コードをでっち上げる必要はなかったりするんではないかなぁと思わなくもないんだけどね。
# 実際には文書定義の段階で文字コードを定義しちゃうし、実体参照なんてものもあるので、XML という枠組みでこれを実現するのはちょっと難しいんだけどね。
国立国語研究所の方のご意見は、かなり参考になるし重要なご意見だと思うのですが、高度すぎて、整理しなおさないとおいらの頭では処理しきれないっす (^_^; 。ちなみに、「斎藤秀紀」の名でぐぐってみると、一番目に こんな記事 [kokken.go.jp] が Hit したのですが、この中の議論、とくに理論コードを使い続けてきたという辺りや、漢字データベースに関する辺りのお話は、非常に興味深いし、参考になります。こういう考え方を背景にお持ちの人なんだな、と思いながら、紹介してくださった記事を読み返してみると、またちょっと違った趣があるかもしれません。
# しかし沖電気の漢字テレックスの話題は相当アレゲだな。。。実物触ってみてぇ~ (@_@) 。
むらちより/あい/をこめて。
Re:Unicodeと言えば思い出す~ (スコア:1)
すんませんリンク先間違えてました、こちら [horagai.com] でございまする。。。orz
むらちより/あい/をこめて。
Re:Unicodeと言えば思い出す~ (スコア:1)
まぁ 結局今はなんだかんだ言っても Unicode を使わなければいけないような状態になっちゃってますからねぇ.
例えば はしご高 とか人の名前に使われてるわけで そういった漢字を扱える標準規格って現状でUnicodeくらいでしょうし.
NEmacs→Mule→Emacsと使ってきているので Muleそのものは使っていたのですが 『国際化されてるんだぜ』とは言っていたものの『フォントをインストールしてないから表示できねー』ってオチがつきました.
XMLの話は 現状におけるエスケープとかによる切替をタグを使ってやるって感じですかね.
『JISという資産がもったいない』という話が出てくると Mail/News のheaderにおけるSubject: フィールドなんかのMIMEな話とかが思い出されます.
あぁ いかんいかん昔話だらけになってしまう:-p
それに今ならMIMEの演算もたいしたことないでしょうしね.
国立国語研の方は……すごいですねぇ. 探していただいたページを読んで素直にそう思いました. もうトンデモ研究所 [srad.jp]なんて言わせないぞ:-p
うーん@_@ (スコア:1)
あたしのサイトにこのエントリーを重要参考人としてリンクさせていただきます。
// ちなみにあたしのサイトは腐海です。
// まだ、Googleに解放していないので探しても今のアドレスは見つかりませんけど:P。
----
:oすずめのおやどはどこじゃろぉ
('>ぴよぴよ
Re:うーん@_@ (スコア:1)
えへへ、おいらも結構、書きながらアップアップしてたのは秘密(w。なんだかうまくまとめられないうちに、本当に業務時間のかなり多くを割いてしまったことに気がついて、慌ててエントリーしちゃったのも秘密 ((((((/^^)/ 。
ただ、この辺について探っておくのは、 Unicode を扱う上での「クセ」を知ることになって、既存コードとの変換を Web アプリとかで扱う際にはそれなりに役に立つと思うので、少しずつでも噛み砕いてゆくのは、損なことではないと思います。
# 思わぬ反響に若干戸惑いつつ ID (^_^;
むらちより/あい/をこめて。
実は… (スコア:1)
「一時期香港POPsに興味を持って中国語(簡体中文)での(歌詞の)入力に挑戦し、面白いのでサイトの一部に中国語を使ってみたかったから(歌詞を使用した訳ではありません)」
なんです:P。
そこから「今までうまく書けなかった複数の言語(特に2バイト文字と呼ばれる)を気軽に一つのファイルで「文字として」表現できれば良いなぁと。
何故なら、中国語学習系サイトを見た時に肝心な中国語はグラフィックで表示されてるところばかりで(勿論S-JISやらEUC-JP使ってればそうするしかないのですけど)「勿体ない」と思ったからです。
機種依存文字とUnicodeに関して考えたことはあまり無くて、あたしのサイトで使ってる「記号」があまり重要な部分じゃないって言うのもあって気づいてても放置していたのが事実:P。
多分フォントによって表示できない文字(UTF-8でも)があるので(って言うかあたしのサイトでそれを実際使っちゃってたので:P)、ウェブに公開する文書はできるだけ記号は使わないに超したことことは無いと思ってますけど。<と言いつつ今はリンゴマーク使ってますけど:P。
>本当に業務時間のかなり多くを割いてしまったことに気がついて
ご苦労様でしたm(__)m。
>ただ、この辺について探っておくのは、 Unicode を扱う上での「クセ」を
>知ることになって、既存コードとの変換を Web アプリとかで扱う際には
>それなりに役に立つと思うので、少しずつでも噛み砕いてゆくのは、損な
>ことではないと思います。
(引用に改行を入れさせていただきました)
そですよねぇ。
ぼちぼちっと噛んでみます。
まるで塩昆布か何かみたいな…。
----
:oすずめのおやどはどこじゃろぉ
('>ぴよぴよ
微妙なところですが、フォントの問題では? (スコア:1)
ということで、これは変換表の問題ではなくて日本語フォントの問題なのではないでしょうか?
腐乱化…もといFlanker
Re:微妙なところですが、フォントの問題では? (スコア:1)
Re:微妙なところですが、フォントの問題では? (スコア:1)
腐乱化…もといFlanker
Re:微妙なところですが、フォントの問題では? (スコア:1)
0x5C が円記号として表示されるのが日本語フォントだけなのは当然です。なぜなら、非日本語フォントは JIS X 0201 を知らないからです。
問題はむしろ、Windows が標準でつんでいる日本語フォントが、ちゃんと JIS X 0201 に準拠していない (これは 0x7E がチルダとして表示されてしまう方のお話) ことにあります。
Unicode に変換する際に、実際の表示に合わせるのが正しいか、それとも ASCII 文字セットの一部として扱うのが正しいのかについては、微妙なところです。 ISO 646 によるプラットフォーム間の相違は、技術者層の人間には周知の事実で (つまり、MS-DOS 由来の Windows と Unix とで 0x5C の表示が異なるのはアタリマエだし、コンパイルが通ればまあいいよぐらいに思われていることが多い)、むしろ ASCII 文字が ASCII 文字として扱われないことの方がややこしさを覚えます。しかし、非技術者層の人間からしてみれば、今、表示されている文字こそが、真実であり、正義なのです(w。
むらちより/あい/をこめて。
Re:微妙なところですが、フォントの問題では? (スコア:1)
ぁぅ、そっちは確かに問題ですね orz
この辺は全てM$が日本語DOSを作ったときにさかのぼる問題なのだ・・・
っていうか、こういう文字コード関係にお詳しいのでしたか。脱帽・・・
ところでむらちさん・・・部員1号なんですから変なもの部の方も忘れないでくださいね(苦笑)
腐乱化…もといFlanker