Bug #74713 [Com]: CSV cell split after fputcsv() + fgetcsv() round trip.

From: Date: Mon, 10 Sep 2018 16:17:08 +0000
Subject: Bug #74713 [Com]: CSV cell split after fputcsv() + fgetcsv() round trip.
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-216961@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74713&edit=1

 ID:                 74713
 Comment by:         theodorejb at outlook dot com
 Reported by:        andreas at dqxtech dot net
 Summary:            CSV cell split after fputcsv() + fgetcsv() round
                     trip.
 Status:             Open
 Type:               Bug
 Package:            Filesystem function related
 Operating System:   Linux / 3v4l
 PHP Version:        7.1.5
 Block user comment: N
 Private report:     N

 New Comment:

This is still a serious issue which I've run into, and it even affects popular libraries such
as League/CSV. See the discussion on PHP internals here: https://externals.io/message/100729#103145.

Would it be possible to move forward with allowing a blank string to be passed to fputcsv() to fix
this? To me the fact that fputcsv() doesn't support a blank string for the escape character
should be treated as a bug - an RFC should only be needed if we want to change the default behavior
in PHP 8.


Previous Comments:
------------------------------------------------------------------------
[2017-09-21 16:48:38] cmb@php.net

> So how could we achieve this? Do we need an RFC for this?

I've already sent a respective mail to the internals list[1]. If there'll be no
massive objections, I'm planning to pursue the RFC process.

[1] <http://news.php.net/php.internals/100729>

------------------------------------------------------------------------
[2017-09-21 16:09:45] andreas at dqxtech dot net

> It would be better, though, if one could pass an empty
> string or maybe NULL, and perhaps to make that the default in PHP 8.

Yes. So how could we achieve this? Do we need an RFC for this?

------------------------------------------------------------------------
[2017-09-21 11:27:31] cmb@php.net

> Sorry, but "use a user land parser because someone may rely on buggy behavior
> hence we keep" is a bad attitude

Well, this is not really a bug, but rather related to the escape character,
which is a non-standard extension. Removing the escape character may very well
cause a BC break for applications relying on it.

Anyhow, currently, a quite acceptable workaround is to pass "\0" as $escape
argument to fputcsv(). It would be better, though, if one could pass an empty
string or maybe NULL, and perhaps to make that the default in PHP 8.

------------------------------------------------------------------------
[2017-06-12 07:06:32] spam2 at rhsoft dot net

Sorry, but "use a user land parser because someone may rely on buggy behavior hence we
keep" is a bad attitude

------------------------------------------------------------------------
[2017-06-12 02:50:56] andreas at dqxtech dot net

> I'd recommend using a userland CSV parser instead.

Maybe you can write the same thing on the stackoverflow question :)
https://stackoverflow.com/questions/44427926/data-gets-garbled-when-writing-to-csv-with-fputcsv-fgetcsv

------------------------------------------------------------------------


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=74713


--
Edit this bug report at https://bugs.php.net/bug.php?id=74713&edit=1


Thread (11 messages)

« previous php.bugs (#216961) next »