Bug #50686 [Com]: fputcsv and fgetcsv doesn't follow CSV format

Edit report at https://bugs.php.net/bug.php?id=50686&edit=1 ID: 50686 Comment by: office at williamhollandschool dot com Reported by: thuejk at gmail dot com Summary: fputcsv and fgetcsv doesn't follow CSV format Status: Wont fix Type: Bug Package: Filesystem function related Operating System: * PHP Version: 5.*, 6 Assigned To: iliaa Block user comment: N Private report: N New Comment: I see that the versions entry only lists 5.* and 6. I use PHP 7 and the "escape" character thing has caused me no end of grief in trying to implement import and export of natural language documents into and out of CSV format to later be interpreted by MariaDB's LOAD INFILE. Even trying the workaround that's posted everywhere of putting the "escape" character the same as the enclosure character only caused it to fail to escape any enclosure characters. Having to generate then fix giant files by hand is what has driven me to Python for this task. Many, many things are still using CSV. Not the most important bug in PHP 7, but one that has annoyed me to no end. Previous Comments: ------------------------------------------------------------------------ [2016-01-05 14:08:11] minexew at gmail dot com Is there any chance that this will be fixed? As of today, the documentation for fgetcsv is still misleading and there is no simple workaround. ------------------------------------------------------------------------ [2010-05-30 12:38:14] david at davidhoulder dot com I've written a CSV parser in PHP that could easily be converted to C to form the basis of a fix for this. Go to http://www.ubercart.org/project/uc_stock_update-2x and grab the latest uc_stock_update-*.tar.gz In that tarball you'll find uc_stock_update/ReadCSV.inc which uses a finite state machine to parse a CSV file. I think it handles RFC4180-compliant files correctly, although it currently tolerates many error cases. There's a little test suite in uc_stock_update/tests/ . Feedback welcome (see the download page). ------------------------------------------------------------------------ [2010-04-30 22:35:59] rememb70 at yahoo dot com Thanks for all your hard work PHP! Forgive the ego of thuejk and provide replacement functions. It was very disappointing to fully implement code utilizing these and then discover that they are incompatible with actual csv files. Thanks. ------------------------------------------------------------------------ [2010-01-11 14:23:08] thuejk at gmail dot com The spec existed before PHP's function was written, just not in RFC form, but in actual program implementations. For example I just tested Excel from Office 2000, and it also can't recognize CSV output from fputcsv (it chokes on the same string from my first post as OpenOffice). IMO, just because there were no formal RFC before 2005 does not mean you can choose whatever format rules you like, and still call it CSV. Do you have any examples of CSV implementations which actually use the same format as fgetcsv()? If all spreadsheets disagree (Excel and OpenOffice tested), then you are probably doing something wrong. In any case, I can understand if you want to keep the current fgetcsv for backwards-compatibility. But you really need to prominently display a warning on its manual page that "fgetcsv and fputcsv are incompatible with RFC 4180, Microsoft Excel, OpenOffice Calc, and probably most other CSV implementations." since the PHP function (misleadingly IMO) contains CSV in its name. Also, as I mentioned in the first post here, fputcsv does not double quotes for the input string (PHP format) '\\"' - the output of that is (PHP format) '\\"'. ------------------------------------------------------------------------ [2010-01-11 02:55:18] iliaa@php.net The PHP's behaviour on this matter was established before the spec written and the implementation of fgetcsv() will continue to support \ escape character. The fputcsv() function already uses "" for escaping. ------------------------------------------------------------------------ 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=50686 -- Edit this bug report at https://bugs.php.net/bug.php?id=50686&edit=1