今回は、日本語 Windows Xp から日本語を含むテキストを持ってくる場合に発生する漢字コード変換に関する問題を少し話そうと思う。Windows ユーザーは、こういった知識に非常に疎い部分があるので、被害を被らない為の予防知識程度に知っておくのも良いだろう。

 

日本語 Windows ユーザーの多くは、Xp の文字コードを Shift-JIS だと信じている

Xp ユーザー提供の日本語が含まれるテキストファイルを入手し、次のコマンドを実行してみて欲しい。(便宜上、入手したファイルを「xp日本語.txt」としてある)

 

$ iconv -f SHIFT-JIS -t UTF-8 xp日本語.txt > 日本語-from-sjis.txt
$ iconv -f CP932 -t UTF-8 xp日本語.txt > 日本語-from-cp932.txt
$
$ diff 日本語-from-sjis.txt 日本語-from-cp932.txt

 

iconv とは、オープンソース系で利用される文字コード変換コマンドであり、また、同名のライブラリは文字コード変換を必要する殆どのオープンソース系のアプリケーションやデーモンで使用されている。

※ オプションの「-f」は変換元のエンコーディング、「-t」は変換後のエンコーディング(from → to の頭文字)

 

上のコマンド、人によってはエラーで失敗したり、diff で違いが出た人もいたのではないだろうか?

結論から言えば、それは当然の結果である。

なぜなら、Windows Xp で使用されている文字コードは CP932 であり、Shift-JIS ではないからだ。

では、 上記のコマンドで違いが出なかった人は一体ナゼだろう?

答えは簡単、 CP932 と Shift-JIS は共通する部分も多く、短い文章だと違いが出ない事もある。単にラッキーだっただけだ。

もし windows で CP932 の文章が作成出来る場合、次の文章を作成して欲しい。

 

①ほんとに違いなんてあるの~?
②あるんだよ、きっとー。

 

もう一度、上記の文章が入ったファイルを「Shift-JIS」→「utf-8」へ変換してみて欲しい。今度は必ず失敗するハズだ。

で、このような場合、Windows ユーザーは言ったりするものだ。

「iconv 使えねー」とか「nkf 無いの?」とか。

まあ、この程度なら充分許せる範囲だ。困るのは Windows ユーザーであって、Linux ユーザーではないからだ。

ところがコレが、オープン系のサーバー・クライアントモデルの開発に関わってくると実害を持ち始める。

たとえば MySQL などのオープン系のデータベースを利用し、Windows 系のクライアントを構築した場合などである。

テーブルのエンコーディングに「Shift-JIS」を使用し、クライアント側も「Shift-JIS」を指定したとしよう。

この場合、

[データベース] ↔ [サーバー] ↔[クライアント]

の関係では、コード変換が発生しないため、 問題が発生しない。

ところが、UTF-8 を使用する Linux や Mac OSX でデータを参照する場合は、文字化けしたりエラーが出たりと半端ではない被害を被ることになる。

「当然、Xpの文字コードがCP932なのは知っていますよね?」

その一言が、あなたを救うかもしれない。

 

※ 非常に古い iconv を使用している場合、波線「~」の変換に失敗するそうだ。utf-8 で 波線「~」を含む文章を作成し「波線.txt」として保存、「 iconv -f utf-8 -t cp932 波線.txt 」とした場合、失敗するようなら iconv のバージョンアップをお勧めする。(コマンドだけではなくライブラリを使用する全てのソフトウェアの問題である。)なお、緊急的な回避策としては、cp932 ではなく、SHIFT_JISX0213 を指定する方法もある。

 

日本語 Windows ユーザーの多くは、アスキーコードに¥(円マーク)が存在すると思っている

ある日の事だ。

「あのー、¥n で改行しないんですけど~。」

たしか、Mac で日本語キーボードを使い、何かの開発をしていた時だったと思う。

Windows しか、まともに使った事が無い人たっだのだろう。

「¥」 と「﹨」は本来まったくの別物で、コード自体も違う。ところが日本語Windows ではバックスラッシュ(0x5C)を円マークとして表示する不思議なトラップが存在するために、このような誤解をしている人が多いからだ。

だが考えてもみて欲しい。ascii (American Standard Code for Information Interchange)はアメリカで作られたコード規格であって、円マークなるモノが入っているハズがないのだ。

そして、C 言語の標準である ANSI-C (American National Standards Institute – C) で定められた改行文字が「﹨n」だったわけだ。現在では多くのプログラミング言語が改行に利用しているのは、これを継承したモノである。

早い話、「¥n で改行」なんて文法は世界のどこにも存在しないのだ。

Macintosh は一般ユーザーの為に存在し、プログラマーの為に存在しているワケではない。 当然、日本語 Windows の「俺ルール」を採用するはずもなく、円マークキーが押された場合は、キッチリと円マークのコードを出力する。改行しないのは当然だ。

で、騒いでいた本人は言ったものだ。

「 Tera Term でよく Linux を使っていたので、大丈夫だと思っていました。」

え~と、そーゆーのは使っていたんじゃなく、繋いでいたって言うんだよ…。しかも、おもいっきり Windows を通過してるじゃないかっ!!

まあ、この程度なら苦労するのは Windows ユーザーだけなので実害は無い。

だが、ホームページ製作をする場合は、笑い事では済まなくなる。

たとえば、「¥ 1,980」 が「\1,980」になっちゃう可能性がある。

スマートフォンや iPad などの非 Windows 系端末が増え続ける昨今では、無視できないはずだ。

以前は某有名ショッピングモールとかオークションでも見られた現象だけど、今はすっかり治っているご様子。

もう許される状況じゃないハズなんだけど、いまだにエンティティーって言葉さえ知らない Web 技術者が結構います。ナゼ?

 

※ バックスラッシュはどんな環境でも見られるようにするため、全角を使用しています。
※ 円マークの問題は、厳密には日本語 Windows のフォントが原因である。従って、日本語 Windows では本来 バックスラッシュに見えるべきモノが全て円マークに見える。