Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100758
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.48 cause and error)
MIME-Version: 1.0
In-Reply-To: <2e92a618-c053-0434-bbf4-511892d41758@gmx.de>
References: <7cf5adb8-0738-259e-6d1e-f966722fdae2@gmx.de> <CAH0Uv3FOj_N=XGY+CKiWgp8qqLMFG4fEh-q44t8s5FejOjc3Aw@mail.gmail.com>
 <C2703892-C0AA-4C9B-ACED-6C343D202887@gmail.com> <2e92a618-c053-0434-bbf4-511892d41758@gmx.de>
Date: Fri, 22 Sep 2017 20:39:18 +0200
Message-ID: <CAH0Uv3G7rt31kgvhkcLOa9gr=BgpR54sZDDs5MK5nAfE=NxaTw@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] fputcsv() and $escape character
From: andreas@dqxtech.net (Andreas Hennings)

On Fri, Sep 22, 2017 at 1:20 PM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
>> 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 other problem that this proposal wants to fix is that CSV cannot
currently be used reliably to store or transport data between
different PHP scripts, due to this bug:
https://bugs.php.net/bug.php?id=74713&edit=2

> If one cell of the data sent to fputcsv() contains "{$enclosure}{$escape_char}{$escape_char}{$enclosure}{$delimiter}", this cell will be split after a round trip of fputcsv() + fgetcsv().


>
> 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).

I have opened a lot of php-generated CSV files with LibreOffice Calc,
and the line endings have not been a problem.
I assume Excel and OpenOffice would also be ok with it.
I'd say stick with existing behavior for BC reasons, or discuss it separately.