Re: [RFC] Kill proprietary CSV escaping mechanism

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