小形克宏の「文字の海、ビットの舟」
|
|
読者の皆さん、すみません。最初に謝っちゃいます。前回、最後にさんざん盛り上げた末に「ここで紙幅がつきた。次回をお楽しみに」とカッコよく終わったのだが、その続きを書けませんでした。ただ今2月1日の午後11時。メール版の配信予定時間まで、残すところわずか2時間。いわば崖っぷちの瀬戸際でございます。もちろん怠けていたわけではなく、ふだん一日10時間きっちり寝る私が、なんと毎日6時間しか寝ないでモニターに向かって頑張ったのだ。
そういえば、私は他誌で超遅筆で知られる後藤弘茂氏の担当編集者もやっているのだが、本紙の兄弟紙『PC Watch』の配信が時に夜明け近くになり、そういう号にきまって後藤氏の名前があったりすると、「後藤さんもやってくれるよなあ～」なんてメーラーをスクロールさせながら笑っていたのだが、まさか自分が同じ境遇におちいるとは。人を笑えば穴ふたつというやつである。あ、人を呪えばでしたね。
ことここに至っては、ない袖は振れない、書けないものはしようがないだろうと居直ってみたのだが、本紙編集部はさすがに手強かった。どうしても原稿を落とすことを納得してくれない。ま、普通そうだよな。
そこで、前回、第2回の原稿で、読者の皆さんからご指摘いただいた意見に対する訂正と補遺を、ここに掲載することにした。これと同じものはHTML版でも読むことができる。
ちょっと説明すると、私は自分の間違いを人知れず直すのではなく、自分がどこを間違えたのかも含めて読者の皆さんに知らせようと考え、本文に手をつけずに訂正文などを別記する形で掲載することにしたのだ。最初はこんなに訂正するようになるとは思わなかったのでこういう形にしたのだが、これだけ多くなると本文は直して、修整履歴を別記するという形にしたほうが親切かもしれない。
こうして読み直すと、我ながらよくもまあ、これだけたくさん訂正や補足を書いたものだと思う。自分の原稿に反響があるということに、単純に感動して舞い上がってしまったのかもしれない。しかも、この文章は調べものやらなんやらで、必要以上に時間をかけている。もちろんまず一番に、訂正や補足が山盛りで必要な原稿を書いた私の責任が問われるべきだが、その前に、ひょっとしたらこういうことばかりしていたから、本番の原稿が書けなかったのではないかという気もするが、いやいや、きっと気のせいでございましょう。
最後になったが、ここで取り上げられなかった方をふくめ、私の原稿に対して感想を送っていただいたすべての方々にお礼を申しあげたい。これからもアクティブに訂正をしていくつもり（おいおい……）なので、なにか気がついたことがあれば、どんどん編集部までお寄せいただきたい。
というわけで、今回はお茶を濁したが、きっと来週は前回の続きをお届けすることをお約束したい……なあ…………。
(2000.1.27)
◆形式変更のおことわり
最初は本文に手をつけずに、文末に原文と訂正文をつけていたのだが、訂正が多くなりすぎてかえって不便だとのご指摘をいただいた。そこで上述したように、本文を直し、文末に訂正履歴をつける形式にあらためることにした。また、この機会に、第２回の文末にあった同文の訂正と補遺を削除して、形式をスッキリさせた。
いやはや、間違いばかりの原稿を書いたことをお詫びするとともに、これからもビシビシ厳しいご指摘をいただければと思う。
なお、〈 〉は原文、《 》は訂正後の原稿をあらわす。
(2000.2.12)
◆訂正履歴
[訂正1]……読者の方から、日本工業規格は訳語ではなく正式名称であるとのご指摘をいただき修正した。
〈JISはJapan Industrial Standardの略称で、日本工業規格と訳される〉
《JISはJapan Industrial Standardの略称で、正式には日本工業規格という。》
(2000.1.27 同年2.12加筆)
[訂正2]……マイクロソフト株式会社より、以下のような指摘をいただいた。メールより引用する。
>具体的に気になったところは、
>1)「なぜ文字化けはおこるのか。違う文字コードとのあいだで変換に失敗するか
>らだ。」
>->
>2)「世界中の人々がUnicodeさえ使えば文字化けなしに情報交換できる」という論
>の運びです。
>最初の問題定義、そこからの解決策という運び方は着眼点も含めて非常によいの
>ですが、問題定義1)と解決策2)の間が(物理的に)離れすぎていて、読者に「そう
>か、Unicodeをつかえば文字化けがおきないのか」という早とちりをひきだして
>しまうようでもったいないと思いました。
>
>問題定義 1)のなかの着眼点：「違う文字コードとのあいだで変換に失敗する」を
>生かす形でUnicodeの解決策を述べるならば、もう少し丁寧に2-a) 「Unicodeを世
>界共通の文字コードとして使えば、違う文字コードとのあいだの変換で生じてい
>た文字化けは原理的に存在しなくなる。」と限定的に書いたほうが誤解が少ない
>と思います。
上記のご指摘にもとづき、以下のように修正した。
〈Unicodeは後者の手法であり、より徹底して、複数の言語というより世界中の言語を収容して、世界中の人々がUnicodeさえ使えば文字化けなしに情報交換できる――という、ユーザーにとっては夢のような世界の実現を目指したプロジェクトなのだ。〉
《Unicodeは後者の手法であり、より徹底して、複数の言語というより世界中の言語を収容する文字コードをつくり、これを世界共通の文字コードとして使って、違う文字コードとのあいだの変換で生じていた文字化けは原理的に存在しなくさせる――という、ユーザーにとっては夢のような世界の実現を目指したプロジェクトなのだ。》
(2000.1.27 同年2.12加筆)
[訂正3]……直井靖さんより以下のような指摘をいただいた。
[訂正3-1]
>>Unicodeは後者の手法であり、より徹底して、複数の言語というより世界中の言語
>>を収容して
>「言語」というより「スクリプト」じゃないですか？「スクリプト」が耳慣れない
>言葉だとしたら、「世界中の言語を記述するための文字」とか……。
直井さんのご指摘のとおりだ。「言語」という単語は、日本語とかドイツ語とか いった場合のひとつのまとりをあらわす。つまり「話し言葉」や「書き言葉」をふ くんだ、その総称ということになる。言葉について原稿を書こうとする人間にとっ て、初歩的なミスといえるだろう。なお、直井さんのおっしゃる「スクリプト＝ script」については、ただ今勉強中。今の私のような状態をあらわすのに、最適な 言葉がある。「泥縄」である。
(2000.1.31)
その後、スクリプトの概念を勉強して原稿に反映させた。しかし、こんな基本的なことを知らずに文字コードの原稿を書くとは……。我ながら呆れてものが言えない。下記の訂正にくわえて、スクリプトを説明する補注1を加筆した。
〈もうひとつが複数の言語を単一の文字コードの中に入れてしまう方法だ。Unicodeは後者の手法であり、より徹底して、複数の言語というより世界中の言語を収容〉
《もうひとつが複数のスクリプトを単一の文字コードの中に入れてしまう方法だ。Unicodeは後者の手法であり、より徹底して、複数のスクリプトというより世界中のスクリプトを収容》
(2000.2.12)
[訂正3-2]
>>それ自身のなかに世界中の多くの文字を含んでいるISO/IEC 10646（Unicode）は、
>>いったんプログラムをこれで記述すれば、日本語版であろうと、フランス語、ド
>>イツ語であろうと、はたまた中国簡体字版であろうと、中国繁体字版であろうと、
>>台湾版であろうと、韓国語版であろうと、部分的な修整でことがすむ。
>
>「Unicodeで記述すれば」というより「Unicode用のシステム・ルーチンを呼び出し
>て使用するプログラムであれば」というようなことでは？
これもまことにその通りで、けっして〈Unicode で記述すれば〉いいだけの問題 ではない。なによりもプログラムがUnicodeに対応していなければ問題にならない。 そこで、以下のように訂正させていただこうと思う。
・訂正前
〈それ自身のなかに世界中の多くの文字を含んでいるISO/IEC 10646（Unicode）は 、いったんプログラムをこれで記述すれば、日本語版であろうと、フランス語、ド
イツ語であろうと、はたまた中国簡体字版であろうと、中国繁体字版であろうと、 台湾版であろうと、韓国語版であろうと、部分的な修整でことがすむ。シフトJISに
はこういう拡張性がない。〉
・訂正後
《それ自身のなかに世界中の多くの文字を含んでいるISO/IEC 10646（Unicode）は 、いったんプログラムをこれで記述すれば、日本語版であろうと、フランス語、ドイツ語であろうと、はたまた中国簡体字版であろうと、中国繁体字版であろうと、台湾版であろうと、韓国語版であろうと、ISO/IEC
10646（Unicode）に対応したアプリケーションであるなら、部分的な修整でことがすむ。シフトJISにはこういう拡張性がない。》
(2000.1.31)
[訂正4]……山本もぐさんからの指摘により以下の点を修正した。
〈日本工業標準会〉
《日本工業標準調査会》
(2000.2.12)
[補遺1]……マイクロソフト株式会社より、以下のような指摘をいただいた。
>筆者の図式「符号化文字集合（文字コード）＝文字集合＋符号化方法」に従えば、
>「複数の文字コードを切り替えて使う方法」
>は図式右辺の文字集合そのものを丸ごと取り替えながら使う方法で、同一符号で
>もどの文字集合を使っているかで表現している文字が違ってくるのに対して、
>「複数の言語を単一の文字コードの中に入れてしまう方法」
>は図式右辺の文字集合を単一にして異なる符号には異なる文字が対応しているの
>で曖昧さが生じません。
筆者としては、考えもしなかった視点で、まさに目からうろこが落ちるような指摘であった。自分の考えを世に問う意味とは、まさにこのような反応に出会うためなのかもしれない。
この指摘じたいはISO/IEC 2022とUnicode（ISO/IEC 10646）を比較し、後者の利点をのべているが、ここでは、シフトJISとUnicode（ISO/IEC 10646）を比較し、より原稿の趣旨がつたわるように補足的に説明させてもらうことにしよう。
符号化文字集合（文字コード）＝文字集合＋符号化方法
シフトJISを上記の図式にあてはめてみると、以下のようになる。
シフトJIS実装機＝（0201＋0208＋機種依存文字）＋シフトJIS
なぜシフトJISを実装したコンピュータの間で文字化けを招きやすいか、この図式で分かりやすく理解できる。つまり右辺カッコ内の“機種依存文字”の項が、OSによって違ってしまうからだ。よって右辺の総和は各OSにより異なってしまう。
一方でUnicodeはどうだろう。これはちょっとややこしい。
Unicode＝Unicode文字集合＋さまざまな符号化方法
Unicode（ISO/IEC 10646）は文字集合として世界中の文字をふくめ単一固定化するものだ。その一方で符号化方法はいくつかある。それぞれの符号化方法によりアクセスすることのできる文字集合が違うので、厳密には等号ではむすばれないかもしれない。これは以下のような式であらわせられる。
UCS-2⊆UTF-16⊆（UCS-4＝UTF-8）[補遺1の訂正1][補遺1の訂正2]
つまり、UCS-4 と UTF-8は同じ範囲の文字集合をアクセスし、UTF-16によってアクセス可能な文字集合はすべてこれに含まれ、またUCS-2 の規定する文字集合は UTF-16に含まれる。
つまりすべての符号化方法がアクセスできる部分があることがお分かりいただけると思うが、この部分こそが現在制定がほぼ終わり、実装がすすみつつあるBMP（Basic Multilingual Plane、基本多言語面）であり、およそ64,000文字を収録する。0208の6,879字と比べると、これがいかに膨大な数かわかるだろう。
Unicodeの利点は、この現在使用可能なBMPに収録された文字をあつかうかぎり、どのような符号化方法でも文字化けしない、言葉をかえれば符号化方法が変わっても文字化けしないということだ。
しかし、最後の最後でちゃぶ台をひっくり返すようなことを言って申し訳ないが、0208もUnicodeも文字集合の非互換な変更（従来空欄だった区点に文字を追加するのではなく、入れ替えたり、変更したりする変更。文字化けが発生するので、文字の符号化で絶対やってはならないことのひとつ）をおこなっているおり、バージョンによって文字集合が違うということは指摘しておきたい。勘のいい読者なら、すでにお分かりかもしれないが、本文中で説明をさけたUnicodeとISO/IEC 10646の違いも、このUnicodeのバージョンに依存する。
以上、まったく用語を解説しないで文章を書いた。ここででた難解な用語、特にUnicodeの符号化方法については4回以降の原稿で解説していくつもりだ。
(2000.1.27)
高橋征義さんより、以下のような指摘をいただいた。
>さて、先日の連載での補遺、
>/www/column/ogata/part1_2.htm
>を読ませていただいたのですが、2点ほど気になる点があります。
>一つ目は、シフトJIS実装機を
>
> （0201＋0208＋機種依存文字）＋シフトJIS
>
>と規定しているところですが、この「0201」を素朴に導入してしまうのは
>問題があるのではないでしょうか。これではいわゆる「￥問題」が説明
>できません。0201とASCIIを曖昧なまま使い続けてしまったつけが、
>文字化けの一端となっている以上、何らかの形で言及してほしいと思い
>ます。もっとも、ここに触れると分かりにくくなってしまうので、深入りを
>避けたということであれば、それも一つの見識かとは思いますが。
>
>もう一つは、
>
> UCS-2＝UTF-8⊇UTF-16⊇UCS-4
>
>という式です。正直、符号化文字集合であるUCS-2、UCS-4と、
>符号化方式であるUTF-8、UTF-16が並列しているところから気になる
>のですが、それはおくとしましても、このUTF-8の位置付けは問題なの
>ではないでしょうか。UTF-8はUTF-16よりも大きく、UCS-4と
>同じ広さを持ちますよね？
>IETFでUTF-8を規定しているRFC2279では、
>
>(略)
>0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
>0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx
>
>という例すら示して、UTF-8が31ビットの空間を持つことを述べて
>います。あるいは単純なミスかもしれませんが、そうであれば訂正して
>いただけたらと思います。もし私の理解が違っていましたら、申しわけ
>ございません。
どうやら筆者の一夜漬け、付け焼き刃がここで一気に露呈されてしまったようで、なんともお恥ずかしいかぎりだ。たぶん“馬脚をあらわす”という表現は、こういうときに使うのだろう。
まず指摘の1、つまり0201における「￥問題」について。これについては高橋さんも薄々お分かりのとおり、じつは承知のうえで一緒、というより埒外にしたので、訂正はご容赦いただく。つまりこの式は、アメリカ英語の文字コードであるUS-ASCIIとの関係を問題にしておらず、シフトJIS実装機間の文字化けを説明しようとしたものだからだ。
ただしこれはとても根元的な問題をふくむので、この機会にくわしく書きたい。もちろんこれは私の理解なので、もしも誤解があれば読者の皆さんにはどんどんご指摘いただきたいと思う。
高橋さんはUS-ASCIIとその日本版規格JIS X 0201との間の文字の違いをおっしゃっている。US-ASCIIは'63年に制定され、のちに世界中の文字コードの基本になったもので、各国の文字コードはUS-ASCIIを発展させるかたちで制定した歴史がある。これをつかう限り文字化けがおこらないゆえんである。US-ASCIIは7ビットコードだ。
ここでちょっと脱線して、この“○ビットコード”という言葉を説明する。たとえば7ビットコードとは、“コードポイントを7桁の2進数（7ビット）であらわす文字コード”という意味だ。7桁の2進数であらわすことのできる数は、2の7乗で128。つまり7ビットコードは128の文字をコード化できることになる。同様の計算で、0201などの8ビットコードは2^8=256文字、現在のUnicode、つまりUCS-2などの16ビットコードは2^16=65,536文字、Unicodeが最終的に目指すUCS-4の32ビットコードにいたっては、2^32=4,294,967,296、つまり42億9496万7,296文字。気が遠くなりそうな数だ。
ところで、この○ビットコードの文字数をもとめる計算式というのを、私はいつもすぐに忘れてしまい、そのたびに友人に恥をしのんで聞くか、7ビットは7の2乗だっけ、いや2桁2進数は、00、11、01、10、なるほど4か、では2×2で、ということは……などということをグルグル考えなければならないハメにおちいる。なぜなら、このような英語のABC、日本語のあいうえおにあたる初歩の初歩の計算式が、
「どの文字コードの本にも書いていない」[補遺1の訂正1の訂正A]
からである。どうやら現在文字コードを語るには、上記の計算式がごく当然、言わずもがなの了解事項でなければいけないらしい。算数音痴の私としては、同じ轍を自分の原稿でおかしていた心苦しさが、この文章を書くことで解放でき、ほっとしている。
話をもどす。US-ASCIIは7ビットコードだが、ここで規定された94文字（残りは不可視の制御用符合）ではウムラウトが必要なドイツ語、セディーユ[訂正4]が必要なフランス語などは表現できない。そこで、94文字のUS-ASCIIのうち、12文字をてきとうな自国の言語の文字に入れ替えて使い、残りのアルファベットの大文字・小文字などはUS-ASCIIそのままという規格が考えられた。つまり、これを使えば大筋では判読が可能な情報交換ができるわけだ。これこそ'67年に制定されたISO/IEC 646であり、この枠組みを使って日本、イギリス、ドイツ、フランス、スウェーデンなど、多くの国の言語で対応バージョンがつくられた。
日本の文字コードの基本であり、US-ASCIIの日本版規格、JIS X 0201は、'67年に制定された。つまり上記のISO/IEC 646と同年であり、ヨーロッパ各国に先駆けて作られたものだ。これは8ビットコードの枠内に、ローマ字94文字、カタカナ他を63文字、あわせて157文字を規定する（残りは保留域と制御符合）。このうちローマ字部分は上記ISO/IEC 646の枠組みを使って配置されており、つまり大ざっぱにはUS-ASCIIと互換性がある。
今、「大ざっぱに」という書き方をした。これが高橋さんの言われる「￥問題」である。0201では、US-ASCIIのバックスラッシュ、つまり“/”の逆向きの記号のコードポイントに“\”をおいた。このため例えば「\1,200」という1200円をあらわす0201の数字の文字列を、US-ASCIIに変換したとたんに“\”の文字が化けてしまう。
もちろんISO/IEC 646の枠組みを使ったのだから、US-ASCIIと違う文字があり、ここで文字化けがおこるのは当たり前なのだが、この“\”とバックスラッシュを、運の悪いことに80年代になって、マイクロソフトがMS-DOSやWindowsで、ファイルの位置を表記する際の区切り文字として使うようになり、混乱は拡大してしまった。区切り文字はファイル名などで使用禁止となるなど、特殊な属性を与えられるのでだ。ここでは詳しく書かないが、たとえばアメリカ英語版のアプリケーションを日本語版にローカライズしたり、逆に日本語のアプリケーションをアメリカ英語版にする場合、プログラマーはややこしい処理を強いられることになる。
以上が「￥問題」のあらましである。より詳しくは『文字コードの世界』（安岡孝一・安岡素子著 東京電機大学出版局）の第2章、それに『パソコンにおける日本語処理／文字コードハンドブック』（川俣晶著 技術評論社）の82ページ以降を参照してほしい。
さて、次に指摘の2。これはUTF-8はBMPにしかアクセスしないと思っていた私の間違い。正直にいえば、高橋さんがおっしゃるような「単純ミス」ではなく、「理解不足」といった方がよい。また、これについて前寺正彦さんからも同様のご指摘をいただいた。
・訂正前
〈UCS-2＝UTF-8⊇UTF-16⊇UCS-4〉
・訂正後
《UCS-2⊇UTF-16⊇（UCS-4＝UTF-8）》
(2000.1.31)
▼[補遺1の訂正1の訂正A]
この点について、他ならぬ川俣晶さんから以下のようなご指摘をいただいた。
> 拙著の「パソコンにおける日本語処理／文字コードハンドブック」の冒頭(11
> ページ)にて、ビットを何個集めると、何種類の数値を表現できるかを記述して
> います。
> 一応、2のべき乗で増加すると書きましたが、これでも分かりにくいでしょう
> か? 2^(ビット数)のように数式の形で書いた方が良かったでしょうか
この本を、まるで教科書のように何度も読んで勉強した筆者のとっては恐縮のいたりである。もちろんこのご指摘の部分は読んでいた。しかし、情けないことに筆者は“べき乗”という表現が脳味噌のどこにもヒットせず、わけも分からないまま読み流していたのでございます。トホホ。算数音痴の開き直りととっていただいても結構だ。ただ、“べき乗”という概念をあらわす単語で説明するよりも、思考の道筋をたどれるような数式をしめした方が、一見むずしそうだが、かえってシロートには分かりやすいんですよ～、ということは、ちょっと言わせてください。
〈このような英語のABC、日本語のあいうえおにあたる初歩の初歩が、〉
《このような英語のABC、日本語のあいうえおにあたる初歩の初歩の計算式が、》
(2000.2.12)
[補遺1の訂正2]
羽毛田信拓さん、高橋征義さんより指摘があって、集合記号の向きが逆であることが判明し、修正した。いやはやなんともお恥ずかしい限りだ。慣れないことをするもんじゃない。
〈UCS-2⊇UTF-16⊇(UCS-4＝UTF-8)〉
《UCS-2⊆UTF-16⊆(UCS-4＝UTF-8)》
(2000.2.12)
[補遺1の訂正3]
Nob.Koikeさんから「符号」と「符合」が混ざって使われているという指摘をうけた。単純な筆者の間違いであり、「符号」に統一した。
(2000.2.12)
[訂正4]…… 伊藤弘樹さんより原稿中のフランス語発音記号「セディラ」は、それぞれ「セディーユ」の間違いであるというご指摘をいただき、修整した。ああ恥ずかしい。
(2000.2.22)
(2000/2/2)
[Reported by 小形克宏]