要約：CSVは可能な限り最もシンプルなデータ形式に見える。だからこそ、引用符のないテキストフィールド内の迷い込んだカンマ、一致しない区切り文字、隠れたBOMといった小さな不整合が、インポートを失敗させたり、列を静かにずらしたりする。このガイドはEncoding Converter、Duplicate Finder、Remove Extra Spaces、Character Counterと組み合わせて使ってください。

CSVの実際のルールはRFC 4180で定義されているが、実際には実際に使われているほとんどのCSVはこれに緩やかに従うだけであり、それがまさにほとんどのインポート問題の原因となっている。

CSVインポートが実際にどこで失敗するか

核心的な問題：カンマは列の区切り文字であると同時に、テキストフィールド内に正当に現れうる文字でもある（住所、"小、中、大"を含む製品説明など）。RFC 4180の答えは引用符だ——カンマを含むフィールドはダブルクォートで囲まなければならず、引用符付きフィールド内のリテラルなダブルクォートは、それを二重にすることでエスケープされる（""）。このルールに従わずにCSVをエクスポートするソフトウェアは、引用符のない一つのカンマが、その後のすべての列を気づかないうちに1列ずつずらしてしまうファイルを生成する。

区切り文字は普遍的ではない

カンマ区切りがデフォルトの前提だが、多くの実際のファイルは代わりにセミコロンを使用している——特に、カンマがすでに数値の小数点区切りとして使われている地域で一般的であり、それを列の区切り文字として再利用することが曖昧になる。スプレッドシートで一つの分割されていない列として開くCSVは、そのツールの前提とは異なる区切り文字を使っているだけであることが非常に多く、実際に壊れているわけではない。

エンコーディングと見えないBOM

UTF-8バイトオーダーマーク（BOM）——ファイルの本当の先頭にある3つの見えないバイト——は一部のツール（特にエクスポート時のExcel）によってエンコーディングを示すために追加されるが、すべてのパーサーが自動的にそれを取り除くわけではない。そのままにしておくと、最初の列のヘッダー名に見えない形でくっついてしまい、文字通りnameという名前の列を検索すると失敗する。実際のヘッダーは前に見えない文字が付いたnameだからだ——これは目で見つけるのが本当に難しいバグだ。

インポート前のクリーンアップワークフロー

  1. 実際の区切り文字と引用符の使い方を確認するため、まず生のファイルをプレーンテキストとして開く（自動的に解釈し実際の構造を隠してしまう可能性があるスプレッドシートではなく）。
  2. 列名での検索が謎めいて失敗する場合は、最初の数バイトにBOMがないか確認する。
  3. 単一のテキストフィールドであるべき場所に、引用符のないカンマがないか特に探す——これは列のずれの最も一般的な原因だ。
  4. 末尾の改行や末尾の空行がないか確認する。一部のインポートツールはこれを壊れた最後のレコードとしてカウントする。
  5. 重複レコードが後で問題を引き起こす場合は、インポート前にキー列（IDやメールアドレスなど）に対してDuplicate Finderを実行する。

避けるべきよくある間違い

  • すべてのCSVがカンマを使っていると想定すること——セミコロン区切りのファイルは一般的で、間違った文字で分割しようとするまでは同じに見える。
  • スプレッドシートアプリでCSVを編集すること。これは日付を静かに再フォーマットし、先頭のゼロを取り除き、元のファイルと一致しない方法でテキストを再エンコードすることがある。
  • ヘッダーベースの検索が目に見える理由なく失敗するときに、先頭のBOMを確認しないこと。
  • インポートが明らかにずれた列を生成するまで、自由テキストフィールド内の引用符のないカンマを無視すること。

ほとんどのCSVインポートの失敗は、実際にはデータそのものについてではない。パーサーの前提（区切り文字、エンコーディング、引用符の使い方）が、ファイルが実際に含んでいるものと一致していないことについてなのだ。