Re: fputcsv() and $escape character

On Friday, Sep. 22, 2017 at 5:09 PM Christoph M. Becker <cmbecker69@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. Thanks, Theodore Brown