0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

RFC4180に準拠しないCSVを考える

Posted at

RFC4180に準拠しないCSVを考える

RFC4180を実装したくないので独自仕様を考えます。嫌いな人はBBしてください。

そもそもRFC4180とは?

有志による翻訳

フォーマットについて抜粋したものが以下です

  • カラム名を示すヘッダ行の有無は自由
  • 値をカンマで区切る
  • 値がカンマを持つ場合は""で囲む
  • 改行(CRLF)で次のレコード
  • 値が改行を持つ場合も""で囲む
  • 値がダブルクォーテーションを持つ場合はダブルクォーテーションを2つ重ねてエスケープする
  • ファイル末尾の改行の有無は自由
  • 「Infomational(情報提供)」なので必ず従う必要はない

RFC4180に対する評価

筆者個人の評価になりますが、あまり良いものではないです
理由としては以下が挙げられます

  • 値に改行を持つ場合はテキストエディタで開くとフォーマットが崩れているように見える
  • 多くのファイル入出力では行ごとに読み込むがこの仕様では前の行の状態を見なければならない
  • 完全に対応できているライブラリは多くはない
  • CSVを安易に採用する現場で外部ライブラリやOSSの使用が許可されていない事が多い

独自仕様の要点

上記の通り、従う必要はなく、送信側と受信側で形式に合意があれば何の問題もない。よって独自仕様を考える
独自仕様を考えるにあたって以下に注意する必要がある

  • 値にカンマを持つ場合
  • 値に改行を持つ場合
  • エスケープ文字が値に含まれている場合
  • エスケープ文字が何もエスケープしていない場合

その他考慮する点

  • 行ごとにフィールド数が異なる場合の扱い
  • コメント行

筆者の独自仕様

プログラミング言語に倣う

  • 値がカンマを持つ場合はカンマの前にバックスラッシュを付与する
  • 値が改行を持つ場合は改行を\r\n、\r、\nのいずれかで示す
  • 値がバックスラッシュを持つ場合はバックスラッシュを2つ重ねる
  • バックスラッシュが単体で存在している場合は無視する

文字コードやヘッダ行については送受信間で応相談

感想

ここまで書いといてなんですが、更に外部に展開する可能性を考えると最初から標準仕様に従って車輪を再再再発明するほうが楽です。逆にその場対応なら改行を扱わないとするので十分です

誰かちゃんとした標準仕様作ってくれないかな

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?