Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79046
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender)
Message-ID: <546E2FA1.1010006@gmx.de>
Date: Thu, 20 Nov 2014 19:14:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Tjerk Meesters <tjerk.meesters@gmail.com>
CC: PHP Internals <internals@lists.php.net>
References: <82139FDD-8D8B-43D9-B811-ECC1FFE6E8A6@gmail.com> <546CC4C8.7010001@gmx.de> <8E49EAC8-3681-4E36-BDAD-163D292193DD@gmail.com>
In-Reply-To: <8E49EAC8-3681-4E36-BDAD-163D292193DD@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: fgetcsv incompatible with fputcsv
From: cmbecker69@gmx.de (Christoph Becker)

Tjerk Meesters wrote:

>> On 20 Nov 2014, at 00:26, Christoph Becker <cmbecker69@gmx.de> wrote:
>>
>> Are you aware of <https://bugs.php.net/bug.php?id=50686>?  It seems this
>> very inconsistency has been reported a few years ago, but has been
>> tagged as "Wont fix" back then.
> 
> Actually that bug report seems to suggest that fputcsv() uses backslash to encode enclosure characters, but AFAICT it doesn’t.

Apparently, there is a somewhat hidden bug, see <http://3v4l.org/El5Xs>
for a simplified test script.  The expected result is

  string(14) ""a""b","a\""b""

or maybe

  string(14) ""a\"b","a\\"b""

The actual result makes no sense to me, even though str_getcsv() parses
it "correctly".

> And then there are bug reports like https://bugs.php.net/bug.php?id=67566 which were fixed but really just made the situation worse =(

ACK.

>> <https://bugs.php.net/bug.php?id=38929> also seems to deal with this
>> inconsistency, and had been tagged as "Not a bug".
>>
>> So maybe an RFC is appropriate?
> 
> Yeah, I didn’t realise the can of worms until I opened it; I’ll round up all the bug reports and run them against whatever RFC I can get my hands on.
> 
> PS: Favourite quote from the semi-authoritative spec of Perl_CSV: http://rath.ca/Misc/Perl_CSV/CSV-2.0.html#csv:
> 
>> Given that the essence of CSV files is simplicity, I have decided to reject all escape and escaped characters with the exception of quoation marks appearing within quotation marks …
> 
> Good times :)

One might argue that the essence of CSV files is being a data exchange
format, so applying Postel's law would be reasonable. :)

-- 
Christoph M. Becker