(registered by RFC 4180, last updated 2014-01-17)
Type name: text
Subtype name: csv
Required parameters: none
Optional parameters: charset, header
The "charset" parameter specifies the charset employed by the
CSV content. In accordance with RFC 6657 [RFC6657], the
charset parameter SHOULD be used, and if it is not present,
UTF-8 SHOULD be assumed as the default (this implies that US-
ASCII CSV will work, even when not specifying the "charset"
parameter). Any charset defined by IANA for the "text" tree
may be used in conjunction with the "charset" parameter.
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.
Encoding considerations: CSV MIME entities consist of binary data
[RFC6838]. As per section 4.1.1. of RFC 2046 [RFC2046], this
media type uses CRLF to denote line breaks. However, implementers
should be aware that some implementations may use other values.
Security considerations:
Text/csv consists of nothing but passive text data that should
not pose any direct risks. However, it is possible that
malicious data may be included in order to exploit buffer
overruns or other bugs in the program processing the text/csv
data.
The text/csv format provides no confidentiality or integrity
protection, so if such protections are needed they must be
supplied externally.
The fact that software implementing fragment identifiers for
CSV and software not implementing them differs in behavior, and
the fact that different software may show documents or
fragments to users in different ways, can lead to
misunderstandings on the part of users. Such misunderstandings
might be exploited in a way similar to spoofing or phishing.
Implementers and users of fragment identifiers for CSV text
should also be aware of the security considerations in RFC 3986
[RFC3986] and RFC 3987 [RFC3987].
Interoperability considerations: Due to lack of a single
specification, there are considerable differences among
implementations. Implementers should "be conservative in what you
do, be liberal in what you accept from others" (RFC 793 [RFC0793])
when processing CSV files. An attempt at a common definition can
be found in Section 2. 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 Section 2 of RFC 4180 [RFC4180].
Applications that use this media type: Spreadsheet programs and
various data conversion utilities.
Fragment identifier considerations: Fragment identification for
text/csv is supported by using fragment identifiers as specified
by RFC7111.
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 and Erik Wilde
Intended usage: COMMON
Restrictions on usage: none
Author: Yakov Shafranovich and Erik Wilde
Change controller: IESG