Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78997
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
Message-ID: <546CAB88.4040809@gmail.com>
Date: Wed, 19 Nov 2014 14:39:04 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <82139FDD-8D8B-43D9-B811-ECC1FFE6E8A6@gmail.com>
In-Reply-To: <82139FDD-8D8B-43D9-B811-ECC1FFE6E8A6@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: fgetcsv incompatible with fputcsv
From: rowan.collins@gmail.com (Rowan Collins)

Tjerk Meesters wrote on 19/11/2014 12:20:
> Hi list,
>
> As I was fiddling with CSV data reading and writing I noticed that fgetcsv() is inherently incompatible with fputcsv() when it comes to the enclosure escape character that’s used.
>
> Example: http://3v4l.org/LHEZj
>
> The above example code demonstrates how, by default, fputcsv() encodes a backslash as is but fgetcsv() will treat that same backslash as the enclosure escape character as well as the enclosure character itself; this is rather surprising behaviour and imho unnecessarily complicated.
>
> I would suggest changing the behaviour in such a way that:
> a) the default enclosure escape character for fgetcsv() is a double quote.
> b) fgetcsv() only treats the escape character as … an escape character.
>
> Due to the kind of change BC can’t be maintained, so I’d propose this change for PHP 7.
>
> If anyone has violent objections to the above, or thinks that an RFC should be drawn up, do let me know … otherwise I’ll commit the change into master by next week or so.
>
>
> Best,
>   Tjerk

If I remember rightly, some of the escaping behaviour is actually 
incompatible with MS Excel (I believe 2000 was the current version when 
I tested) as well, which struck me as rather unfortunate.

However, I'm always a bit wary of subtle breaking changes like this, so 
we need to be sure we definitely get it right this time, and that there 
are documented options to both functions which emulate the old behaviour.

Regards,
-- 
Rowan Collins
[IMSoP]