ID: 50686
User updated by: thuejk at gmail dot com
Reported By: thuejk at gmail dot com
Status: Wont fix
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5.*, 6
Assigned To: iliaa
New Comment:
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) '\\"'.
Previous Comments:
------------------------------------------------------------------------
[2010-01-11 02:55:18] il...@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 :).
------------------------------------------------------------------------
[2010-01-09 18:46:49] j...@php.net
No, you send us the tests provided as PHPTs like any other test is in
our test suite. Not the other way around.
------------------------------------------------------------------------
[2010-01-09 15:48:01] thuejk at gmail dot com
I have written a test suite (for my own local replacement functions for
fcsvget/put). So if you reimplement the PHP functions then you might
want to send me your new implementation, so I can run it through the
test suite.
------------------------------------------------------------------------
[2010-01-08 13:05:37] thuejk at gmail dot com
Also, according to RFC 4180, CSV lines should be terminated by \r\n,
not \n.
Since CSV is a data exchange format, the line termination should not be
dependent on the system generating the CSV file.
fputcsv() currently terminates CSV-lines with \n on my Linux server.
----
PS: I just noticed that RFC 4180 is from 2005, so you have some excuse,
since the PHP function predates the RFC. However, the RFC cites 4
previous non-RFC definitions, which all agree with the RFC on the
important points, so it is not clear that the PHP implementation ever
had any right to claim it had anything to do with the CSV format. And of
course at least OpenOffice's CSV-support, and probably many other
programs, can't work with the input/output of the PHP functions.
------------------------------------------------------------------------
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
http://bugs.php.net/50686
--
Edit this bug report at http://bugs.php.net/?id=50686&edit=1
