Req #38301 [Opn]: field enclosure behavior in fputcsv
| From: | cmb@php.net | Date: | Thu, 13 Sep 2018 12:36:31 +0000 |
| Subject: | Req #38301 [Opn]: field enclosure behavior in fputcsv | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-217028@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=38301&edit=1
ID: 38301
Updated by: cmb@php.net
Reported by: programmer at tklee dot com
Summary: field enclosure behavior in fputcsv
Status: Open
Type: Feature/Change Request
Package: Filesystem function related
Operating System: Linux
PHP Version: 5.1.4
Block user comment: N
Private report: N
New Comment:
<https://github.com/php/php-src/pull/3515>
would implement this
feature request.
Previous Comments:
------------------------------------------------------------------------
[2018-09-13 12:35:47] cmb@php.net
Related To: Bug #43225
------------------------------------------------------------------------
[2018-09-12 22:53:36] cmb@php.net
Related To: Bug #74713
------------------------------------------------------------------------
[2014-12-04 08:09:59] programmer at tklee dot com
Wow! After 8.5 years! That's dedication!
Thank you for your answer to issue 2.
If we can address issue 1, then issue 2 can be solved at the same time. Allowing "" to be
the quote char is actually a closer implementation of RFC 4180. Users can choose whether or not to
enclose the field with something.
In short, can we accept "" as the 4th parameter of fputcsv?
Thanks for reconsidering.
------------------------------------------------------------------------
[2014-12-02 23:57:26] datibbaw@php.net
As far as expected behaviour goes, RFC 4180 states:
> Each field may or may not be enclosed in double quotes
Also, there's a provision that states:
> Spaces are considered part of a field and should not be ignored.
That said, while I agree that spaces (or tabs, if not the delimiter) in a field do not strictly
require an enclosure (unlike newlines or the enclosure character itself), the only thing coming
close to a standard doesn't forbid it.
------------------------------------------------------------------------
[2006-08-03 00:17:01] programmer at tklee dot com
Description:
------------
Regarding the field enclosure parameter in fputcsv...
1. It's unrealistic to require the field enclosure to be one character because it's very
common to have "empty string" as the field delimiter (especially when TAB is used as field
delimiter). I tried to use "\0" as the field enclosure, hoping that'd be interpreted
as an empty string, but fputcsv translated it into literal.
2. fputcsv wrongly adds the field enclosures whenever a field contains a space. The expected
behavior should be adding the field enclosures when a field contains a field delimiter.
Reproduce code:
---------------
/*
test_in.csv has only one line:
$line = "field 0\tfield_1\tfield 2\n";
*/
$fh_in=fopen("test_in.csv","r");
$fh_out=fopen("test_out.csv","w");
// since "" is not accepted as the 4th parameter, I use "\0" instead
$fields = fgetcsv($fh_in, 0, "\t", "\0");
fputcsv($fh_out, $fields, "\t", "\0");
close($fh_in);
close($fh_out);
Expected result:
----------------
/*
One would expect to see in test_out.csv :
$line = "field 0\tfield_1\tfield_2\n";
*/
Actual result:
--------------
/*
However, the result shows:
$line = "\0field 0\0\tfield_1\t\0field 2\0\n";
Unexpected:
1. Since space is not the field delimiter, there is no point of using the field enclosure.
2. Empty enclosure is very common and should be accepted.
*/
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=38301&edit=1