RFC 4180

Common Format and MIME Type for Comma-Separated Values (CSV) Files

๐Ÿ“… published October 2005, from ietf

Common Format and MIME Type for Comma-Separated Values (CSV) Files ๐Ÿ“„โœจ

Title block, bestie ๐ŸŽ€

  • RFC number: 4180
  • Written by: Yakov Shafranovich, SolidMatrix Technologies, Inc. ๐Ÿ’…
  • Category: Informational (this is info, not a binding standard ๐Ÿ™ˆ)
  • Date: October 2005 ๐Ÿ“
  • Obsoletes / Updates: the title block doesn't list either one ๐ŸŒธ

Network Working Group โœจ Request for Comments: 4180 โœจ Category: Informational โœจ October 2005


Status of This Memo ๐ŸŒˆ

okay so this memo gives info to the Internet community. it does not specify an Internet standard of any kind. distribution is unlimited, so share it with everyone ๐Ÿซถ

Copyright (C) The Internet Society (2005).

Abstract โœจ

this RFC writes down the format people use for Comma-Separated Values (CSV) files, and it registers the MIME type "text/csv" ๐Ÿ”ฅ

Table of Contents ๐Ÿงญ

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. Introduction ๐Ÿฆ‹

ok the comma separated values format (CSV) has been used for ages to swap and convert data between spreadsheet programs. it's SO common, but nobody ever wrote down a formal spec for it ๐Ÿ’€ the IANA MIME registry has a "text/tab-separated-values" entry, but CSV never got an IANA MIME registration. meanwhile different programs and operating systems started using their own MIME types for it, which is chaotic ๐Ÿ˜ญ so this RFC documents the CSV format and formally registers "text/csv" for CSV, following RFC 2048 [1] ๐Ÿ‘‘

2. Definition of the CSV Format ๐ŸŽ€

there are a bunch of specs and implementations floating around for CSV (for ex. [4], [5], [6] and [7]), but there's no formal spec, so everyone can interpret CSV files a little differently. this section writes down the format that most implementations seem to follow ๐Ÿ’–

  1. Each record is on its own line, and lines end with a line break (CRLF). for example:
aaa,bbb,ccc CRLF
zzz,yyy,xxx CRLF
  1. The last record in the file may or may not have an ending line break. for example:
aaa,bbb,ccc CRLF
zzz,yyy,xxx
  1. There may be an optional header line as the first line of the file, with the same format as the normal record lines. the header holds names for the fields in the file, and it should have the same number of fields as the records in the rest of the file. whether the header line is there or not should be shown with the optional "header" parameter of this MIME type ๐Ÿงš for example:
field_name,field_name,field_name CRLF
aaa,bbb,ccc CRLF
zzz,yyy,xxx CRLF
  1. Inside the header and each record there can be one or more fields, separated by commas. each line should have the same number of fields all the way through the file. spaces count as part of a field and should not be ignored ๐Ÿซง the last field in a record must not be followed by a comma. for example:
aaa,bbb,ccc
  1. Each field may or may not be wrapped in double quotes (but some programs, like Microsoft Excel, never use double quotes at all ๐Ÿ™ˆ). if a field isn't wrapped in double quotes, then double quotes may not appear inside that field. for example:
"aaa","bbb","ccc" CRLF
zzz,yyy,xxx
  1. Fields that contain line breaks (CRLF), double quotes, and commas should be wrapped in double quotes. for example:
"aaa","b CRLF
bb","ccc" CRLF
zzz,yyy,xxx
  1. If double quotes are used to wrap fields, then a double quote appearing inside a field must be escaped by putting another double quote in front of it. for example:
"aaa","b""bb","ccc"

The ABNF grammar [2] looks like this ๐Ÿง

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

3. MIME Type Registration of text/csv ๐Ÿ’…

this section is the media-type registration application for text/csv, as per RFC 2048 [1]. here's the whole template, verbatim ๐Ÿ“ฎ

To: ietf-types@iana.org

Subject: Registration of MIME media type text/csv

MIME media type name: text

MIME subtype name: csv

Required parameters: none

Optional parameters: charset, header

the optional charset parameter: common CSV usage is US-ASCII, but other character sets IANA has defined for the "text" tree can be used with the "charset" parameter ๐ŸŒ

the optional header parameter says whether the header line is present or absent. valid values are "present" or "absent". implementors who choose not to use this parameter must make their own decisions about whether the header line is present or absent ๐Ÿซถ

Encoding considerations: as per section 4.1.1. of RFC 2046 [3], this media type uses CRLF to denote line breaks. implementors should be aware that some implementations may use other values ๐Ÿ‘€

Security considerations: CSV files contain passive text data that should not pose any risks. however, in theory, malicious binary data could be included to exploit potential buffer overruns in the program that processes the CSV data. also, private data may be shared via this format (which, of course, applies to any text data) ๐Ÿ˜ฑ

Security note: a CSV file can carry malicious binary data that aims at buffer overruns in the parser, and it can leak private data. handle inputs with care, bestie ๐Ÿ”ฅ

Interoperability considerations: because there's no single specification, implementations differ quite a bit ๐Ÿ’€ 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 is in Section 2. implementations that decide not to use the optional "header" parameter must make their own decision about whether the header is absent or present โœจ

Published specification: lots of private specs exist for various programs and systems, but there's no single "master" spec for this format. an attempt at a common definition is in Section 2 ๐ŸŽ€

Applications that use this media type: spreadsheet programs and various data conversion utilities ๐Ÿ“Š

Additional information:

  • Magic number(s): none
  • File extension(s): CSV
  • Macintosh File Type Code(s): TEXT

Person & email address to contact for further information: Yakov Shafranovich <ietf@shaftek.org> ๐Ÿ’Œ

Intended usage: COMMON

Author/Change controller: IESG

4. IANA Considerations ๐ŸŒธ

IANA has registered the MIME type "text/csv" using the application given in Section 3 of this document ๐ŸŽ‰

5. Security Considerations ๐Ÿ›ก๏ธ

see the discussion above in Section 3 ๐Ÿ™ˆ

6. Acknowledgments ๐Ÿซถ

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 to prepare RFCs and Internet drafts ๐Ÿงš

a special thank you goes to L.T.S. ๐Ÿ’œ

7. References ๐Ÿ“š

7.1. Normative References

  • [1] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
  • [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

7.2. Informative References

Author's Address ๐Ÿ“ฎ

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.

Intellectual Property ๐Ÿ”

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 claim to have made any independent effort to identify any such rights. information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get 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 online 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 send that information to the IETF at ietf-ipr@ietf.org ๐Ÿซถ

Acknowledgement ๐ŸŒˆ

Funding for the RFC Editor function is currently provided by the Internet Society โœจ

๐Ÿ“ฆ where this page comes from