EXCELの謎仕様には涙が止まらない(2)

未分類

ちょっと文字コードの話。0と1というデジタルデータが７個で１セットとしたら

0000000
0000001
0000010
0000011
0000100
・・・・・・全部で128通りある。1000001に「A」とか、1110010に「r」とか、0100011に「#」とか0/1の７個セット（128通り）に文字を割り当てたのがASCIIと呼ばれるコンピュータでの文字情報記録方法の始まり。例えば「Love」という文字は 1001100 1101111 1110110 1100101 というデジタルデータで記録する。英語なら大文字、小文字、数字、記号など全部あわせても128通りもあれば十分だったんだな。その後、ドイツ語やスペイン語などの独特な文字も記録できるように0/1を１つ増やして合計8個の0/1を１セット256通りの組合せにしてこれに文字を割り振る方式が一般化している・・・んだと。

ところが日本語だとひらがな、カタカナ、漢字と膨大な数の文字があるので0/1が8個でも全然足りない。そこで0/1を16個１セットにして65,536通りに文字を割り当てることにした。16個の0/1の（65,536通りの）組合せにどんな文字を割り当てるかは JIS とか Shift-JIS とか EUC-JP とかいくつかの流派が存在してる。この流派が「文字コード」。たとえば「久」という字は Shift-JIS だと 1000101101110110 に割り当てられてて、EUC-JP だと 1011010111010111 に割り当てられている。日本語の文字コードだけでも複数の流派があるんだが、言語ごとにどの組合せにどの文字を割り当てるかは各国が独自に決めている。結局 1001000010111101 という組合せでデータが記録されていた時、それがいったいどんな文字なのかはそれが Shift-JIS なのか EUC-JP なのかはたまた中国語なのか韓国語なのか、どの文字コードで記録されてるかによって違う。コンピュータが文字コードの判断に失敗するとデータを作った人の意図とは別の字が表示されてしまう。これが文字化け。だから日本語、中国語、韓国語など文字コードが異なる文字情報を一つのデータの中に記録するのは結構難しい。

グローバル化によって英語、日本語、中国語、ハングル、ベトナム語、アラビア語などなど世界中にある膨大な数の文字を一つの文字コード体系で記録する方法が必要になってきた。そのためには0/1が16個１セットの65,536通りでは全然足りない。そこで「ユニコード」。最大48個の0/1を１セットと考える（１セットの0/1個数が48個に決まってるわけじゃなくて最大48個と可変になっているところもミソ）。すると組合せは・・・・まあ無限とも思えるような組合せを作ってそこに世界中の文字を全部割り当てちゃおうという壮大な話。ユニコードにもいくつか流派が存在するが、一般的なUTF-8では「久」という字は 111001001011100110000101 に割り当てられている。ユニコードを使えば世界中の文字を一つのコードで記録できる。1980年代から大手IT企業が中心になって検討が始まっていたのでもうかれこれ30年経っている。当然ながら最近のWindowsやMacならユニコードを理解できるように作られているし、システム内部もユニコードを積極的に利用している。

中国市場を無視できない化粧品業界でも、日常的に日本語、英語、中国語が入り乱れる文書の作成やデータの作成が必要になってきた。だからウチの会社が作ってるデータベースも文字情報はユニコードで記録するし、画面表示もユニコードで出力する。システム全体で文字情報はユニコードを使う。これが俗にいう「多言語対応」ということ。

さて、データベースに記録されているデータを一覧表形式でファイルとしてダウンロードしたい場合、業界標準で汎用性が高いcsv形式（カンマ区切りテキスト）で出力することが多い。しかし一覧表形式のデータを取り扱う事実上の世界標準ソフトであるはずのEXCELがcsvをまともに扱えないとんでもなくクソ仕様なソフトで、多くのプログラマがEXCELのクソ仕様にあわせたクソ形式のcsvファイルを出力しなければならないという涙腺崩壊物語な状況にあることは以前書いた通り。

さて、csvファイルの中味はデータをカンマで区切ったテキストファイル。日本語、英語、中国語を混在させるなら文字はユニコードで出力する必要がある。ところがユニコードで書き出したcsvファイルをEXCELで開くと見事に文字化けする。えーっ！！。メモ帳で開けばちゃんと中を見ることができる。なのにEXCELで開くと文字化けする。文字コードの判定に失敗するのだ。失敗するというかどうやらEXCELはcsvファイルを開くときに何の判断もせず文字が Shift-JISで記録されていると決め打ちしてるらしい。なんで決め打ちすんの？メモ帳ですら文字コードは何かなぁ？って考えて適切な文字コードで開いてくれるのに、なんでEXCELは何も考えずにShift-JISって決め打ちして開いちゃうのさ。

はあぁぁぁぁ・・・・・・・・

しかし！前回同様、EXCELがユニコードで記録したcsvファイルをまともに開けない問題についても諸先輩プログラマの方々が解決策を編み出してくれているのだ。その解決法とは

(1)ユニコードにもいくつかの流派があって、主流のUTF-8ではなくUTF-16LEで出力する
(2)ファイルの先頭にUTF-16LEであることを示すBOMと呼ばれる特殊な非表示文字を出力しておく
(3)データの区切りをカンマではなくタブにする

以上の方法で出力した csvファイルならダブルクリックしたときにEXCELが文字化けせずに読み込んでくれる。めでたしめでたし

って、ちょっと待て！！

カンマで区切るんじゃなくてタブで区切るだと？　そ、それは comma separated values（.csv）ではなく tab separated values（.tsv）なのでは？　か、か、カンマ区切り・・・・カンマ区切り・・・・カンマ・・・・こうして、タブで区切ったカンマ区切りテキストを出力するという自分がバカなんじゃないかと思うようなプログラムを書くことになる。タブ区切りで出力したファイルに.csvという拡張子を付けなければならない屈辱感。まあユーザからすればダブルクリックしてEXCELでちゃんと開いてくれりゃカンマで区切ってあろうがタブで区切ってあろうが関係ないんだろうけどね。

嗚呼、EXCELなんてこの世から消えてしまえっ！！！