On Fri, Sep 22, 2017 at 1:20 PM, Christoph M. Becker <cmbecke...@gmx.de> wrote: >> please make sure the behaviour of common applications, most notably >> Excel, is considered and tested. In my experience it has its own quirks, >> and it's likely that a large proportion of users require >> interoperability with it. It may be there's nothing relevant to >> consider, but I thought I'd mention it, in case people get too caught up >> with a specification that nobody actually follows. > > That's exactly the point of this proposal. As it is, fputcsv() outputs > CSV that won't be understood by Excel (or any other CSV aware > implementation I'm aware of), as soon as the escape character is > actually part of any string. So being able to avoid any such escaping > would be helpful wrt. major CSV implementations, and making that the > default even more so.
The other problem that this proposal wants to fix is that CSV cannot currently be used reliably to store or transport data between different PHP scripts, due to this bug: https://bugs.php.net/bug.php?id=74713&edit=2 > If one cell of the data sent to fputcsv() contains > "{$enclosure}{$escape_char}{$escape_char}{$enclosure}{$delimiter}", this cell > will be split after a round trip of fputcsv() + fgetcsv(). > > The only other issue that I can see is that currently our fputcsv() > hard-codes the line endings to LF (while RFC 4180 demands CRLF), but > that may not be a real problem anymore. (Well, there might be issues > with non ASCII compatible character encodings as well). I have opened a lot of php-generated CSV files with LibreOffice Calc, and the line endings have not been a problem. I assume Excel and OpenOffice would also be ok with it. I'd say stick with existing behavior for BC reasons, or discuss it separately. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
