意味不明な記事タイトル、ですが、これが今日の悩みどころでした。
著者さんからある原稿を受け取って作業しているのですが、送ったものと受け取ったもので微妙な違いがあり、気持ち悪いと言うのです。
聞けば、特定の文字で、見た目の差はないが、ソフトを使って比較すると文字コードレベルで違いがあるということでした。いったい何が起きているんでしょうか？
まず、著者さんはUTF-8（Unicode）で原稿を書いているということでした。しかし、こちらがWindows環境（職場は）であることを気遣ってか、Shift JISにわざわざ変換して送ってきてくれたわけです。
私は、それをわざわざUTF-8に変換し、推敲していました。なぜUTF-8かというと、最近はWeb関係もDTPも、基本的にUTF-8ベースに統一している、というのがあるからです。
著者さんに、あらかじめそういう状況をお伝えしておけばよかったです。
そして、UTF-8のまま、著者さんにお戻ししていました。その後、著者さんの方ではUTF-8からShift JISにまた変換し、こちらに送った時点のものと比較、推敲内容を確認しよう、ということだったようです。
ここで、一部の文字が見た目は変わっていないのに、コードとしては変わってしまうのはなぜだろうということになりました。そこで、どんな文字が変わってしまうのか確認しましたら、通貨記号、にょろ（〜）、全角ダッシュ（—）のあたりだと判明しました。
これは臭いな、臭いですね。ということで、改めて手順をおさらいしてみました。
(A)UTF-8テキスト
↓（iconvでUTF-8→Shift JIS変換）
(B)Shift JISテキスト
↓（秀丸エディタでShift JIS→UTF-8変換）
(C)UTF-8テキスト
↓（iconvでUTF-8→Shift JIS変換）
(D)Shift JISテキスト
↓（iconvでShift JIS→UTF-8変換）
(E)UTF-8テキスト
(B)と(D)では、何も編集作業を加えずとも、内容が文字コードレベルで変わってしまいます。つまりこれは、(B)→(C)と(C)→(D)の変換に互換性がないということです。
(A)→(B)として、そのまま(B)=(D)→(E)とすれば、文字コードの変化はありません。
なんとも気持ち悪いのですが、最初からUTF-8だけでブッ通す！ということで作業は行うことにしました。
実作業的には問題はないのですが、ここで満足しないのが悪いところで、では何が起きているのか調べてやろう、というわけです。
ここででてくるのが、〜（にょろ）、いわゆる全角チルダですね。
このにょろを、たとえばMac OS Xのターミナル上でemacsで入力しますと、「一般句読点」の中の2053が入るようなのです。この文字はiconvでShift JISに変換しようとしますと、対応する文字がないからとエラーになります。
さらに、Windowsの秀丸エディタで入力しますと、今度は「半角・全角形」のFF5Eとなります。このグループは、いわゆる半角文字・全角文字を全角・半角にマップしたもので、アルファベットの全角や、カタカナの半角などがあります。
考え方からすると、「一般句読点」の中の文字を入れる方が真っ当です。これに対して「半角・全角形」の中の文字は、過去のしがらみにとらわれているといえます。
上の(A)→(B)のプロセスでは、「一般句読点」の中のにょろがShift JISの「〜」に変換されましたが、(B)→(C)のプロセスでは「半角・全角形」のにょろに変換されて、これをまた変換するときに違ったことが起きたと推測されますが、それぞれのステップのファイルをもらっているわけではないので、はっきりしたことはわからないのですね。
たかが文字コードですが、気軽に変換、変換とやっていると、とんだ落とし穴にはまりそうです。
コメント