（改宗しました）ウェブで公開するCSVは、漢字入りならUTF-8よりShift_JIS（charsetは指定しよう）

2月のことですが、さる官庁でオープンデータといってCSVをウェブ公開したはよいが、正規化してないわファイル名はpermalinkを意識しているとは思えないわというのでネット上のエンジニアの注目を浴びるということがありました。そこから派生して、改行コードや文字コード（エンコーディングというのが正しいのだろうが、通じないので以下文字コードでとおす）が話題になりました。

たとえば mishiki さんの例

なお、「Shift_JISを止めてUTF-8にしろ」という意見には賛成できません。理由は、Shift_JISじゃないCSVをExcelは開けないからです。インポートすれば開けますが、慣れていない人達の大混乱は必至です。

— 未識@🐠🏭技術書典2 お-03 (@mishiki) 2017年2月22日

@s_no_jijo 本当にそのまま開けるのもあるんですね。Shift_JISのCSVを、そのままUTF-8 BOM付きにしてみただけではダメでした。うーん条件が分からない。様々な環境でのトラブルシューティングの工数を考えると、まあレガシーShift_JISもやむ無しかな…と。

— 未識@🐠🏭技術書典2 お-03 (@mishiki) 2017年2月23日

この件に関して、つい先週まではUTF-8派だったのですが、いろいろ考え議論して改宗しました。現在のお勧めは：

• 改行は CR+LF
• 文字コードはShift_JIS
• 極力 HTTP 応答に charset=Shift_JIS が付くよう設定しよう。

なぜ Shift_JIS なのか。まず、さまざまな利用環境での文字コード対応状況（ベンダ保証でなく実験結果）：

• MS Excel で文字化けせず開けるのは Shift_JIS または BOM つき UTF-8
• Apple iOS や Android タブレットでは UTF-8 しか開けないアプリが散見される
• ブラウザ上の JavaScript から文字化けせず開けるのは、正しい charset がついているか、UTF-8
• Java など現代的なプログラム環境から読む場合も「正しく charset を知っていれば化けない」という意味では同様
• Cで自作プログラムする場合など、文字コード認識を適切なライブラリに任せず、オクテット列として処理している場合、BOM が問題を起こすことが多い

日本的管理職ふうには、環境×文字コードの星取表を作りたくなって、どの環境でも化けないのは BOM つき UTF-8 だけなのだから、それを普及させるべき（ソフトウェアの問題ならちゃんと改修すればいい）、といいたくなるのですが、複雑な問題でそういうカタログショッピング的な単純思考をしていると立ち行きません。結局、「C で自作プログラムする場合など」が無視できないので BOM つき UTF-8 を避けるとなり、そうだとすると最も多くの環境でサポートされるのが Shift_JIS ということになります。

ソフトウェアの問題というのは、たとえばこういう仮定が成り立たなくなるということです：

• 複数の CSV ファイルを cat で連結すれば正しい CSV ファイルが得られる
• CSV ファイルを sort や grep などのコマンドでフィルタした結果も正しい CSV ファイルである
• CSV ファイルを LF で区切って得られる「行」を U+002C COMMA で区切ったものが各セルである

そういう仮定は国際化とともに終わったものと心得て決して使わず、かならず wchar_t 列を処理する素養と経験を持ったプログラマーがいればいいのですが、理屈ではいろいろ言えるのでしょうが、まあ実際問題としては無理です。

なお、テストに使ったファイルを http://toyoda-eizi.net/2017/csv-utf8/files.html に置いておきますのでよかったらお使いください。