Re: fgetcsv incompatible with fputcsv

Tjerk Meesters wrote: >> On 20 Nov 2014, at 00:26, Christoph Becker <cmbecker69@gmx.de> wrote: >> >> Are you aware of >> <https://bugs.php.net/bug.php?id=50686>? It seems this >> very inconsistency has been reported a few years ago, but has been >> tagged as "Wont fix" back then. > > Actually that bug report seems to suggest that fputcsv() uses backslash to encode enclosure > characters, but AFAICT it doesn’t. Apparently, there is a somewhat hidden bug, see <http://3v4l.org/El5Xs> for a simplified test script. The expected result is string(14) ""a""b","a\""b"" or maybe string(14) ""a\"b","a\\"b"" The actual result makes no sense to me, even though str_getcsv() parses it "correctly". > And then there are bug reports like > https://bugs.php.net/bug.php?id=67566 which were fixed but really > just made the situation worse =( ACK. >> <https://bugs.php.net/bug.php?id=38929> also seems to >> deal with this >> inconsistency, and had been tagged as "Not a bug". >> >> So maybe an RFC is appropriate? > > Yeah, I didn’t realise the can of worms until I opened it; I’ll round up all the bug > reports and run them against whatever RFC I can get my hands on. > > PS: Favourite quote from the semi-authoritative spec of Perl_CSV: > http://rath.ca/Misc/Perl_CSV/CSV-2.0.html#csv: > >> Given that the essence of CSV files is simplicity, I have decided to reject all escape and >> escaped characters with the exception of quoation marks appearing within quotation marks … > > Good times :) One might argue that the essence of CSV files is being a data exchange format, so applying Postel's law would be reasonable. :) -- Christoph M. Becker