CSVに「標準仕様」はない — RFC 4180がInformationalである意味

CSVの受け渡しで中身がずれたとき、最初に疑われるのは送り手の実装です。「仕様どおりに出力してほしい」という依頼が飛びます。

ところが、依頼の宛先になる「仕様」のほうを開くと、話が変わります。CSVについて最もよく参照される文書はRFC 4180ですが、この文書は冒頭で自分がいかなる種類のインターネット標準も規定しないと宣言しています。

つまり、ずれの原因は実装の怠慢ではなく、拠るべき共通の規格が存在しないことです。この違いは責任の所在を変えます。規格があるなら、守っていない側に直してもらう話になります。規格がないなら、受け渡しの当事者同士で何を揃えるかを決める話になります。

本稿では、RFC 4180の原文を読んで、どこまでが書かれていてどこからが書かれていないのかを切り分けます。扱わないのは、特定の表計算ソフトやツールの挙動です。区切り文字が地域設定で変わる、バイト順マーク（BOM）をどう扱う、文字コードを自動で判別する——いずれもRFC 4180に規定がなく、本稿は実測もしていないため書きません。

30秒で要点

• RFC 4180はInformational（情報提供）で、文書自身が「いかなる種類のインターネット標準も規定しない」と書いている
• 形式を定める2章は規範ではなく、「ほとんどの実装が従っているように見える形式」の記述である
• 文法記法（ABNF）を読むと、引用符の内側にカンマ・CR・LFを置けることが明示されている。だから物理的な行数はレコード数と一致しない
• 文字コードはファイルの外側（MIMEのcharsetパラメータ）で示すもので、ファイル自身が保証する仕組みはない
• RFC自身の助言は「準拠を要求して揃える」ではなく「送出は保守的に、受容は寛容に」である

この記事で使う言葉の意味

表が収まらない場合は、横にスクロールできます

RFC 4180は自分を「標準ではない」と書いている

まず文書そのものの素性です。RFC 4180「Common Format and MIME Type for Comma-Separated Values (CSV) Files」は、Y. Shafranovich（SolidMatrix Technologies, Inc.）による2005年10月発行の文書で、ヘッダ部には "Request for Comments: 4180 / Category: Informational / October 2005" と書かれています。

そしてStatus of This Memoは、こうです。

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

「いかなる種類のインターネット標準も規定しない」。この一文があるため、「RFC 4180に準拠していない」という指摘は、規格違反の指摘にはなりません。参照できる共通の記述から外れている、という指摘にとどまります。

言葉の選び方が細かいようでいて、交渉では効きます。規格違反なら相手に是正の義務が生まれます。記述からの逸脱なら、どちらが歩み寄るかは交渉事項です。前者として話を始めて、後者だと分かった時点で止まる会話は珍しくありません。

形式を定める2章は、規範ではなく観察の記述である

RFC 4180の2章が、いわゆる「CSVの仕様」として引かれる部分です。ここに改行・ヘッダ行・引用符の扱いが列挙されています。

その2章の導入が、文書の性格を決めています。

While there are various specifications and implementations for the CSV format (for ex. [4], [5], [6] and [7]), there is no formal specification in existence, which allows for a wide variety of interpretations of CSV files. This section documents the format that seems to be followed by most implementations:

「正式な仕様は存在しない」と述べ、続く記述は「ほとんどの実装が従っているように見える形式」を記録したものだと宣言しています。"seems to be followed" です。規範を定めたのではなく、当時の観察を書き留めた節だと、文書自身が位置づけています。

ここが、冒頭の「依頼の宛先がない」という状況の正体です。2章の内容は有用ですが、守るべき規定として引くには、文書自身がその資格を否定しています。

ABNFを読むと、「1行＝1件」が崩れる場所が分かる

抽象的な話で終わらせないために、文法記法のほうを見ます。RFC 4180のABNFから、受け渡しの判断に関わる行を抜き出します。

file = [header CRLF] record *(CRLF record) [CRLF]
header = name *(COMMA name)
record = field *(COMMA field)
name = field
field = (escaped / non-escaped)
escaped = DQUOTE *(TEXTDATA / COMMA / CR / LF / 2DQUOTE) DQUOTE
non-escaped = *TEXTDATA
COMMA = %x2C
CR = %x0D

注目すべきは escaped の行です。二重引用符（DQUOTE）で囲まれた中に置けるものとして、TEXTDATA のほかに COMMA・CR・LF が並んでいます。つまり引用符の内側には、区切り文字であるカンマも、改行を構成するCRもLFも置けます。引用符自身をフィールド内に書くときは2つ続け（2DQUOTE）、原文では例として "aaa","b""bb","ccc" が挙げられています。

ここから、1つの帰結が出ます。

「1行＝1レコード」が成り立つのは、引用符の外側だけです。

この区別は、数え方の定義として書けます。

• 物理的な行数: ファイルの中に現れる改行で区切られた行の数。引用符の内側にある改行も1つとして数えてしまう
• レコード数: ABNFの record の数。引用符の外にある改行だけが区切りになる

2つは一致しません。住所欄や自由記述欄に改行が1つ入ったデータが1件混ざるだけで、行数で数えた件数は実際のレコード数より多くなります。そして、これは実装の不具合ではありません。ABNFがそう書いているとおりの挙動です。

もう1か所、見落としやすい行があります。file の末尾の [CRLF] です。角括弧は任意を意味します。RFC 4180の本文も「ファイル中の最後のレコードは終端の改行を持っていてもいなくてもよい」と明記しています。

2. The last record in the file may or may not have an ending line break.

ファイル末尾の改行の有無が送り手ごとに違っても、どちらも記述の範囲内です。末尾の改行を手がかりに件数を数える処理は、ここで足をすくわれます。

ヘッダ行は任意であり、原文には表記のゆれすらある

ヘッダ行についても、RFC 4180は任意だと書いています。該当箇所を原文のまま写します。

3. There maybe an optional header line appearing as the first line of the file with the same format as normal record lines. This header will contain names corresponding to the fields in the file

"There maybe" という表記は原文のままです（"There may be" ではありません）。引用するときは原文どおりに写し、直した形を原文として示さないほうが安全です。

内容として読み取れるのは、ヘッダ行は「あってもよい」ものであり、その形式は通常のレコード行と同じだということです。ABNFでも name = field と定義されており、ヘッダの各項目は本体のフィールドと同じ文法です。

これは、ファイルの1行目を見てヘッダかデータかを判定できないという意味になります。1行目が 2026-10-29,1200,東京 であればデータだと見当がつきますが、date,amount,city のような値が実データとして入っているファイルも文法上は作れます。ヘッダ行の有無は、ファイルを見て決めるのではなく、受け渡しの合意として決める項目です。

文字コードは、ファイルの外側で示すものになっている

MIMEタイプ text/csv の登録内容を見ると、もう1つの境界が見えます。

必須パラメータは none（なし）。任意パラメータは charset と header の2つです。charsetが文字コード、headerはヘッダ行の有無で、値は present / absent を取ります。

文字コードについて、RFCはこう書いています。

Common usage of CSV is US-ASCII, but other character sets defined by IANA for the "text" tree may be used in conjunction with the "charset" parameter.

一般的な用法はUS-ASCIIであり、IANAが "text" ツリーに定義する他の文字集合もcharsetパラメータと併用できる、という書き方です。ここでUTF-8が既定だとは書かれていません。

そして、より重要なのは置かれている場所です。文字コードは charsetパラメータで「示す」ものとして規定されており、ファイル自身が自分の文字コードを保証する仕組みは定義されていません。ヘッダ行の有無も同様に、headerパラメータで示す形になっています。

つまり、ファイルだけを受け取ってパラメータが付いてこない受け渡し——たとえば共有フォルダに置かれたファイルを拾う形——では、RFC 4180が「外側で示せ」と言っている情報が、構造的に欠けたまま届きます。文字コードとヘッダ行の有無が受け渡しの合意事項になるのは、このためです。

だから「準拠させる」では解決しない

ここまでを踏まえると、RFC 4180自身の相互運用性に関する記述が、素直に読めます。

Due to lack of a single specification, there are considerable differences among implementations. Implementors should "be conservative in what you do, be liberal in what you accept from others" (RFC 793 [8]) when processing CSV files.

単一の仕様がないため実装間にかなりの差がある。だから実装者は「送出は保守的に、受容は寛容に」すべきだ——この助言はRFC 793からの引用です。

RFCの立場は「準拠を要求して揃える」ではありません。「差があることを前提に、受け側を広く作る」です。

したがって、「RFC 4180に準拠して出力してください」という依頼は、期待した効果を持ちにくくなります。相手がどの解釈で準拠したかによって、届くファイルはなお変わります。どれだけの頻度で取り込み事故が起きているかという数字は本稿も持っていませんが、準拠要求が事故をなくすという保証は、文書のどこにもないことは確認できます。

受け渡しの前に合意しておく4か所

RFCが「外側で示せ」と言っている情報と、ABNFが「どちらもありうる」と書いている箇所が、そのまま合意事項の一覧になります。

• 引用符の内側に改行が入りうるか：入りうるなら、行数を件数として扱う処理は使えない。送り手が「改行は取り除いて出す」のか、受け手が「引用符を解釈して数える」のかを決める
• ファイル末尾の改行の有無：どちらも記述の範囲内なので、受け側は両方を受け付ける前提で作る。末尾の改行を件数計算の手がかりにしない
• ヘッダ行の有無：ファイルを見て判定せず、present / absent のどちらかを取り決める。MIMEのheaderパラメータが付かない受け渡しなら、文書や設定として残す
• 文字コード：US-ASCIIの範囲を超える文字が入るなら、何で符号化するかを合意する。charsetパラメータが付いてこない経路では、合意だけが根拠になる

この4か所は、どれも「どちらが正しいか」を決められない項目です。RFC 4180に照らして正解が出る問いではなく、当事者間で先に決めておくしかない問いです。そう分かっていれば、受け渡しの設計で最初に聞くべきことが決まります。

確かなことと、この記事で扱っていないこと

確かなこと（RFC 4180の原文から直接確認した範囲）

• RFC 4180は2005年10月発行、Category: Informational であり、文書自身が「いかなる種類のインターネット標準も規定しない」と述べている
• 2章は「ほとんどの実装が従っているように見える形式」の記述として位置づけられている
• ABNFの escaped は、引用符の内側にCOMMA・CR・LFを許している
• ファイル末尾の改行とヘッダ行は、いずれも任意である
• text/csv の必須パラメータはなく、任意パラメータは charset と header の2つである
• 相互運用性の項は、実装間の差を認めたうえで「送出は保守的に、受容は寛容に」を助言している

この記事で扱っていないこと

• 特定の表計算ソフトやツールの挙動（区切り文字が地域設定で変わる、BOMの扱い、文字コードの自動判別）。RFC 4180に規定がなく、本稿は実測していない
• セミコロン区切りやタブ区切りのファイル。ABNFは COMMA = %x2C を固定しており、他の区切り文字はこの文書の範囲外である
• RFC 4180が参照として挙げている他の仕様（[4][5][6][7]）の内容。本稿はそれらの文書を開いていない
• 取り込み事故の発生頻度。構造上ずれが起きうることは書けるが、どれだけ起きているかの数字は持っていない

なぜ「CSVは単純な形式だ」と思いやすいのか

CSVは、開けば中身が読めます。テキストエディタで開いてカンマが並んでいるのを見れば、構造は一目で分かった気がします。この「見て分かる」という性質が、仕様の有無を確認する動機を消します。

画像や音声の形式なら、開いても中身は読めません。だから仕様を調べます。CSVは調べなくても読めるので、調べる段階が飛ばされます。

さらに、CSVはほとんどの場面で問題なく動きます。問題が出るのは、引用符の内側に改行が入ったとき、US-ASCIIの範囲を超える文字が入ったとき、ヘッダ行の有無が変わったときだけです。普段は動くという事実が、「単純で安定した形式だ」という理解を強化し続けます。壊れたときに初めて、拠るべき規格がないことに気づきます。

もう一つ、RFCという文書の形式そのものが誤解を招きます。RFCには番号が付き、公式な体裁をしています。番号が付いた文書があるなら標準があるのだろう、という推測は自然です。Categoryの行を読むまで、Informationalだとは分かりません。

1行のCSVで試せる最小の検証

受け渡しの相手を決める前に、10分で確かめられることがあります。

引用符の内側に改行を1つ含むCSVを1件作り、取り込み側に通してみてください。

id,note
1,"1行目
2行目"

このファイルは、ABNFに照らせばヘッダ行が1つ、レコードが1件です。しかし改行で数えれば3行あります。

確認する点は2つです。

1. 取り込み側が報告する件数：1件と出るか、2件と出るか。2件と出るなら、その処理は引用符を解釈せずに行で数えています
2. noteフィールドの中身：改行を保って1つのフィールドに入っているか、途中で切れているか

同じファイルを、送り手になる側のツールから出力してみる方向でも試せます。出てきたファイルに引用符が付いているか、改行がそのまま残っているか、末尾に改行があるか。これが、相手が「保守的に送出」しているかどうかの実測値になります。

この検証の価値は、合否を出すことではありません。合意すべき4か所のうち、どこが既にずれているかを、交渉の前に把握できることです。

判断の土台として置いておくこと

• CSVに準拠を要求できる規格はない。RFC 4180は参照できる共通の記述であり、それ自身がInformationalだと宣言している
• 「1行＝1件」はABNFの範囲で崩れる。引用符の内側に改行を置けると明示されているので、行数で数える処理は仕様どおりのデータで合わなくなる
• 文字コードとヘッダ行の有無は、ファイルの外側で示すものとして規定されている。ファイルだけが届く経路では、その情報は合意として持つしかない
• RFC自身の助言は「受容は寛容に」である。送り手を揃えようとするより、受け側を広く作り、合意の4か所を先に決めるほうが、文書の立場に沿っている

「標準だと思われているが標準ではない」という同型の構図は、システム連携の窓口（API）の側でも起きています。冪等性とは？「もう一度送っていい処理か」を決めていないAPIの弱点は、仕様が存在しない側ではなく、仕様が失効したまま慣習として使われている側の話です。仕様の文言を素直に読み直すという手順については、no-cacheは「キャッシュするな」ではない｜Cache-Controlを4つの問いに分けるが近い例になります。

参考資料・引用元

• Y. Shafranovich「Common Format and MIME Type for Comma-Separated Values (CSV) Files」RFC 4180、Category: Informational、2005年10月 https://www.rfc-editor.org/rfc/rfc4180.html （確認日: 2026-10-29。全文を確認）