Bug #43225 [ReO]: fputcsv incorrectly handles cells ending in \ followed by "

Edit report at https://bugs.php.net/bug.php?id=43225&edit=1 ID: 43225 Updated by: lbarnaud@php.net Reported by: ed at bronto dot com Summary: fputcsv incorrectly handles cells ending in \ followed by " Status: Re-Opened Type: Bug Package: Filesystem function related Operating System: Centos PHP Version: 5.2.4 Block user comment: N Private report: N New Comment: To summarize the related bugs: fputcsv() seems to be using inconsistent and broken escaping of the enclosing char (") : - " followed by \ are not escaped - " not followed by \ are escaped by doubling them (e.g. " becomes ""); leading to inconsistent escaping method - \ themselves are not escaped, leading to generation of invalid CSV if a field is terminated by \: "foo bar\",baz - With the input \\", the " is still considered to be escaped Due to this combinaison of bugs, it is impossible to parse the CSV generated by the following call: fputcsv(STDOUT, ['foo\"bar', 'foo""bar', 'foo bar\\']); Output is: "foo\"bar","foo""""bar","foo bar\" Trying to parse this with a parser using the doubled-char escaping method will break on the first field. Trying to parse this with a parser using the backslash escaping method will break on the 2nd and 3rd fields. Trying to parse this with a parser allowing both methods will break on the 3rd field. Without the 3rd field, parsing this CSV document would result in loss of information (some \ or " from the original input would be lost). Previous Comments: ------------------------------------------------------------------------ [2014-08-21 23:55:57] maris dot radu+phpnet at gmail dot com Just not to confuse people, aharvey@php.net said it's fixed in "5.3.22 and 5.4.12", but in fact I tested in 5.4.31 and it's not fixed. Looking at the patch commit it seems it's tagged with php-5.6.0beta4, so I guess will only be available in 5.6. ------------------------------------------------------------------------ [2013-01-15 09:43:18] aharvey@php.net Sadly, that was a classic case of fixing one thing and breaking another. Reopening, and unassigning myself. ------------------------------------------------------------------------ [2013-01-15 07:35:00] aharvey@php.net Fixed in 5.3.22 and 5.4.12: https://github.com/php/php-src/commit/9b5cb0e8059b1e8bec096067491ed8d75f878938 ------------------------------------------------------------------------ [2013-01-15 07:05:38] aharvey@php.net I've found the cause of this while writing tests for PR 197. php_fputcsv(), while iterating over the fields to be output, has this fairly odd "escaped" concept — once escape_char (which is hardcoded \ at present) is seen, escaping stops until the next enclosure (" by default) is seen. It doesn't matter whether it's the following character or not. After that, escape_char is then ignored anyway, and the enclosure is used as the "escape" character. This came in via https://github.com/php/php-src/commit/af0adbed3963cdee1bfaf5e3a74b029d2b92c8b7 seven years ago to make the use of enclosures optional — the feature in general is good, but this is definitely an issue in the implementation. ------------------------------------------------------------------------ [2009-10-09 19:57:18] mbest at icontact dot com magicaltux@php.net is wrong. This bug is not about fgetcsv but about fputcsv. fputcsv should always escape a double quote to two double quotes. But it doesn't do so if the field contains \" This will mess up the CSV output such that it will not be importable in Excel or other such programs. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=43225 -- Edit this bug report at https://bugs.php.net/bug.php?id=43225&edit=1