クソコード製造機

数理最適化とかPythonとか

CSVの文字コード問題

雑記

数理最適化を含むデータ分析するシステムを作る際に、いつも悩むのが入出力データの形式だ。
選択肢としては、次の3つがあるだろう。

ユーザーが扱うことをだけを考えると、最もなじみがあるExcelファイルが無難だろう。
ただし、Excelファイルはバイナリファイルであるため、Git管理したときに差分が表示されない。基本的にGit管理するファイルにバイナリファイルは含めたくない。
CIで自動テストをすることを考えると、テストデータをGit管理する必要がある。コードレビューするためにブランチを取ってきてExcelで開くのは非常にめんどくさい。

そうなるとCSVファイル(文字コード:UTF-8)が第2候補に挙がってくる。
CSVファイルはテキストファイルであるため、Git管理との相性もよく、プログラムとの親和性も高い。

ただし、ユーザーがデータをいじろうとすると問題が発生する。基本的にユーザーのPCにメモ帳以外のエディターはインストールされていないので、CSVファイルを渡すとExcelで開こうとするのだが、なんとExcelはBOMのないCSVファイルを受け取るとデフォルトでCP932でエンコードしてくる。しかもPowerQueryなどでない限り文字コードを指定することもできない。(やはりExcelはクソ)
ユーザーにメモ帳でデータをいじらせるのは流石に酷である。

最終手段として、もともとCP932でエンコーディングされたCSVファイルを使うという発想になってくる。こうなると、プロジェクト内で入出力データだけがCP932になるという非常に奇怪な状態になる。文字コードのデファクトスタンダードがUTF-8とされている現状でCP932のファイルをわざわざ使うのもはばかられる。
Excelでの編集の問題も解決しておらず、CSVで開き、編集して保存すると、Excelが数値や時刻だと認識したものが勝手にフォーマットが変換される。(やはりExcelは滅ぼさなければならない)
これでもユーザーがメモ帳でCSVデータをいじるという苦行が発生する可能性がある。

そうなると結局Excelファイルで、となって堂々巡りになってしまう。この問題は常に頭痛の種だ。

結局、WindowsがさっさとCP932を廃止して、ExcelがUTF-8をデフォルトにしてくれれば問題の大部分が解決する。それでも、もし将来UTF-8は古いと言われるようになってしまったら、また同じ問題が起こるのだろうか。