Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100745
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.43 cause and error)
MIME-Version: 1.0
In-Reply-To: <7cf5adb8-0738-259e-6d1e-f966722fdae2@gmx.de>
References: <7cf5adb8-0738-259e-6d1e-f966722fdae2@gmx.de>
Date: Fri, 22 Sep 2017 02:55:26 +0200
Message-ID: <CAH0Uv3HMcyfofbKVJ+PV2z-aX4NpiT-X39Y_dOo0tyBohW-ihA@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] fputcsv() and $escape character
From: andreas@dqxtech.net (Andreas Hennings)

On Thu, Sep 21, 2017 at 1:43 PM, Christoph M. Becker <cmbecker69@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.