文字化け

文字化けと言うのは永遠に解決しない問題なのだろうか？昔々わたしがまだこの業界に入って間もないころ数々のエンコーディングがあってその混沌たる世界は標準化によって解決できるのではないかと夢想していたが、歴史はそれを否定した。（少なくとも今現在は）。数々の標準が（de factoであれde jureであれ）生まれたがどれかに統一されたと言うことはない。
Unixの世界であればEUCというエンコーディングは非常によくできていたし1985年前後の環境を考えれば絶妙な（？）バランス感覚を持っていた。当時は米国生まれのソフトウェアをいかにして簡単に日本語化するかという課題をとくことが一つの使命であった。バイリンガルなソフトウェアがゴールであった。まだソフトウェアの国際化という概念は十分成熟していなかった。
日本語化、韓国語化、中国語化などを繰り返すうちに、ソフトウェアから文字コードに関する数々の暗黙の仮定を取り除くことの重要性が徐々に理解されてきた。従来のプログラミング言語は一文字を一バイトで表現していたが、漢字を表現するには一バイトではたりなくて、最低二バイト必要だった。当時日本語化のことをダブルバイト化などとよく言っていた。文字コードに関する仮定だけではなくて、メッセージやヘルプ、あるいは入力メソッドなど数々のソフトウェアに内在する仮定をあぶりだしていった。そしてそのようなソフトウェアの作る中で、ソフトウェアのあらかじめ持つべき性質としての国際化したソフトウェアという概念を構築していった。当時日本のベンダだけではなく、IBM、DEC、HPなどの外資系ベンダがベンダの垣根を越えてコラボレーションしていた。
Unicodeはある意味妥協の産物である。それを否定しないがUnicode化する過程の中で多くの問題が解決したことも事実である。ソフトウェアから文字コードに関する仮定を取り除くと言いつつ結局はUnicodeという文字コードを仮定することによって多くの問題を解決した。日本語化という観点で言えば特になにもしなくてもそのまま使えるようになった。文字化けの問題を除けば。
Windowsの世界ではシフトJISというエンコーディングが利用されている。①（まるに１）とか㈱（（㈱））とか日本工業規格JIS X0208に定義されていない文字も利用できる。EUCというエンコーディングにはそのような文字は定義されていないのだが、昔はEUCとシフトJISの変換はアルゴリズム的に行われていたのでJISの未定義文字もそのままシフトJISにマッピングされていた。EUC（精密にはeucJPとでも言うべきか）とシフトJISのラウンドトリップの変換でも元の文字に戻った。①は①なのであって、①は？ではない。（まる１はまる１なのであって、まる１は？ではない）
ところがソフトウェアがUnicodeを仮定するようになると、レガシーエンコーディング（ここではシフトJISやeucJPのことを仮にそう呼ぶことにする）とUnicodeとの変換が必要になってくるがそれはテーブルによる変換にならざるおえない。そしてJIS X0208に定義していない文字に関してEUCの立場は、そんなものは知らないという立場であって、Unicodeの①（まる１）からeucJPへは変換されない。そして文字化けする。もちろん変換するようなマッピングテーブル(eucJP-msとか）を用意すればいいのだが、ソフトウェアによってはそのようなものを準備していないものが少なからずある。
特にオープンソースソフトウェアの場合、レガシーエンコーディングとのマッピングに関しては保守的な立場をとるソフトウェアが多いように感じる。これは実装の話なので極論すればいくら標準があろうがなかろうが解決しない。一つ一つソフトウェアをレガシーエンコーディング対応しないといけないということである。Unicode化することによって前進したが半歩後退したようなものである。
Samba3.0の国際化はまさにそのような問題を解決する作業であった。Samba 2.0時代はSamba-jpグループが開発したパッチによってeucJPとシフトJISの変換がなされていたが、Samba 3.0になって内部コードがUnicode化されたため上に記したような問題が顕在化したのである。このような様々な問題が発生しているのはもちろんSambaだけではない。横串を通してその問題を解決するようなイニシアティブが今まさに求められている。
文字化けはなかなかなくならない。