|
．ややこしいんですよねー 。 独立した話題が二つ混在してるので、 ひとつずつほどいていくといいかもしれません。
．一つめの話題というのは SJIS と CP932 の違いでして、 この二つは良く似ているけどいろいろと違います。 SJIS および CP932 で使われているエンコーディングスキームは、 大まかに言って 8bit 領域 2 つと 16bit 領域 1 つを持っており、 8bit の一つがいわゆる半角英数字記号、もう一つがいわゆる半角カナ、 そして 16bit 領域がいわゆる全角漢字記号に使われます。
．SJIS では、この領域にそれぞれ 「ISO646-JP」「JISX0201 カナ」「JISX0208」が割り当てられています。 対して CP932 は 「ISO646-US」「JISX0201 カナ」「JISX0208+拡張文字」が 割り当てられています。これをみれば分かるとおり、 そもそも SJIS は拡張文字を持ってないため、 たとえば「丸数字を SJIS で表現する」ということ自体が厳密には不可能でして、 もしそれをやっていたとしたらそれは厳密には 不正なバイト列ということになります。 したがって、実際にそこで SJIS と言われてるものは、 実は十中八九 CP932 のことを指しています。 そもそも Windows で使われているのは SJIS ではなくて CP932 なので、 したがって、Windows との相互運用を考えた場合には SJIS ではなくてできるかぎり CP932 を選択するほうが無難です。 まあそれができない場合には仕方ないんですけど。
．SJIS と CP932 には違いがあるということと、 世の中ではそういう混同があるということを認識しておくのが大切ですね。 これが一つめの話題。丸数字の問題に関しては、こっちだけ理解しておけば 十分ともいえます。
．二つめの話題というのは、SJIS ないし CP932 を Unicode へと変換する時の あいまいさに起因する問題です。SJIS や CP932 は、 論理的に同じと見なされるような文字を重複して持っています。 たとえば、「全角のＡ」と「半角の A」は、エンコーディング上は 別々の文字として扱われていますが、論理的には同じ文字です。 同様に、Unicode も重複した文字を持っています。
．問題となるのは、SJIS ないし CP932 から Unicode へ変換する時、 その重複している文字のどっちに変換すればいいのかという部分です。 常識的に考えて、SJIS と CP932 の重複部分、つまり 「JISX0201 カナ」と「JISX0208」 に関しては同じルールを適用できるはずです。 ところがややこしいことに、 Unicode コンソーシアムが提供している JISX0208 vs Unicode 変換表と、 Windows で使われている JISX0208 vs Unicode 変換表が違うんですね。 たった 4 文字 7 文字なんですけど、 これが文字列検索などで問題になることがあります。
．これは本質的に SJIS と CP932 の違いとは次元の異なる話なのですが、 Windows との互換性を考えた場合に毒を食らわば皿まで、ということで、 「SJIS を Unicode に変換する時は Unicode コンソーシアムの JIS X 0208 変換ルールを使う」 「CP932 を Unicode に変換する時は Windows の JIS X 0208 変換ルールを使う」 という「慣例」になっています。これが二つめの問題ですね。
．後者に良く似た話として、ISO646-JP と ISO646-US の違いに起因して、 Unicode 変換した時に顕在化する問題というのもあるのですが、 まあこれは省略します。
．まあなんというかややこしいですね。個人的にはですね、 SJIS と書いてあるところは何も考えずに CP932 と読み替え/書き換えてしまったほうが、 結果としてその後も何も考える必要がなくて良いと思っています。 上記のような話を除いたとしても、 ISO646-JP を使っているということ自体が SJIS の潜在的問題の一つでして、 これが Unicode との相互運用で面倒くさい話を発生させます。
．もっとも今度は、「円マークがバックスラッシュになる問題」が発生して、 エンドユーザから文句を言われたりする可能性もなきにしもあらず。 まぁフロントエンドが Windows だけで閉じてれば、 これも顕在化しなかったりする可能性が高いですけど。
．すっかり忘れてましたけど 、 拡張文字と JISX0208 で見ると同じ文字が 3 つとか存在するケースもありますな。 これは、「JISX0208 になかった字を NEC と IBM がそれぞれ独自に追加し、 その後 JISX0208 もそれを追加した」という歴史的経緯によります。 Windows 3.1 でこれらをまとめた際に、変換を容易にするため Unify は されなかったんですな。
．Unicode コンソーシアムの JISX0208 vs Unicode 変換テーブルには、 レガシーな文字コードとの相互運用性という観点からすると一つ致命的な問題が あるんですよね。それはバックスラッシュの扱いでして、件のテーブルは これが U+005C へと変換されるようになっています。EUC-JP も CP932 と同様に、いわゆる半角英数字として ISO646-US を使っており、 当然こっちのバックスラッシュも U+005C へと飛ばされますから、 バックスラッシュを含む文字列を EUC-JP → Unicode → EUC-JP と変換すると元に戻らない可能性があるということになります (普通は、 いわゆる全角バックスラッシュが半角バックスラッシュになってしまいます)。 一方、Windows の変換テーブルは JISX0208 のこの文字を U+FF3C へと 変換するので元に戻せます。もっともこれ、 Unicode コンソーシアムの気持ちもわからんではないんですけどね。 まあパンドラの箱をあけちまった Unicode コンソーシアムの連中が 悪いんだけど(ぉぃ
|
