Re: fputcsv() and $escape character
| From: | Andreas Hennings | Date: | Fri, 22 Sep 2017 00:39:48 +0000 |
| Subject: | Re: fputcsv() and $escape character | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-100744@lists.php.net to get a copy of this message | ||
On Thu, Sep 21, 2017 at 11:08 PM, Dan Ackroyd <danack@basereality.com> wrote:
> On 21 September 2017 at 12:43, Christoph M. Becker <cmbecker69@gmx.de> wrote:
>> Hi everybody!
>>
>> There are several bug reports regarding "broken" fputcsv() behavior in
>> our tracker, namely, because the $escape parameter causes unexpected
>> results. For instance:
>
>
> I looked at fixing some of the CSV related bugs about a year or so
> ago. My conclusions were:
>
> i) There is no way to fix the problems that wouldn't cause horrible BC
> breaks for code that is only coincidentally working currently.
How so?
What we can do:
If $escape_char !== '', fputcsv() should work exactly as it does now.
It can even use the same C code.
If $escape_char === '', fputcsv() will have a different behavior than
currently, where no character is treated as special.
If we want to be 100% sure, these two cases can use completely
separate C code, with one if() at the entry point.
>
> ii) Handling strings in C is much more error prone than handling them in PHP.
>
> I'm reasonably certain that trying to fix the current functions is the
> wrong approach, and one of the following would be much better.
>
> Either, find a C library that has already been proven to handle CSV
> parsing/generating 'correctly' and bring that into PHP core under
> either new function names or namespace.
Yeah why not. But it will require a lot more work and design decisions
than just introducing a new allowed value for $enclosure parameter.
>
> Or, write the code in PHP (or just use
> https://github.com/thephpleague/csv) and find a way to make
> that fast
> enough for people to use.
It can never be as fast as native functions.
I vaguely remember something like factor 2 or 3 when I tried it, but
for now treat this as hearsay.
>
> Touching the existing code is pretty certain to bring a lot of pain,
> without resulting in a fully compliant csv parser/generator.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>