Edit report at https://bugs.php.net/bug.php?id=63426&edit=1
ID: 63426
Updated by: ab@php.net
Reported by: rick dot hjpbarcelos at gmail dot com
Summary: Can't throw exceptions with accentued chars coded in
latin1/ISO-8859-1
Status: Verified
Type: Bug
Package: *Unicode Issues
Operating System: Linux/Ubuntu 12.10
PHP Version: 5.4Git-2012-11-03 (snap)
Block user comment: N
Private report: N
New Comment:
The reason it's cannot be fixed is complex is simple. Since 5.4 the PHP's internal
encoding is UTF-8, where it was latin1 before. Everything else has almost no change.
Every error message to show in HTML context needs to have the entities converted. For
that the same functionality as in htmlspecialchars() is used. Where before PHP 5.4 it
was forced to use latin1, now it's forced to use UTF8. There is per design. Using
header() with content-type or default_charset affects merely only the senging of the
content-type header.
Thus, you use error text in latin1, but UTF-8 will be used to convert entities, and
that will die at the first invalid char. The relevant place in the code:
http://lxr.php.net/xref/PHP_5_4/main/main.c#1083
, subsequently determine_charset()
will deliver UTF8 for the conversion charset. That's the reason why your accent char
is swallowed. And that's the reason why Hui couldn't reproduce this - if you look at
his post earlier, indeed latin1 is sent in content-type, but obviously an UTF-8
encoded PHP script used, so the error message is
"Fatal error: Uncaught exception 'Exception' with message 'é' in
...". The current
condition however doesn't enforce you to have scripts in UTF-8, in your script
encoded in latin you still could throw the exception using utf8_encode('é'). The
reason it works with CLI is because no HTML entities have to be encoded, so the chars
are passed as is to the output.
This all actually means this issue was always there, but it was in favour of users
with default iso-8859-1. Now users with default UTF-8 do profit. Looking through the
codes to solving this might require more global intrusion than required just by this
ticket.
For htmlspecialchars() behaviour change see also bug #61354
Previous Comments:
------------------------------------------------------------------------
[2013-06-05 19:37:43] rick dot hjpbarcelos at gmail dot com
Tried with PHP 5.4 built-in server and got this on my terminal:
[code]
[Wed Jun 5 21:32:08 2013] PHP Fatal error: Uncaught exception 'Exception' with message
'�' in /var/www/test2.php:9
Stack trace:
#0 {main}
thrown in /var/www/test2.php on line 9
[Wed Jun 5 21:32:08 2013] 127.0.0.1:55116 [200]: /test2.php - Uncaught exception
'Exception' with message '�' in /var/www/test2.php:9
Stack trace:
#0 {main}
thrown in /var/www/test2.php on line 9
[/code]
But in the browser, still the same problem.
------------------------------------------------------------------------
[2013-05-30 13:30:15] rick dot hjpbarcelos at gmail dot com
Tried with lighttpd/1.4.28 and same results achieved.
------------------------------------------------------------------------
[2012-11-05 08:11:33] rick dot hjpbarcelos at gmail dot com
I'll try this in another computer with the same OS... But in mine, still the same, even after I
installed from source...
------------------------------------------------------------------------
[2012-11-05 04:11:29] laruence@php.net
Hey, still can not with apache-2.2.22 :<
Connection:Keep-Alive
Content-Length:235
Content-Type:text/html;charset=iso-8859-1
Date:Mon, 05 Nov 2012 04:08:36 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.8e-fips-rhel5 PHP/5.4.9-
dev
X-Powered-By:PHP/5.4.9-dev
Fatal error: Uncaught exception 'Exception' with message 'é' in
------------------------------------------------------------------------
[2012-11-05 03:45:15] aharvey@php.net
Fixing package (sorry, should have been in the last comment). Guessing this is SAPI related for now,
given CLI is fine, but I don't really have time to investigate further at present.
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=63426
--
Edit this bug report at https://bugs.php.net/bug.php?id=63426&edit=1