On 09.09.2018 at 16:55, Theodore Brown wrote: > On Friday, Sep. 22, 2017 at 5:09 PM Christoph M. Becker <cmbecke...@gmx.de> > wrote: > >>>> 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. >>> >>> 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. >>> >>> 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. >>> >>> Touching the existing code is pretty certain to bring a lot of pain, >>> without resulting in a fully compliant csv parser/generator. >> >> And frankly, I don't see why it would be a problem to allow to use no >> escape character for `fputcsv()`. That certainly wouldn't be a BC break, >> since currently the function bails out if `escape_str_len < 1`. Of >> course, that wouldn't fix all issues, but it appears to make the >> function work as expected for ASCII compatible character encodings (for >> other character encodings the function appears to be broken anyway). >> >> Ad league/csv: rather impressive! However, including this functionality >> into ext/standard is totally over the top, in my opinion. > > Ironically, the League/Csv library uses `fputcsv()` behind the scenes, and > thus suffers from the same escape character problem > (see https://github.com/thephpleague/csv/issues/307). > > Is there any chance `fputcsv()` can be updated to allow setting a blank > string as the escape character? As Christopher pointed out, this would not > be a BC break, and while it wouldn't fix every issue with the function it > would still be a step forward. Frankly I found it very surprising that the > function *didn't* support passing a blank string.
I've submitted <https://github.com/php/php-src/pull/3515>. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
