Req #38301 [Opn]: field enclosure behavior in fputcsv

From: 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

« previous php.bugs (#217028) next »