#25004 [Bgs->Opn]: Uploaded file name truncated if accent present
ID: 25004 User updated by: spud at nothingness dot org Reported By: spud at nothingness dot org -Status: Bogus +Status: Open Bug Type: *Languages/Translation Operating System: RedHat 7.2 PHP Version: 4.3.2 New Comment: Actually, the first rule of submitting a bug is "check the database first", but point taken. This problem still occurs with PHP 4.3.3RC3 on my machine, despite your results. See (http:// dev.dadaimc.org/test.php for test form and phpinfo() output) The CVS snapshot (php4-200308111530) refuses to make on my machine, generating an error near the end (see below), so I can't test the CVS version: /home/spud/src/php4-200308111530/ext/standard/ filestat.c:575: undefined reference to `php_check_open_basedir_ex' Previous Comments: [2003-08-10 11:11:55] [EMAIL PROTECTED] Works fine with latest CVS (and with PHP 4.3.3RC3 too) Bogusing since you failed the first rule of submitting a bug report: Try the latest CVS snapshot first. [2003-08-10 10:54:57] spud at nothingness dot org Description: On a standard form upload, if the user uploads a file with a name like "épice.jpg" (with an acute accent on the e), PHP reports the $_FILES[0]['name'] as "foo_e", dropping the accent and ALL following characters, including the suffix. I understand the perhaps the file upload can't handle the accented characters, but it seems incorrect to strip off the rest of the filename, including characters that are still legitimate. I don't know if this is a PHP bug or not, but it seems very limiting for non-English file uploads, where accented characters in a filename are common. Reproduce code: --- Example: with a page like upload a file named "épice.jpg", and PHP will report the filename as "e". Expected result: I expect $_FILES[0]['name'] to be "épice.jpg", or at least "epice.jpg". Actual result: -- Filename reported as "e". -- Edit this bug report at http://bugs.php.net/?id=25004&edit=1
#25004 [NEW]: Uploaded file name truncated if accent present
From: spud at nothingness dot org Operating system: RedHat 7.2 PHP version: 4.3.2 PHP Bug Type: *Languages/Translation Bug description: Uploaded file name truncated if accent present Description: On a standard form upload, if the user uploads a file with a name like "épice.jpg" (with an acute accent on the e), PHP reports the $_FILES[0]['name'] as "foo_e", dropping the accent and ALL following characters, including the suffix. I understand the perhaps the file upload can't handle the accented characters, but it seems incorrect to strip off the rest of the filename, including characters that are still legitimate. I don't know if this is a PHP bug or not, but it seems very limiting for non-English file uploads, where accented characters in a filename are common. Reproduce code: --- Example: with a page like upload a file named "épice.jpg", and PHP will report the filename as "e". Expected result: I expect $_FILES[0]['name'] to be "épice.jpg", or at least "epice.jpg". Actual result: -- Filename reported as "e". -- Edit bug report at http://bugs.php.net/?id=25004&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25004&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25004&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25004&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25004&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25004&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25004&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25004&r=support Expected behavior: http://bugs.php.net/fix.php?id=25004&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25004&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25004&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25004&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25004&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25004&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25004&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25004&r=gnused
#25004 [Opn->Bgs]: Uploaded file name truncated if accent present
ID: 25004 User updated by: spud at nothingness dot org Reported By: spud at nothingness dot org -Status: Open +Status: Bogus Bug Type: *Languages/Translation Operating System: RedHat 7.2 PHP Version: 4.3.2 New Comment: Correction: the problem persists in PHP 4.3.3RC3 with the (mac) Safari browser, but works in (mac) IE 5.2.3. Until further browser testing, I'll consider this "bogus", assuming it's a browser issue with Safari only. Previous Comments: [2003-08-11 11:27:16] spud at nothingness dot org Actually, the first rule of submitting a bug is "check the database first", but point taken. This problem still occurs with PHP 4.3.3RC3 on my machine, despite your results. See (http:// dev.dadaimc.org/test.php for test form and phpinfo() output) The CVS snapshot (php4-200308111530) refuses to make on my machine, generating an error near the end (see below), so I can't test the CVS version: /home/spud/src/php4-200308111530/ext/standard/ filestat.c:575: undefined reference to `php_check_open_basedir_ex' [2003-08-10 11:11:55] [EMAIL PROTECTED] Works fine with latest CVS (and with PHP 4.3.3RC3 too) Bogusing since you failed the first rule of submitting a bug report: Try the latest CVS snapshot first. [2003-08-10 10:54:57] spud at nothingness dot org Description: On a standard form upload, if the user uploads a file with a name like "épice.jpg" (with an acute accent on the e), PHP reports the $_FILES[0]['name'] as "foo_e", dropping the accent and ALL following characters, including the suffix. I understand the perhaps the file upload can't handle the accented characters, but it seems incorrect to strip off the rest of the filename, including characters that are still legitimate. I don't know if this is a PHP bug or not, but it seems very limiting for non-English file uploads, where accented characters in a filename are common. Reproduce code: --- Example: with a page like upload a file named "épice.jpg", and PHP will report the filename as "e". Expected result: I expect $_FILES[0]['name'] to be "épice.jpg", or at least "epice.jpg". Actual result: -- Filename reported as "e". -- Edit this bug report at http://bugs.php.net/?id=25004&edit=1
#22003 [NEW]: XML parsing and strtoupper broken in Turkish
From: [EMAIL PROTECTED]
Operating system: Linux Redhat 7.2
PHP version: 4.3.0
PHP Bug Type: *Languages/Translation
Bug description: XML parsing and strtoupper broken in Turkish
I was trying to do some XML-RPC stuff in PHP while my locale was set to
'tr_TR.utf8'. I (and others) have reported other bugs related to Turkish
and PHP because of the odd Turkish relationship with the letter "i".
While issues related to the lower-casing of object classes have been
resolved in 4.3.0, I encountered similar problems with XML parsing.
Specifically, when the locale is set to "tr_TR.utf8' and an xml parser is
created with CASE_FOLDING enabled, "INT" tags and "STRING" tags are labels
as "iNT" and "STRiNG". Consequently, functions designed to recognize tag
names based on all uppercase letters fail to recognize these tags.
The problem is also evident in the basic strtoupper function built into
PHP. The following code demonstrates both examples:
\n");
$x = "foo";
echo ("x is ".htmlspecialchars($x,ENT_COMPAT,'utf-8')."\n");
$y = strtoupper($x);
echo ("Strtoupper yields
".htmlspecialchars($y,ENT_COMPAT,'utf-8')."\n");
function startElement($parser, $name, $attrs) {
print "Start tag name: $name\n";
}
function endElement($parser, $name) {
print "End tag name: $name\n";
}
function charData($parser, $data) {
print "Character Data: $data\n";
}
$parser = xml_parser_create('utf-8');
xml_parser_set_option($parser,XML_OPTION_CASE_FOLDING,true);
xml_set_element_handler($parser, "startElement", "endElement");
xml_set_character_data_handler($parser, "charData");
echo ("Parsing with utf-8 parser, case_folding enabled\n");
xml_parse($parser,$x);
xml_parser_free($parser);
?>
--
Edit bug report at http://bugs.php.net/?id=22003&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22003&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22003&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22003&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22003&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22003&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22003&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22003&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22003&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22003&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22003&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22003&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22003&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22003&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22003&r=gnused
#18670 [Com]: strtotime() bug
ID: 18670
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Date/time related
Operating System: RedHat Linux Linux linux1 2.2.16
PHP Version: 4.2.2
Assigned To: rasmus
New Comment:
In PHP 4.2.3, the difference between "2" and "next" are still screwy in
strtotime(). I'm trying to parse icalendar recurrence formats, so I
need to calculate things like the "second Monday" in a month. Sample
code below illustrates the difference between "2" and "next" (which
should be identical).
');
echo ('Start date: Sunday, Sep 1 2002');
$first = strtotime('first Monday',$start);
echo ('"First" Monday: '.date('l, M d Y',$first).'');
$oneth = strtotime('1 Monday',$start);
echo ('"1" Monday: '.date('l, M d Y',$oneth).'');
$next = strtotime('next Monday',$start);
echo ('"Next" Monday: '.date('l, M d Y',$next).'');
$twoth = strtotime('2 Monday',$start);
echo ('"2" Monday: '.date('l, M d Y',$twoth).'');
$third = strtotime('third Monday',$start);
echo ('"Third" Monday: '.date('l, M d Y',$third).'');
$threeth = strtotime('3 Monday',$start);
echo ('"3" Monday: '.date('l, M d Y',$threeth).'');
?>
Previous Comments:
[2002-07-31 18:07:05] [EMAIL PROTECTED]
Assigning to rasmus as it sounds like he already knows whats wrong.
[2002-07-31 10:51:09] [EMAIL PROTECTED]
so can we assign this bug to you Rasmus?
[2002-07-31 10:44:11] [EMAIL PROTECTED]
Sebastian, yes, that is because I changed how "next" works based on bug
report #18655
It works correctly for days now, but it does seem like month-handling
is messed up now.
[2002-07-31 10:39:10] [EMAIL PROTECTED]
The problem is that it adds a full month to the current timestamp. So
you end up getting the 31st of the next month and some months do not
have 31 days. I'll need to do some reading to determine if strtotime()
is supposed to pick the beginning of the next month instead, or perhaps
the middle.
[2002-07-31 10:38:50] [EMAIL PROTECTED]
Strange... With PHP4.3.0-dev-20020730 on Compaq Tru64 the output is
"July October December".
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/18670
--
Edit this bug report at http://bugs.php.net/?id=18670&edit=1
