🌟
CSVファイルを扱うためのルールを再確認する

2024/10/02に公開
 CSVファイルでの連携に必要な共通ルールを定義します。!ここで紹介するルールは、絶対的な「CSVファイルの規格」ではありません。他にも既存のCSVルールや、利用するパーサーの仕様があるかもしれません。状況に応じて、臨機応変に対応してくださいね。
CSVファイルの読み込みや書き込みに関して、仕様を見直す機会がありました。そこで、ここにCSVファイルの基本ルールを整理しておきます。
CSVファイルには、「RFC 4180」という、CSVファイル形式に関する最も広く認識されている「公式仕様」が存在します。
RFC4180についてRFC 4180 (Common Format and MIME Type for Comma-Separated Values - CSV Files)
RFC 4180は、CSVファイルの形式に関する「公式仕様」として知られ、インターネット標準の1つです。この文書では、CSVデータを交換するための基本ルールが定義されています。CSVファイルの構造に関して、以下のような主要なルールがあります。
主要なルール:
各レコードは1行で表現され、フィールドはカンマで区切られる。
フィールド内にカンマや改行が含まれる場合、そのフィールドはダブルクォートで囲む。
ダブルクォート内にさらにダブルクォートを使う場合は、二重のダブルクォートで表現する（例：""）。
公式文書:
RFC 4180: Common Format and MIME Type for CSV Files

 CSVファイルの共通ルールここでは、ルールとして決め打ちの表現で進めます。

詳細な説明が必要な箇所には、アコーディオン形式で補足を追加しています。

 1. 文字エンコーディング
UTF-8エンコーディング を使用すること。

BOM (Byte Order Mark) を含まない。
BOM (Byte Order Mark) を含まない理由BOM (Byte Order Mark) を含まない理由を明確にするためには、BOMの役割やその影響を踏まえて説明する必要があります。以下に理由を言語化します。
BOM (Byte Order Mark) を含まない理由
互換性の問題
BOMは、ファイルのエンコーディングを明示するために使われますが、すべてのシステムやアプリケーションがBOMに対応しているわけではありません。特に、多くのCSVパーサーやデータベースインポートツールはBOMをサポートしていないことがあり、BOMが含まれるとファイルの最初に不正な文字が出力される場合があります。これにより、データの先頭に不要な空白やエラーメッセージが挿入されることがあります。
クロスプラットフォームでの扱い
BOMは、Windows環境では一般的に付与されることがありますが、UnixやLinux環境では付与されません。このため、異なるOS間でのデータ交換時にBOMが原因でエンコーディングが正しく解釈されないことがあります。ファイルを一貫して扱うために、BOMを含めない方がクロスプラットフォームでの互換性が向上します。
データ処理の一貫性
BOMは通常、テキストファイルの先頭に配置されるため、CSVファイルの最初のフィールドに影響を与える可能性があります。BOMが含まれていると、最初のカラム名やデータの前に見えない制御文字が入ってしまうことがあり、意図しない動作が発生します。BOMが含まれないことで、データの処理やパースが一貫して正確に行われます。
UTF-8の明示性
UTF-8は、BOMがなくてもエンコーディングが容易に識別できるエンコーディング形式です。そのため、特にUTF-8を使用している場合は、BOMを含める必要がなく、むしろ含めることで誤動作を招くリスクが増加します。BOMを省略することで、余分な制御文字の混入を防ぎ、ファイルがよりシンプルで明確な構造になります。
結論:
BOMを含めないことによって、互換性の向上、クロスプラットフォームでの一貫性、データ処理の正確性が確保され、エンコーディングの混乱を防ぐことができるため、CSVファイルにBOMを含めない方が良いとされています。

 2. 区切り文字
カンマ (,) をフィールド間の区切り文字として使用する。

 3. 改行コード改行コードは LF (Line Feed, \n) を使用する。
Windows環境でも CRLF (\r\n) ではなく、 LF に統一する。
Windows環境でもCRLF (\r\n)ではなく、LF (\n)に統一する理由Windows環境でもCRLF (\r\n)ではなく、LF (\n)に統一する理由を言語化すると、以下のようにまとめられます。
CRLF (\r\n) ではなく、LF (\n) に統一する理由
クロスプラットフォームでの互換性
異なるオペレーティングシステムでは、改行コードの扱いが異なります。Windowsは通常、CRLF (\r\n) を使用し、Unix系のシステム（LinuxやmacOS）はLF (\n) を使用します。プラットフォーム間でファイルを共有すると、CRLFによる不整合が発生することがあります。
LF (\n)に統一することで、すべてのプラットフォーム間で互換性が保たれ、改行コードの違いによるトラブルを防ぐことができます。
バージョン管理システムでの一貫性
Gitのようなバージョン管理システムでは、改行コードの違いが原因で意図しない差分が発生することがあります。特に、Windows環境で作成されたファイルにCRLFが含まれている場合、変更がないのに改行コードだけが変更されたと誤認されることがあります。
LFに統一することで、バージョン管理システム上でも一貫性が保たれ、無駄な差分やコンフリクトを減らすことができます。
多くのツールがLFに対応している
現代の開発ツールやテキストエディタ、プログラミング言語の多くは、LF (\n) を標準的な改行コードとして扱うようになっています。多くのツールでは、LFを使うことが推奨されており、CRLFは特定の環境（主にWindows）でしか必要とされません。
LFに統一することで、これらのツールや環境でのデータ処理やパースがスムーズに行われます。特に、プログラムやスクリプトが異なるOSで実行される場合は、LFであることが安心材料となります。
ファイルの一貫性と簡素化
CRLFは2バイト（\r + \n）で表現されるため、改行1つあたり余分なバイト数が必要です。LFは1バイトで済むため、ファイルが簡素化され、少しではありますがサイズの削減につながります。特に大量のデータを扱う場合、LFを使うことでファイルサイズの最適化が可能です。
また、LFに統一することで、ファイル内の改行コードの処理がシンプルになり、プログラムによる処理や解析の際に余分なロジックを加える必要がなくなります。
開発チーム内での規約統一
複数の開発者が異なる環境（WindowsやmacOS、Linux）で作業する場合、LFに統一することでチーム内の規約を簡単に統一できます。これにより、環境による違いを意識せず、コードやデータのやり取りがスムーズに行われるようになります。
結論:
LF (\n) に統一することで、クロスプラットフォームの互換性が向上し、バージョン管理システムの一貫性を保てます。また、ツールや言語の標準に沿った改行コードを使うことで、開発環境やデータ処理がシンプルになり、チーム全体での作業効率が向上します。

 4. フィールド内のカンマフィールド内にカンマ( , )が含まれる場合、そのフィールドを ダブルクォート (") で囲む。
例: 山田, 太郎 → "山田, 太郎"


 5. ダブルクォート (") の扱いフィールド内にダブルクォート( " ) が含まれる場合、 二重のダブルクォート ("") として表現し、フィールド全体をダブルクォートで囲む。
例: 彼は "すごい" と言った → "彼は ""すごい"" と言った"


 6. カンマ( , ) とダブルクォート( " ) の混在フィールド内に カンマ ( , ) と ダブルクォート ( " ) の両方が含まれる場合、フィールド全体をダブルクォートで囲み、ダブルクォートは二重にする。
例: 彼は "すごい, 素晴らしい" と言った → "彼は ""すごい, 素晴らしい"" と言った"


 7. 空白および空フィールドの扱い空のフィールドは空白のまま残し、カンマで区切る。
例: 1,山田 太郎,,taro@example.com （年齢フィールドが空）


 8. ヘッダー行CSVファイルの1行目には必ず ヘッダー行 を含めること。ヘッダーには意味のあるフィールド名を記述する。
例: id,name,age,email


 9. データ内に改行が含まれる場合フィールド内に改行が含まれる場合、そのフィールドも ダブルクォート で囲む。
例: "彼は素晴らしい。\n次回も期待している。"

サンプルCSV
CSVとしてはこんな感じ
id,name,age,email
1,"山田, 太郎",30,"彼は""すごい, 素晴らしい""と言った。"
2,鈴木 花子,25,"花子は""とても嬉しい""と言いました。"
3,"佐藤 次郎",40,"""さようなら""が彼の最後の言葉だった。"
4,田中 美咲,28,"彼女は""驚きました！""と述べた。"

 改行が特殊文字として含まれる場合の取り扱いデータの中に改行が含まれている場合、特に \n ではなく特殊文字（目に見えない制御文字）として改行が入っているケースの取り扱いについては、適切な処理が必要です。具体的な問題と対策を以下にまとめました。

 1. CSVファイル内の改行の影響CSVデータ内に改行が含まれていると、通常の改行コード (\n) ではなく、何らかの特殊な制御文字として解釈されることがあります。これは、テキストエディタやファイルのエンコーディングに依存して発生することがあり、見た目には「改行」として表示されますが、実際には非標準の改行文字であるため、パース時に正しく認識されない可能性があります。
例: こんにちわ\nどうでしょうか。 の改行が特殊文字で扱われている場合、正しくパースされず、データが2行目にまたがってしまう可能性があります。

 2. 問題点データが途中で途切れる: 改行が特殊文字として処理されると、1つのフィールドが複数行にまたがる形で誤ってパースされ、データの整合性が崩れます。
データベースへの登録エラー: データベースに挿入する際、改行を含むデータが不正な形で登録され、意図しない結果を招くことがあります。

 3. 対策: 改行文字の統一改行が特殊文字として扱われている場合、その改行を標準的な \n に変換する必要があります。これを行うためには、CSVを読み込む際に特殊な改行文字を検出し、置換する処理を追加します。
手順:
特殊改行文字の検出: 特殊な改行文字が何であるか（例: \r\n, \r, 目に見えない制御文字など）を確認します。
正しい改行への置換: 特殊文字を正しい改行コード (\n) に置換します。
TypeScriptの例（正規表現を使用して改行を標準化する）
import fs from 'fs';
import Papa from 'papaparse';

// 特殊な改行を含むCSVファイルを読み込む
fs.readFile('your-file.csv', 'utf8', (err, csvData) => {
  if (err) {
    console.error('CSVファイルの読み込みエラー:', err);
    return;
  }

  // 【注目⭐️】特殊な改行を標準的な改行に置換する
  const normalizedData = csvData.replace(/(?:\r\n|\r|\n)/g, '\n');

  // PapaParseでCSVをパース
  Papa.parse(normalizedData, {
    header: true, // ヘッダー行を使う
    skipEmptyLines: true, // 空行をスキップ
    complete: (results) => {
      console.log('パースされたデータ:', results.data);
      // データベースに挿入する処理などをここで実行
    },
    error: (error) => {
      console.error('CSVパースエラー:', error);
    },
  });
});
https://www.papaparse.com/
改行の処理については以下の処理が非常に有益なのかなと思います。
  // 【注目⭐️】特殊な改行を標準的な改行に置換する
  const normalizedData = csvData.replace(/(?:\r\n|\r|\n)/g, '\n');
特殊な改行を標準的な改行に置換する理由と有益性クロスプラットフォームでの互換性向上
異なるオペレーティングシステム（Windows、macOS、Linux）では、改行コードが異なります。
•	Windows: CRLF (\r\n)
•	macOS/Linux: LF (\n)
•	古いmacOS: CR (\r)
上記のコードは、どのプラットフォームで作成されたファイルでも改行コードを一貫してLF (\n) に置換するため、プラットフォーム間での互換性を確保します。これにより、複数の環境でファイルを扱う際の問題（改行の解釈が異なることによるデータの不整合やエラー）を防ぎます。
データ処理の一貫性
異なる改行コードが混在していると、パーサーやデータ処理ツールが予期しない動作を引き起こすことがあります。たとえば、WindowsのCRLF改行が残ったままだと、データが正しくパースされず、意図しない行区切りやエラーが発生する可能性があります。この置換処理を行うことで、すべての改行コードが統一され、データの処理がシンプルで確実になります。
バージョン管理システムでの差分を減らす
開発者が異なる環境で作業している場合、CRLFやLFの違いだけで無駄な差分がバージョン管理システム（例：Git）に表示されることがあります。この処理により、改行コードが統一され、無駄な改行の差分が発生せず、正しい差分だけを追跡できるようになります。これにより、レビュープロセスがスムーズになり、作業効率が向上します。
ファイル解析の正確性向上
解析やデータ処理において、改行がデータの区切りである場合が多いため、正しい改行コードが必要です。この処理により、すべての改行がLF (\n) となり、解析ツールが一貫して改行を正しく解釈できます。特に、テキスト解析やデータ抽出を行う際のミスを防ぐ効果があります。
ファイルサイズの軽減
CRLFは2バイト（\r + \n）で表現されるのに対し、LFは1バイトです。ファイル内の改行をLFに統一することで、ファイルサイズを少しでも削減できます。大量のデータを扱う場合、こうした細かな改善がパフォーマンスに貢献することもあります。
結論:
このコードは、異なるプラットフォームで作成されたCSVファイルの改行コードを標準的なLF (\n) に統一することで、クロスプラットフォームの互換性を向上させ、データ処理の一貫性を保つために非常に有益です。これにより、データの解析や処理がスムーズに行われ、バージョン管理システムやツール間でのトラブルを未然に防ぐことができます。

 4. フィールド内の改行が必要な場合特定のフィールド内で改行が許されている場合、フィールド全体を ダブルクォート (”) で囲む必要があります。これにより、改行がフィールド内の一部として認識され、データが複数行に分割されることが防止されます。
例:
id,メッセージ
1,"こんにちわ
どうでしょうか。"
上記のように、フィールド全体をダブルクォートで囲むことで、改行がデータの一部として正しく認識されます。
papaparseの改行の扱いについてPapaParseは、CSVの標準仕様に準拠しており、フィールド内に改行やカンマが含まれる場合でも、それらを正しく処理できるようになっています。特に、ダブルクォート (”) で囲まれたフィールド内に改行が含まれている場合、PapaParseはその改行をフィールドの一部として認識し、データを分割することなく1つのフィールドとして処理します。
PapaParseの挙動
フィールド内に改行が含まれている場合、そのフィールドがダブルクォートで囲まれていれば、改行を文字列の一部として認識します。
ダブルクォートで囲まれていない改行があると、PapaParseはそれを次のレコードの始まりとして扱います。
import Papa from 'papaparse';

const csvData = `
id,name,message
1,山田 太郎,"こんにちは
どうでしょうか？"
2,鈴木 花子,"おはようございます"
`;

const result = Papa.parse(csvData, {
  header: true,    // ヘッダーを有効にする
  skipEmptyLines: true,  // 空行をスキップする
});

console.log(result.data);
出力結果：
[
  {
    "id": "1",
    "name": "山田 太郎",
    "message": "こんにちは\nどうでしょうか？"
  },
  {
    "id": "2",
    "name": "鈴木 花子",
    "message": "おはようございます"
  }
]
説明:
"こんにちは\nどうでしょうか？" のように、改行が含まれているフィールドは、ダブルクォートで囲まれているため、message フィールド全体が1つのまとまりとして正しくパースされています。
改行があるにもかかわらず、データは2つのレコードに分割されることなく、1つのフィールドとして扱われています。
注意点:
フィールドがダブルクォートで囲まれていない場合、PapaParseは改行を新しいレコードの始まりと見なすため、フィールド内の改行を処理できません。したがって、改行を含むフィールドは必ずダブルクォートで囲む必要があります。
結論:
PapaParse は、CSVファイル内で改行を含むデータも正しく処理することができます。ただし、CSVのフィールド内に改行が含まれる場合は、そのフィールドをダブルクォートで囲むことが必要です。この仕様を守れば、改行を含むデータでも正しくパースされ、データが分割されることなく正常に処理されます。

 5. データベース登録時の注意データベースに登録する前に、パースされたデータをクリーンにする必要があります。
SQLインジェクション対策ここでは、触りだけ説明します。興味がある場合はSQLインジェクション対策で検索すると良いです。
SQLインジェクションとは？
SQLインジェクションは、悪意のあるユーザーがデータベースに対して不正な操作を行う攻撃手法の1つです。これは、アプリケーションが入力されたデータを適切に処理せずに直接SQLクエリに埋め込んだ結果、SQL文の構造が変更され、意図しないデータの取得や削除が可能になる攻撃です。
SELECT * FROM users WHERE username = 'ユーザー名' AND password = 'パスワード';
ここで、ユーザーがパスワード入力フィールドに次のような文字列を入力したとします。
' OR '1'='1
これをそのままSQLクエリに組み込むと、以下のようなSQL文が実行されます。
SELECT * FROM users WHERE username = '任意のユーザー' AND password = '' OR '1'='1';
このクエリでは、'1'='1' が常に真であるため、パスワードにかかわらず認証が通ってしまうという脆弱性が生じます。

このような不正を未然に防ぐのが「SQLインジェクション対策」になります。

 まとめ:データ内に特殊な改行文字が含まれている場合、まずその改行を標準の \n に置換する必要があります。
フィールド内に改行を含める場合は、フィールド全体を ダブルクォートで囲む。
改行を適切に処理した後、データベースに登録する際には、SQLインジェクション対策としてエスケープ処理やパラメータ化されたクエリを利用することが推奨されます。
これにより、特殊な改行文字が含まれていても、正しくデータを処理してデータベースに登録できます。

 その他、情報
 NPM トレンドcsv-parse-vs-csv-parser-vs-papaparse
https://npmtrends.com/csv-parse-vs-csv-parser-vs-papaparse

 PapaParseを推す理由ベンチマークした結果、PapaParseが良いという結果があるそうです。

この記事を私は信じPapaParseを利用しています。
https://leanylabs.com/blog/js-csv-parsers-benchmarks/#conclusion
CSVファイルでの連携に必要な共通ルールを定義します。

CSVファイルの共通ルール

1. 文字エンコーディング

2. 区切り文字

3. 改行コード

4. フィールド内のカンマ

5. ダブルクォート (") の扱い

6. カンマ( , ) とダブルクォート( " ) の混在

7. 空白および空フィールドの扱い

8. ヘッダー行

9. データ内に改行が含まれる場合

改行が特殊文字として含まれる場合の取り扱い

1. CSVファイル内の改行の影響

2. 問題点

3. 対策: 改行文字の統一

4. フィールド内の改行が必要な場合

5. データベース登録時の注意

まとめ:

その他、情報

NPM トレンド

PapaParseを推す理由

Discussion
