On 21.09.2017 at 20:01, Rowan Collins wrote: > On 21 September 2017 18:32:57 BST, Andreas Hennings <andr...@dqxtech.net> > wrote: > >> So empty string would enable the standard behavior RFC 7111 with no >> escape char. >> If so, I support this. > > Just a note regarding standards:
Actually, there is no accepted standard regarding CSV. RFC 7111 is just an update to RFC 4180 (sorry, I've messed that up), but anyway both are just informational. > 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 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). -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
