ID: 31740
Updated by: [EMAIL PROTECTED]
Reported By: arjan at avoid dot org
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Linux (Suse)
PHP Version: 5.0.3
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
"Locale setting is taken into account by this function. If LANG is e.g.
en_US.UTF-8, files in one-byte encoding are read wrong by this
function."
Previous Comments:
------------------------------------------------------------------------
[2005-01-29 23:22:22] [EMAIL PROTECTED]
Yeah, we should have some information that tells people that the locale
setting have effect on this, recategorizing...
------------------------------------------------------------------------
[2005-01-29 12:07:35] arjan at avoid dot org
The LANG environment variable on the faulty machines was set like
this:
LANG="en_US.UTF-8"
When changed to
LANG="en_US"
The problem is fixed. Thanks a lot!
However, shouldn't this behaviour be mentioned in the
manual for fgetcsv? I can imagine more people experiencing
this 'bug' that turns out to be not a bug...
Thanks again!
------------------------------------------------------------------------
[2005-01-29 03:33:57] [EMAIL PROTECTED]
What locale specifier is set to LANG or LC_CTYPE
environment variable?
------------------------------------------------------------------------
[2005-01-28 20:28:51] arjan at avoid dot org
In order to narrow the problem down as much as I can, I tried the
following script as well on the system that have problems with
fgetcsv:
<?php
$fp = fopen('csv_test.csv', 'r');
while (!feof($fp)) {
$buffer = fgets($fp, 4096);
echo $buffer;
}
fclose($fp);
?>
In this case, the umlauts do get read and printed.
------------------------------------------------------------------------
[2005-01-28 19:37:55] arjan at avoid dot org
Tested the same script on another machine (Suse 9.0), with PHP5.0.3
installed: problem does not occur here.
We have two (identically installed) machines on which this bug does
occur though.
Can anyone point us in some direction as to what might cause this
peculiar behaviour?
------------------------------------------------------------------------
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
http://bugs.php.net/31740
--
Edit this bug report at http://bugs.php.net/?id=31740&edit=1
