On Thu, Sep 21, 2017 at 1:43 PM, Christoph M. Becker <cmbecke...@gmx.de> wrote: > I don't think the current behavior is a bug, but rather the escape > character is an extension to the CSV "standard" (RFC 7111).
Are you sure you mean RFC 7111 ? I was just parrotting the number in my previous email, but now I looked it up and only find this: https://tools.ietf.org/html/rfc7111 This talks about uri fragments with CSV, not CSV itself. RFC 4180 seems to be closer to what we are looking for: https://tools.ietf.org/html/rfc4180#section-2 fputcsv() and fgetcsv() already have a number of extensions to this format, which I think are not harmful and that we should keep: - option to choose a different delimiter - option to choose a different enclosure - option to have a different number of cells per row. - fgetcsv() has some tolerance for broken CSV, that we should continue to support. In the stackoverflow discussion, someone argues that line breaks are not part of the standard / not portable: https://stackoverflow.com/questions/44427926/data-gets-garbled-when-writing-to-csv-with-fputcsv-fgetcsv/46342634#comment75882780_44427926 However, the RFC 4180 that I found clearly mentions them: > 6. Fields containing line breaks (CRLF), double quotes, and commas should be > enclosed in double-quotes. So, all we would change is the escape behavior. In RFC 4180, it says: > 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
