我最初考虑使用Apache Common的csv库的CSVPrinter,它提供了不同的记录分隔符选择。可以是\n
、\r
或\r\n
。或者我可以使用System.lineSeparator()
来设置。但是,这只是为了遵守生产者平台上的行分隔符约定。我担心的是,如果我无法控制消费者选择的平台和语言,我如何最大限度地降低消费者错误地将\r
读取到其解析记录中的风险?例如,如果消费者使用C++,使用getline()读取新行。
- always* 仅仅指定
\n
作为生产者部分的记录分隔符安全吗?那么windows/dos平台上的任何程序都能正确地使用和识别行更改吗?如果我只使用java自己的BufferedWriter.newLine()
,同样的问题还会存在吗?(因为它在生产者系统上写任何行分隔符,但无法控制消费者如何感知它)?
如果仅仅使用\n
是最安全的事情,我不知道为什么在apache commons csv中使用的最流行的CSV格式(或者我是这么想的?)仍然在DEFAULT和EXCEL格式中将recordseparator设置为\r\n
?
1条答案
按热度按时间7kqas0il1#
tl; d天
根据RFC 4180,使用CRLF(回车,换行)终止行,RFC 4180是CSV表格数据文件的唯一编写良好的规范。
遵循规范:CRLF语言
各种各样的人一直在用各种各样的格式写各种各样的文档......一直以来都把它们叫做“CSV”。经过几十年的麻烦和困惑,一些人终于写下了“CSV”确切含义的规范。这个规范是由The Internet Society(2005)通过Internet Engineering Task Force (IETF)发布的。
RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files,是CSV格式的规范。RFC 7111对该规范进行了扩充。
👉 RFC 4180要求CRLF作为delimiters行。RFC 4180的第2.1节明确规定:
每个记录都位于单独的行上,由换行符(CRLF)分隔。
因此,以CARRIAGE RETURN和LINE FEED结束每一行。Unicode code points是13和10(十进制)。
**每个平台都可以解析CRLF。**告知CSV文件的使用者您使用的是RFC 4180标准格式,包括CRLF行delimiters。
顺便说一句...... RFC 4180十年后,W3C感到有必要编写自己的标准,以解决RFC 4180规范的缺陷。如果你觉得有必要,研究一下Model for Tabular Data and Metadata on the Web和related documents。W3C以惊人的决心宣布行终结符为...... CRLF * 或 * LF。是的,一个有意识地写得“不”具体的说明。我建议您坚持使用RFC 4180。甚至W3C也说行尾“应该是CRLF”。
Apache Commons CSV 支持RFC 4180
您正在使用Apache Commons CSV库。请注意,该库提供了一个支持RFC 4180标准格式的预定义
CSVFormat
类:CSVFormat.RFC4180
.你问:
我不确定为什么... apache commons csv仍将recordseparator设置为\r\n
因为标准这么说。