（Mac で圧縮した zip ファイルを Ubuntu で解凍した際のファイル名の文字コード問題を修正する機会があったので、その方法をこちらのページに載せておきました）
| ＯＳ | 文字コード | 改行コード |
|---|---|---|
| Windows | 基本は CP932（Shift-JIS に Microsoft の独自仕様を足したもの）、最近は UTF-8・UTF-16 も。 カーネルや .NET 内部は UTF-16 と思われる | CR+LF |
| Linux | システムに依るが、主に UTF-8、EUC-JP 等 | LF |
| 旧 Mac | MacJapanese （Shift-JIS に Apple の独自仕様を足したもの） | CR |
| Mac OS X | アプリケーションは MacJapanese カーネルはおそらく UTF-8 か UTF-16 ファイルシステムは UTF-16 NFD（Mac 独自） | LF |
※Mac は詳しくないのですが、全て 10.5 (Leopard) で確認しています
このようにしてみると、一般的なものにちょっと独自仕様を足したものが目に付きますね。Mac も Win も、Shift-JIS を基本にしているのでお互いにデータのやり取りはできますが、例えば Mac で作成した標準テキストを Win に持っていくと、文字は読めますが改行コードが LF と CR+LF で異なるために改行がバグります。また、一部のお互いの独自仕様が絡む文字が含まれるとやり取りができなくなる可能性があります。
Mac に関しては非常に汚いですね。Mac OS X までは Shift-JIS を独自拡張した MacJapanese ベースに改行コードとして CR を使ってましたが、Mac OS X からは UNIX ベースになったため改行コードが LF に変わっています。さらに、OS X のシステムも MacJapanese をデフォルトのエンコーディングとしながら、内部的には UTF-8 を利用し、ファイルシステム（HFS+）に NFD 正規化方式を利用した UTF-16 と全部で３種類利用しているようです。
正規化方式の話が出ましたが、「UTF-8」等と書くとほとんどが一般的な NFC 正規化方式を意味し、NFD 方式は Mac ぐらいでしか利用されていません。NFC は濁点や半濁点、ドイツ語等に見られるウムラウトの文字を含めて一字とするのに対して、NFD は「が」→「か」＋「゛」のように分離して表現します。Windows や Linux では NFD に対応しているソフトは少なく、トラブルの原因になりかねません。つまり、濁点や半濁点を含むファイル名を直接テキスト等に書き出すと NFD として書き出され、一般的な UTF エディタ等では開けなくなったり、バグったりします。なので、例えばターミナルから
% ls > dirindex.txt
として書き出すと、UTF-8 NFD（UTF-8-MAC というやつです）で書き出されてしまい、Windows の UTF 対応エディタから開いた場合エラーとなる場合があります。一方で、Mac のテキストエディットでは UTF-8-MAC の文字も UTF-8 のファイルとして読み込めば問題なく表示され、どちらかを意識することなく編集できます。逆に言うと、そこに NFD が混じっていても全く区別がつかないので、Win 等に持っていく場合は注意が必要です。（ちなみに、UTF-8-MAC のテキストを開き、NFD の部分を消して同じ文字を打ち直すとその部分だけ NFC になりました）
ただ、Mac・Linux 間はどちらも UNIX ベースということもあって、Mac のデフォルトエンコーディングの MacJapanese を UTF-8 として、かつ日本語のファイル名を利用しなければ、UTF-8 ベースの Linux ディストリビューションと文字コードに関して完全互換になりそうですね。
しかし、様々な文字コードにソフトを対応させたり文字化け解消や適宜変換をしたりと、世界中でかなりの労力が裂かれてると思うのですが、いい加減統一する方向に向かないんですかね。システムの肥大化や文字化け等のトラブル、ＯＳ間の受け渡しコストとか、統一してしまえば全部解決する気がするんだけどなぁ…。UTF は全世界の文字をほぼ全部表現できることを目指してるので、もう素直に全部 UTF-8 あたりに統一すればいいのに。
…まぁ、色々と大人の事情があるんでしょうね。
0 件のコメント:
コメントを投稿