Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100750
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
References: <7cf5adb8-0738-259e-6d1e-f966722fdae2@gmx.de>
 <CAH0Uv3FOj_N=XGY+CKiWgp8qqLMFG4fEh-q44t8s5FejOjc3Aw@mail.gmail.com>
 <C2703892-C0AA-4C9B-ACED-6C343D202887@gmail.com>
Message-ID: <2e92a618-c053-0434-bbf4-511892d41758@gmx.de>
Date: Fri, 22 Sep 2017 13:20:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <C2703892-C0AA-4C9B-ACED-6C343D202887@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] fputcsv() and $escape character
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 21.09.2017 at 20:01, Rowan Collins wrote:

> On 21 September 2017 18:32:57 BST, Andreas Hennings <andreas@dqxtech.net> wrote:
>
>> So empty string would enable the standard behavior RFC 7111 with no
>> escape char.
>> If so, I support this.
> 
> Just a note regarding standards: 

Actually, there is no accepted standard regarding CSV.  RFC 7111 is just
an update to RFC 4180 (sorry, I've messed that up), but anyway both are
just informational.

> please make sure the behaviour of common applications, most notably
> Excel, is considered and tested. In my experience it has its own quirks,
> and it's likely that a large proportion of users require
> interoperability with it. It may be there's nothing relevant to
> consider, but I thought I'd mention it, in case people get too caught up
> with a specification that nobody actually follows.

That's exactly the point of this proposal.  As it is, fputcsv() outputs
CSV that won't be understood by Excel (or any other CSV aware
implementation I'm aware of), as soon as the escape character is
actually part of any string.  So being able to avoid any such escaping
would be helpful wrt. major CSV implementations, and making that the
default even more so.

The only other issue that I can see is that currently our fputcsv()
hard-codes the line endings to LF (while RFC 4180 demands CRLF), but
that may not be a real problem anymore.  (Well, there might be issues
with non ASCII compatible character encodings as well).

-- 
Christoph M. Becker