アンケートCSVの読み方を3通り測ったら、1つは1割が黙って化けた

アンケートの自由記述を集めたCSVを、誰かに渡す。あるいは受け取る。開いてみたら、日本語のところが「縺ゅj縺後→縺・」のような記号の羅列になっている。

一度は踏んだことのある方が多いと思います。私も預かったデータで何度も踏みました。

この記事では「なぜ起きるか」よりも、気づかないまま集計まで進んでしまう場合があるほうを中心に書きます。画面が記号だらけになるのは、見た瞬間に分かるだけまだ親切です。実害が大きいのは、そうならない側です。

先にひとつだけ。これはCSVで渡すときに限った話です。 Excelのファイル（.xlsx）のまま渡せば、文字コードの取り違えは起こりません。それでもCSVの話が無くならないのは、システムからの書き出しがCSVしか選べなかったり、相手からCSVで送られてきたりするからです。

化けているのに、エラーが出ないことがある

文字コードというのは、文字と番号の対応表のことです。日本語のファイルでよく使われる表は主に3つあります。UTF-8、Shift-JIS（Excelで保存したときの既定）、EUC-JP（古いシステムでよく使われた形式）。

同じ番号の並びでも、どの表で読むかによって出てくる字が変わります。ここまでは、よく説明される話です。

厄介なのはこの先で、違う表で読んでも「読めてしまう」ことがあるという点です。読む側のソフトはエラーを出しません。処理は成功で終わり、日本語が出てこないだけです。人が画面を見なければ、そのまま次の工程に進みます。

どれくらい起きるのか、自分で測りました。

1,129件を3つの形式で保存し直し、3,387通り読ませた

手元のアンケートサンプル（1,000件の全行に、その断片や短い定型文を足して1,129件）を、UTF-8・Shift-JIS・EUC-JPの3つで保存し直しました。それを読ませて、元の文にそのまま戻るかを1件ずつ数えます。1,129件 × 3形式 = 延べ3,387通りです。

読み方は3通りくらべました。

A：Shift-JISから先に試す … UTF-8で0件、Shift-JISで0件、EUC-JPで331件。合計331件

B：EUC-JPから先に試す … UTF-8で0件、Shift-JISで1件、EUC-JPで3件。合計4件

C：日本語らしさの点で選ぶ … UTF-8で0件、Shift-JISで0件、EUC-JPで4件。合計4件

Aでは、3,387通りのうち331通り（およそ1割）が化けたまま成功で返ってきました。エラーは1件も出ていません。私が最初に書いていたのがこのAでした。

「試す順番を変えれば直る」は外れました

Aの結果を見て、最初に思ったのは「順番が悪いだけだ」でした。EUC-JPを先に試せばいい。それがBです。

合計は331件から4件まで落ちました。ここで終わりにしていたと思います。

ただ、表をもう一度見てください。BとCは合計が同じ4件ですが、中身が違います。 Bで化けた1件はShift-JISのファイルで出ています。Shift-JISはExcelでCSVを保存したときの既定の形式で、実際に送られてくるファイルはたいていこれです。

合計が同じでも、化ける場所が「まず送られてこない形式」なのか「いちばんよく送られてくる形式」なのかで、意味はまったく違います。合計だけを見て決めていたら、Bを選んでいました。

順番の入れ替えでは解けない、というのが結論でした。Shift-JISとEUC-JPは互いに相手のデータもエラーなしで読み通してしまうので、順番で決めるかぎり、どちらかが必ず黙って化けます。そこでCにしました。読めた候補それぞれに「日本語の文章らしいか」で点を付けて、高いほうを採ります。

いま残っている4件は、全部が極端に短い文でした

Cでもまだ化ける4件は、こういうものです。

- EUC-JPの「表」→ ɽ

- EUC-JPの「無」→ ̵

- EUC-JPの「3年」→ 3ǯ

- EUC-JPの「ﾃｽﾄです」→ 偲漆柴､ﾇ､ｹ

1文字から3文字しかない文は、そのバイトの並びがたまたま別の表でも成立してしまうことがあり、点の付けようがありません。

短いセルほど危ない、というのは覚えておいて損がないと思います。自由記述の列でも「無」「なし」「特になし」だけの回答はかなりの数が混ざります。長い文章が並んでいる列より、そちらのほうが判定は難しくなります。

今日からできること

1. そもそもCSVにしないで済まないか、先に確かめる。 Excelのファイル（.xlsx）のまま渡せるなら、それがいちばん確実です。上の表の話は丸ごと起きません

2. CSVで渡すことになったら、Excelの「名前を付けて保存」で「CSV UTF-8（コンマ区切り）」を選ぶ。 形式を選ぶ欄に並んでいます。これだけで、上の表でいちばん危ない道には入りません

3. 送る前に、CSVをテキストエディタで開いて先頭の数行を見る。 表計算ソフトで開くと、そのソフトなりの解釈が挟まるので、化けているかどうかの判断がつきにくくなります

4. 「無」「なし」だけの短い回答が多い列は、目で数行たしかめる。 上の4件はすべてこの型でした

5. 受け取る側は「読めなかったら止める」を先に決めておく。 化けたまま集計に入ってしまうと、後から気づいても、どの行が影響を受けたのか分からなくなります

私がやっていること

まず、Excelのファイル（.xlsx）でお預かりした場合は、この判定そのものが要りません。 文字コードの取り違えはCSVだけで起きるものだからです。

CSVでお預かりしたときは、まずUTF-8として読めるかを試します。読めたらそれが本物です（UTF-8は「読めた＝正しい」と言い切れる作りになっている、数少ない形式です）。読めなかったときだけ、上の点数くらべに進みます。

それでも判別できないときは、そこで止めてご連絡します。「読めませんでした。UTF-8で保存し直してください」とお伝えします。化けた結果をそのままお渡しすることはありません。

なお、上の数字は自分のサンプルを自分の読み方で測ったものです。世の中のCSVが1割化ける、という話ではありません。

自由記述の分類・集計をまとめてお引き受けしています。ExcelでもCSVでも、そのままお送りいただけます（保存し直していただく必要はありません）。

Excel・CSVの整理と集計の代行はこちらからどうぞ。

https://coconala.com/services/4378152