計算機の世界 Top
新規
編集
2005年10月に公開された、RFC4180「Common Format and MIME Type for Comma-Separated Values (CSV) Files (CSVファイルの一般的書式、およびMIMEタイプ) 」の日本語訳です。謝辞と文献の箇所は原文のままです。
データ交換において頻繁に使われるCSV形式ですが、ベンダの独自仕様が乱立しているのが実情です。
本RFCは、遅まきながら出てきた、最初にして唯一の、「公式(?)」な仕様です。もっとも、区分 (Category) がInformationalのRFCなので、「標準」ではありませんが…
原文は、http://www.ietf.org/rfc/rfc4180.txt をご参照下さい。邦訳の誤りにお気づきの場合、ページ最下部のメールアドレスまでご連絡いただければ幸いです。
なお、可読性向上のため、ページのヘッダ・フッタは省略してあります。また、改行位置は原文から変更しております。ご了承下さい。
Network Working Group Y. Shafranovich Request for Comments: 4180 SolidMatrix Technologies, Inc. Category: Informational October 2005
Common Format and MIME Type for Comma-Separated Values (CSV) Files
CSVファイルの一般的書式、およびMIMEタイプ
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供するものである。インターネットの標準仕様は何ら定めない。このメモの配布に制限はない。
Copyright (C) The Internet Society (2005).
This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv".
このRFCは、CSVファイルに使用される書式について述べ、それと関連付けられるMIMEタイプ、"text/csv"を登記する。
1. Introduction ....................................................2
2. Definition of the CSV Format ....................................2
3. MIME Type Registration of text/csv ..............................4
4. IANA Considerations .............................................5
5. Security Considerations .........................................5
6. Acknowledgments .................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
1. はじめに 2. CSVの書式の定義 3. MIMEタイプtext/csvの登記 4. IANAの考察 5. セキュリティの考察 6. 謝辞 7. 文献 7.1 基準文献 7.2 参考文献
The comma separated values format (CSV) has been used for exchanging and converting data between various spreadsheet programs for quite some time. Surprisingly, while this format is very common, it has never been formally documented. Additionally, while the IANA MIME registration tree includes a registration for "text/tab-separated-values" type, no MIME types have ever been registered with IANA for CSV. At the same time, various programs and operating systems have begun to use different MIME types for this format. This RFC documents the format of comma separated values (CSV) files and formally registers the "text/csv" MIME type for CSV in accordance with RFC 2048 [1].
CSV形式は、数々のスプレッドシート・プログラム間のデータ交換/変換に、極めて頻繁に使用されてきた。この形式は、極めて一般的なものにも関わらず、驚くことに、一度も公式にドキュメント化されたことがない。更に、IANAのMIME登録ツリーには、"text/tab-separated-values"は存在する一方、CSVに対するMIMEタイプは未登録のままである。同時に、様々なプログラムやオペレーティング･システムが、このフォーマットに対し、異なるMIMEタイプを使用し始めている。本RFCは、CSVファイルの形式を述べるとともに、CSVに対するMIMEタイプ"text/csv"を、RFC2048[1]のとおり登記する。
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:
CSV形式の仕様や実装は数多いが (例: [4],[5],[6],[7]) 、CSVの仔細な解説となる公式な仕様は、存在しない。本節で、ほとんどの実装が追随可能と考えられる書式を述べる。
1. Each record is located on a separate line, delimited by a line break (CRLF). For example:
1. 各レコードは、改行(CRLF)を区切りとする、分割された行に配置される。例えば、
aaa,bbb,ccc CRLF zzz,yyy,xxx CRLF
2. The last record in the file may or may not have an ending line break. For example:
2. ファイル末尾のレコードの終端には、改行はあってもなくてもよい。例えば、
aaa,bbb,ccc CRLF zzz,yyy,xxx
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 and should contain the same number of fields as the records in the rest of the file (the presence or absence of the header line should be indicated via the optional "header" parameter of this MIME type). For example:
3. ファイルの先頭には、オプションとして、通常行と同一の書式を持つ、ヘッダ行が存在してもよい。このヘッダは、ファイル中の各フィールドの名称を保持し、ファイルの残りの部分にある各レコードが持っているのと、同じ数のフィールドを持つべきである。ヘッダ行の有無は、このMIMEタイプのオプションパラメータ"header"で明示するべきである。例えば、
field_name,field_name,field_name CRLF aaa,bbb,ccc CRLF zzz,yyy,xxx CRLF
4. Within the header and each record, there may be one or more fields, separated by commas. Each line should contain the same number of fields throughout the file. Spaces are considered part of a field and should not be ignored. The last field in the record must not be followed by a comma. For example:
4. ヘッダと各レコードは、コンマで区切られた、一つ以上のフィールドを含む。各行が保持するフィールドの数は、ファイル全体を通じ、同一であるべきである。スペースは、フィールドの一部とみなす。無視すべきではない。最後のフィールドは、コンマで終わってはならない。例えば、
aaa,bbb,ccc
5. Each field may or may not be enclosed in double quotes (however some programs, such as Microsoft Excel, do not use double quotes at all). If fields are not enclosed with double quotes, then double quotes may not appear inside the fields. For example:
5. (レコード中の) 各フィールドは、それぞれダブルクォーテーションで囲んでも囲わなくてもよい (しかしながら、あるプログラム --Microsoft Excelなど -- は、ダブルクォーテーションを全く用いない) 。フィールドがダブルクォーテーションで囲まれていない場合、そのフィールドの値には、ダブルクォーテーションが含まれてはいけない。例えば、
"aaa","bbb","ccc" CRLF zzz,yyy,xxx
6. Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes. For example:
6. 改行(CRLF)、ダブルクォーテーション、カンマを含むフィールドは、ダブルクォーテーションで囲むべきである。例えば、
"aaa","b CRLF bb","ccc" CRLF zzz,yyy,xxx
7. If double-quotes are used to enclose fields, then a double-quote appearing inside a field must be escaped by preceding it with another double quote. For example:
7. フィールドがダブルクォーテーションで囲まれている場合、フィールドの値に含まれるダブルクォーテーションは、その直前にひとつダブルクォーテーションを付加して、エスケープしなければならない。例えば、
"aaa","b""bb","ccc"
The ABNF grammar [2] appears as follows:
ABNF表記[2]は、以下のようになる。
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 ;as per section 6.1 of RFC 2234 [2] DQUOTE = %x22 ;as per section 6.1 of RFC 2234 [2] LF = %x0A ;as per section 6.1 of RFC 2234 [2] CRLF = CR LF ;as per section 6.1 of RFC 2234 [2] TEXTDATA = %x20-21 / %x23-2B / %x2D-7E
text/csv の登記 (MIME Type Registration of text/csv)This section provides the media-type registration application (as per RFC 2048 [1].
本節は、RFC2048[1]に従った、メディアタイプ登録申請を提供する。
ietf-types@iana.org
Registration of MIME media type text/csv
text
csv
なし
charset, header
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.
CSVでは一般に、US-ASCIIを用いるが、IANAの"text"ツリーで定義されるその他の文字セットも、"charset"パラメータを付与した上で、用いてよい。
The "header" parameter indicates the presence or absence of the header line. Valid values are "present" or "absent". Implementors choosing not to use this parameter must make their own decisions as to whether the header line is present or absent.
"header"パラメータは、ヘッダ行の有無を示す。有効な値は、"present" (存在する) または"absent" (存在しない) である。このパラメータを使用しないこととした実装者は、ヘッダ行の有無を、自身で判断しなければならない。
As per section 4.1.1. of RFC 2046 [3], this media type uses CRLF to denote line breaks. However, implementors should be aware that some implementations may use other values.
RFC2046[3]の4.1.1節のとおり、このメディアタイプは、改行の表示にCRLFを用いる。しかしながら実装者は、他の値を用いた実装があることも念頭に置くべきである。
CSV files contain passive text data that should not pose any risks. However, it is possible in theory that malicious binary data may be included in order to exploit potential buffer overruns in the program processing CSV data. Additionally, private data may be shared via this format (which of course applies to any text data).
CSVファイルが保持するのは、受動的な、何のリスクも生まない、テキストデータである。しかしながら、理論上は、CSVデータを処理するプログラムでバッファ･オーバーランを発生させるような、悪意を持ったバイナリデータが含まれている可能性もある。加えて、個人情報が、このフォーマットで配布されるかもしれない (無論、これはすべてのテキストデータに言えることである) 。
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. An attempt at a common definition can be found in Section 2.
仕様がひとつも存在しなかったため、数々の実装の間には、無視できない差異がある。各実装は、CSVの処理において、「自分が何かするときは保守的に。他者を受け入れるときは革新的に」(RFC793[8])振舞うべきである。世間一般の仕様に対する試行は、2.節を参照されたい。
Implementations deciding not to use the optional "header" parameter must make their own decision as to whether the header is absent or present.
"header"パラメータを使わない、という道を選んだ実装は、ヘッダの有無を、自ら決めなければならない。
While numerous private specifications exist for various programs and systems, there is no single "master" specification for this format. An attempt at a common definition can be found in Section 2.
種々のプログラムやシステムに向けて作られた、非公式の実装は数多いが、「正本」となる仕様は、ただの一つも存在しない。世間一般の仕様に対する試行は、2.節を参照されたい。
Spreadsheet programs and various data conversion utilities
スプレッドシートや、様々なデータ変換ユーティリティ。
なし
CSV
TEXT
Yakov Shafranovich <ietf@shaftek.org>
COMMON
IESG
The IANA has registered the MIME type "text/csv" using the application provided in Section 3 of this document.
IANAは、MIMEタイプ"text/csv"を、3.節の申請によって登記した。
See discussion above in section 3.
3.節での検討事項を参照されたい。
The author would like to thank Dave Crocker, Martin Duerst, Joel M. Halpern, Clyde Ingram, Graham Klyne, Bruce Lilly, Chris Lilley, and members of the IESG for their helpful suggestions. A special word of thanks goes to Dave for helping with the ABNF grammar. The author would also like to thank Henrik Lefkowetz, Marshall Rose, and the folks at xml.resource.org for providing many of the tools used for preparing RFCs and Internet drafts.
A special thank you goes to L.T.S.
[1] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, [RFC 2048|http://www.ietf.org/rfc/rfc2048.txt], November 1996.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", [RFC 2234|http://www.ietf.org/rfc/rfc2234.txt], November 1997.
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", [RFC 2046|http://www.ietf.org/rfc/rfc2046.txt], November
1996.
[4] Repici, J., "HOW-TO: The Comma Separated Value (CSV) File
Format", 2004,
<http://www.creativyst.com/Doc/Articles/CSV/CSV01.htm>.
[5] Edoceo, Inc., "CSV Standard File Format", 2004,
<http://www.edoceo.com/utilis/csv-file-format.php>.
[6] Rodger, R. and O. Shanaghy, "Documentation for Ricebridge CSV
Manager", February 2005,
<http://www.ricebridge.com/products/csvman/reference.htm>.
[7] Raymond, E., "The Art of Unix Programming, Chapter 5", September
2003,
<http://www.catb.org/~esr/writings/taoup/html/ch05s02.html>.
[8] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
Yakov Shafranovich SolidMatrix Technologies, Inc.
EMail: ietf@shaftek.org URI: http://www.shaftek.org
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Funding for the RFC Editor function is currently provided by the Internet Society.
