Req #55413 [Com]: str_getcsv doesnt remove escape characters

From: Date: Mon, 24 Jul 2017 21:45:45 +0000
Subject: Req #55413 [Com]: str_getcsv doesnt remove escape characters
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-210297@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=55413&edit=1

 ID:                 55413
 Comment by:         dan dot libby at gmail dot com
 Reported by:        mathielen at gmail dot com
 Summary:            str_getcsv doesnt remove escape characters
 Status:             Wont fix
 Type:               Feature/Change Request
 Package:            Strings related
 Operating System:   ubuntu 11.04
 PHP Version:        5.3.6
 Assigned To:        colinodell
 Block user comment: N
 Private report:     N

 New Comment:

imho, this bug should not have been closed without at least updating the documentation to match what
the code actually does.

I just checked, and the online docs still say default="\\" without any comment that this
is basically a no-op and doesn't escape anything.

In order to achieve escaping then, one must use/have excel-style escaping in the source document AND
explicitly set escape='"'.

That seems totally broken and bizarre to me.

Further, one cannot always control the format of source document.  Consider if reading files from a
third-party.

I would urge you to reconsider and either fix docs or fix the function to be more useful.


Previous Comments:
------------------------------------------------------------------------
[2017-07-24 21:15:34] colinodell@php.net

Closing this because PHP does indeed have the ability to process escaped characters, but they must
be escaped the CSV way.

(Processing backslash-escaped characters would therefore be a feature change which may impact
backward compatibility.)

------------------------------------------------------------------------
[2017-07-24 21:03:09] colinodell@php.net

According to RFC 4180 Common Format and MIME Type for CSV Files:

> 7.  If double-quotes are used to enclose fields, then a double-quote
>     appearing inside a field must be escaped by preceding it with
>     another double quote.  For example:
>
>     "aaa","b""bb","ccc"

PHP does indeed support this escaping method which is common amongst most other CSV implementations:
https://3v4l.org/e0aX8

------------------------------------------------------------------------
[2014-10-24 17:08:16] desertshadow at gmail dot com

Has this bug really been open for 3 years? This is a pretty big bug, 
1) The docs are incorrect
2) The CSV parser isn't working correctly

I'm trying to escape a comma in a CSV string but it doesn't appear to be escaping
correctly.

------------------------------------------------------------------------
[2012-07-15 04:07:21] darren at dcook dot org

Yes, agree:
 1. change docs to say $escape defaults to '"'
 2. Change code to use $escape when it is something else

(NB. IIUC, this won't break backwards compatibility.)

------------------------------------------------------------------------
[2012-07-14 07:39:46] dan dot libby at gmail dot com

I just ran into this bug also.

I don't know the history, and haven't reviewed the str_getcsv() source yet but I am
guessing that *getcsv() were originally implemented with excel style double-quote escaping.  Somehow
the escape='\\' param got added to the documentation, but seemingly not the code.

Defaulting escape='\\' as the documentation says would potentially break apps depending on
escape='"'.  So that would be a breaking change, and a bad idea.

But leaving it as supporting only escape='"' is also bad, because it limits the
utility of the function.  For example, I need to parse apache logs, and apache only supports
escaping with \.   whoops.

So I believe the correct fix would be to default to escape='"' so we don't break
apps using it with defaults, but still support explicit use of escape='\\'.

agree?  disagree?

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


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


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


Thread (12 messages)

« previous php.bugs (#210297) next »