SolidMatrix Technologies, Inc.

ietf@shaftek.org http://www.shaftek.org

CSV MIME comma separated This document documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv".

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, many of which vary from system to system. This document seeks to document the format of comma separated values (CSV) files and to formally register the "text/csv" MIME type for CSV in accordance with RFC 2048.

While there are various specifications and implementations for the CSV format (for ex. , , and ), no formal specification exists which causes a wide variety of interpretations for CSV files. This section seeks to document the format that seems to be followed by most implementations: Each record is located on a separate line delimited by a line break (CRLF). For example: aaa,bbb,ccc CRLF zzz,yyy,xxx CRLF The last record in the file may or may not have an ending line break. For example: aaa,bbb,ccc CRLF zzz,yyy,xxx 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: field_name,field_name,field_name CRLF aaa,bbb,ccc CRLF zzz,yyy,xxx CRLF 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. The last field in the record may not be followed by a comma. For example: aaa,bbb,ccc 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: "aaa","bbb","ccc" CRLF zzz,yyy,xxx Field containing line breaks (CRLF), double quotes and commas should be enclosed in double-quotes. For example: "aaa","b CRLF bb","ccc" CRLF zzz,yyy,xxx If double-quotes are used to enclosed fields, then a double-quote appearing inside a field must be escaped by preceding it with another double quote. For example: "aaa","b""bb","ccc" The ABNF grammar appears as follows: 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 DQUOTE = %x22 ;as per section 6.1 of RFC 2234 LF = %x0A ;as per section 6.1 of RFC 2234 CRLF = CR LF ;as per section 6.1 of RFC 2234 TEXTDATA = %x20-21 / %x23-2B / %x2D-7E

This section provides the media-type registration application (as per RFC 2048, which will be submitted to IANA after IESG approval of this document. 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 Common usage of CSV is US-ASCII, but other character sets as defined by IANA for the "text" tree may be used in conjuction with the "charset" parameter. The "header" parameter indicates the presence or absence of the header line. Valid values are "present" or "absent". Implementators choosing not to use this parameter must make their own decisions as to whether the header line is present or absent. Encoding considerations: As per section 4.1.1. of RFC 2046, this media type uses CRLF to denote line breaks. However, implementors should be aware that some implementations may use other values. Security considerations: CSV files contain passive text data which should not pose any risks. However, it is possible in theory that malicious binary data maybe included in order to exploit potential buffer overruns in the program processing CSV data. Additionally, private data maybe shared via this format (which of course applies to any text data). Interoperability considerations: Due to lack of a single specification there are considerable differences among different implementations. Implementors should "be conservative in what you do, be liberal in what you accept from others" (RFC 793) when processing CSV files. An attempt at a common definition can be found in . Implementations deciding not to use the optional "header" parameter must make their own decision as to whether the header is absent or present. Published specification: 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 . Applications which 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

After IESG approval, IANA is expected to register the MIME type "text/csv" using the application provided in of this document.

See discussion above

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 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.

Innosoft International, Inc.

1050 East Garvey Avenue South West Covina CA 91790 US +1 818 919 3600 +1 818 919 3614 ned@innosoft.com

First Virtual Holdings

25 Washington Avenue Morristown NJ 07960 US +1 201 540 8967 +1 201 993 3032 nsb@nsb.fv.com

STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11 and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing sytem and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. Internet Mail Consortium

675 Spruce Dr. Sunnyvale CA 94086 US +1 408 246 8253 +1 408 249 6205 dcrocker@imc.org

Demon Internet Ltd.

Dorking Business Park Dorking Surrey England RH4 1HN UK paulo@turnpike.com

ABNF Augmented Backus-Naur Form electronic mail Innosoft International, Inc.

1050 East Garvey Avenue South West Covina CA 91790 USA +1 818 919 3600 +1 818 919 3614 ned@innosoft.com

MCI

2100 Reston Parkway Reston VA 22091 +1 703 715-7361 +1 703 715-7436 klensin@mci.net

USC/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90292 USA +1 310 822 1511 +1 310 823 6714 Postel@ISI.EDU

Applications mail media type multipurpose internet mail extensions STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. This fourth document, RFC 2048, specifies various IANA registration procedures for the following MIME facilities: (1) media types, (2) external body access types, (3) content-transfer-encodings. Registration of character sets for use in MIME is covered elsewhere and is no longer addressed by this document. These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US

Creativyst, Inc.

120 Jefferson St. Riverside NJ 08075 USA +1-856-764-5099 http://www.creativyst.com

Edoceo, Inc.

620 W. Olympic Pl. #206 Seatle WA 98119 USA +1-206-378-5619 http://www.edoceo.com

Addison-Wesley

esr@thyrsus.com http://www.catb.org/~esr/

Ricebridge

Waterford Ireland

Discussion about this document should be directed to the IETF-TYPES mailing list which is also reachable via . Of course, comments directly to the author are always welcome.

Copies of this and earlier versions including multiple formats can be found at .

Changes from draft-shafranovich-mime-csv-04 to draft-shafranovich-mime-csv-05: Fixes in ABNF grammar: comma excluded from TEXTDATA and added to escaped text, 2*DQUOTE changed to 2DQUOTE. Changes from draft-shafranovich-mime-csv-03 to draft-shafranovich-mime-csv-04: Fixed ABNF grammar in response to IESG comments: VCHAR changed to TEXTDATA, DQUOTE excluded from TEXTDATA, spaces are included in TEXTDATA, CRLF taken out since CR and LF are already included. Added clarification that double quotes may not be included inside non-quoted fields. Added clarification that the same number of fields should appear in every line. Added the optional "header" parameter to indicate the presence or absence of a header line. Changes from draft-shafranovich-mime-csv-02 to draft-shafranovich-mime-csv-03: Changed text to prohibit the last field ending with a comma matching the ABNF grammar The double quote escaping is now set to two double quotes instead of three Moved some of the references between informative and normative sections Changes from draft-shafranovich-mime-csv-01 to draft-shafranovich-mime-csv-02: Minor errors in ABNF grammar corrected in response to AD comments Minor spelling mistakes corrected Changes from draft-shafranovich-mime-csv-00 to draft-shafranovich-mime-csv-01: Type "text/comma-separated-values" has been removed The "encoding consideration" paragraph of has been changed to allow CRLF only as per section 4.1.1. of RFC 2046. This has been reflected in the ABNF grammar in . ABNF grammar in has been cleaned up. Acknowledgements and status sections were added. CSV format definition was moved to the normative section of the document