Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103285
To: Pierre Joye <pierre.php@gmail.com>, Stas Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <d46e41f8-e483-8425-280e-42cc04f21242@gmx.de>
 <3081944c-4e55-f303-fddd-7f03cff04034@gmail.com>
 <CAEZPtU6A3LdUWcSJi3Y-Co0yhekhTrqkfcUe+EMq2phq2bA1fA@mail.gmail.com>
Message-ID: <b5397964-263f-8cc0-70c5-e4a58f1ffb2b@gmx.de>
Date: Sun, 30 Sep 2018 12:20:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <CAEZPtU6A3LdUWcSJi3Y-Co0yhekhTrqkfcUe+EMq2phq2bA1fA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Kill proprietary CSV escaping mechanism
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 30.09.2018 at 06:06, Pierre Joye wrote:

> On Fri, Sep 28, 2018, 2:00 PM Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
> 
>>> I hereby put the “Kill proprietary CSV escaping mechanism” under
>> discussion:
>>>
>>> <https://wiki.php.net/rfc/kill-csv-escaping>
>>
>> For fputcsv (and generally writing) this is probably OK. I am much more
>> concerned about reading - this may make files generated by PHP be
>> unreadable by php. And some use cases keep archives for a very long
>> time. Trying to find something in a backup and discovering that your
>> code is not longer able to read your data is no fun.
> 
> This is a very good point. Removing it in read mode is going to break
> things badly out there (I had a few projects using it. We need a sensible
> decision here.

If we cannot eventually get rid of the escaping for CSV reading (note
that I proposed to keep the possibility to use it until PHP *9*), I
don't think that we should remove it for CSV writing either, since that
would make SplFileObject::setCsvControl() and ::getCsvControl() pretty
much confusing.  Consequently, it wouldn't make sense to deprecate using
a non-empty string as $escape, and therefore we can't change the
default.  So we're basically left with
<https://github.com/php/php-src/pull/3515>, which, in my opinion,
doesn't need an RFC at all.

Anybody who uses the escaping mechanism (deliberately or unwittingly)
should be aware of the roundtrip issues (see
<https://bugs.php.net/74713> and <https://bugs.php.net/76940>), though.

-- 
Christoph M. Becker