Edit report at https://bugs.php.net/bug.php?id=50686&edit=1
ID: 50686
Comment by: minexew at gmail 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:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2010-01-10 19:21:57] thuejk at gmail dot com
I will consider doing the work to port the tests if you will commit to actually use them.
I assume you can't change the functions (until PHP 6 at least), since people may depend on
their current behavior. So I assume you will just add a "THIS IS NOT REALLY CSV FORMAT"
warning to the manual page, and perhaps add a strict warning when using the functions.
So I assume that any CSV functions will be new functions, which you will have to commit to making
first.
So say you will make the CSV functions (and please also make string versions of both functions this
time), then I will consider doing the effort of porting my tests :).
------------------------------------------------------------------------
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