Everything

php

fputcsv()

php.internals

David Sklar

22 years ago

Attached is a patch that implements fputcsv() as a complement to fgetcsv().

There are two things that still need improvement:

- It adds "\n" as a newline onto the end of each line. I think it would
be better to add a platform-specific line ending.

- It is not mbstring-aware.

Any suggestions for fixing these things (or other issues) would be
appreciated.

Thanks,
David

Andi Gutmans

22 years ago

How about using PHP_EOL?

At 12:33 PM 4/11/2004 -0400, David Sklar wrote:

David Sklar

22 years ago

Perfect, thanks. I knew there was a #define lurking around somewhere
that was \r\n, \r, or \n, as appropriate, I just didn't know what it was
called.

David

Andi Gutmans wrote:

Derick Rethans

22 years ago

On Sun, 11 Apr 2004, David Sklar wrote:

> Perfect, thanks. I knew there was a #define lurking around somewhere
> that was \r\n, \r, or \n, as appropriate, I just didn't know what it was
> called.

I don't think it's a good idea to do this as it causes different output
on different systems. This means that writing test casesis harder, and
that users will have to take care of those issues themselves (if they
don't use fgetcsv() to read the data in of course).

I'd say we should stick to \r\n like Ilia proposed.

Derick

David Sklar

22 years ago

Thanks for the line-ending feedback everyone, and Ilia for the code
cleanup. Attached is a diff that implements the (cleaned up) function
and a test file for tests/basic.

If someone with appropriate karma could commit these, that'd be great.

Thanks,

David

Ilia A.

22 years ago

Hi David,

I've made a slight revision to your proposed patch with adds the following
changes:

1) Raise notice when delimeter or enclosure are >1 character long.
2) Fixed a crash with custom delimeters & enclosures.
3) Made fields with spaces and tabs be enclosed.
4) Simplify the code & made it abide by PHP's CS.

As far as the line terminators, I think your initial usage of '\n' is the best
approach. Most applications capable of reading csv files will support \n
without further input from the user regardless of the system's EOL. Although,
\r\n is equally well supported, the only one which is not terribly well
supported is \r especially on some Win32 applications. Since the idea would
be to generate a universally usable csv file, \n seems (to me) like the best
choice.

Ilia

On April 11, 2004 12:33 pm, David Sklar wrote:

Moriyoshi Koizumi

22 years ago

On 2004/04/12, at 1:33, David Sklar wrote:

> Attached is a patch that implements fputcsv() as a complement to
> fgetcsv().
>
> There are two things that still need improvement:
>
> - It adds "\n" as a newline onto the end of each line. I think it
> would be better to add a platform-specific line ending.
>
> - It is not mbstring-aware.

As for writing stuff, we don't have to care about in which encoding
strings
are encoded as long as it is 8-bit compatible. UTF-16 / UTF-32 / UCS-2 /
UCS-4 are not 8-bit compatible and I've never seen a case where one of
these is utilised for CSV files, so I think your code is actually
"multibyte safe" :)

Moriyoshi