PHP 5.4 exception exception – Impossible de voir le message avec le message de chaîne codé ISO-8859-1

J’ai récemment installé PHP 5.4 sur mon Ubuntu 12.10 depuis apt-get.

Les informations PHP montrent: PHP Version 5.4.6-1ubuntu1

Je viens d’installer tous les paquets communs, comme mysql, pgsql, curl, etc., n’a pas fait d’autres changements mais j’ai un problème.

J’aime utiliser l’encodage ISO-8859-1 / latin1 dans mes fichiers et bases de données, car c’est là que j’ai le meilleur workflow. Maintenant, cela me pose un problème car PHP ne semble pas s’accorder avec les exceptions dont les messages ont été encodés de cette manière.

Eh bien, juste pour clarifier cela, j’ai créé un fichier de test comme celui-ci:

ini_set('display_errors', 1); error_reporting(E_ALL); throw new Exception('é'); 

Si le code ci-dessus est dans un fichier utf-8, tout va bien, avec Xdegub activé, j’obtiens:

 ( ! ) Fatal error: Uncaught exception 'Exception' with message 'é' in /home/henrique/public/teste.php on line 5 ( ! ) Exception: é in /home/henrique/public/teste.php on line 5 Call Stack # Time Memory Function Location 1 0.0002 124212 {main}( ) ../teste.php:0 

Si le fichier est dans ISO-8859-1, si Xdebug est activé, le problème est que le message ne s’affiche pas:

 ( ! ) Fatal error: in /home/henrique/public/teste.php on line 5 ( ! ) Exception: in /home/henrique/public/teste.php on line 5 Call Stack # Time Memory Function Location 1 0.0002 124436 {main}( ) ../teste.php:0 

Cependant, sans Xdebug, tout ce que j’obtiens est ce message “très clarifiant”:

 Fatal error: in /home/henrique/public/teste.php on line 5 

Peut-être que c’est un problème dans Apache, parce que quand j’essaie la même chose en utilisant la ligne de commande, j’obtiens:

 Stack trace: #0 {main} thrown in /home/henrique/public/teste.php on line 5 Fatal error: Uncaught exception 'Exception' with message ' ' in /home/henrique/public/teste.php on line 5 Exception:   in /home/henrique/public/teste.php on line 5 Call Stack: 0.0002 121256 1. {main}() /home/henrique/public/teste.php:0 

Le message est toujours là, cependant, il est illisible, mais est là …

modifier

J’ai également essayé avec Lighttpd 1.4.28 et les résultats étaient les mêmes.

Edit 2:

Essayé avec le serveur intégré PHP 5.4 et obtenu ceci sur mon terminal:

 [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 

Mais dans le navigateur, toujours le même problème.

Le message d’exception dans PHP est une chaîne , comme aucune nouvelle pour vous.

Les chaînes en PHP sont binarys. Cela signifie que PHP ne se soucie pas de l’encodage, les chaînes en PHP conservent tout codage pouvant être exprimé avec des données binarys en octets (c’est-à-dire que 8 bits forment un seul octet, qui est alors un caractère dans une chaîne PHP) si vous utilisez un access de sous-chaîne comme $ssortingng[10] pour accéder au 11ème caractère ).

Comme toutes ces choses garantissent cependant que vous écrivez le message, cependant, il sera transmis dans la sortie.

La seule différence réside dans la manière dont vous affichez la sortie. Disons que vous avez le codage Latin-1 dans cette chaîne de message d’exception et que vous le sortez via votre serveur Apache, puis vous l’affichez dans votre navigateur et votre navigateur (nous ne nous préoccupons pas de la raison jusqu’ici) l’affiche comme UTF-8, vous verrez cette question-marque-diagmond / crystal: .

La même chose s’applique au terminal si le terminal l’affiche comme UTF-8.

Ou si vous enregistrez la sortie dans un fichier et que vous ouvrez ce fichier dans votre éditeur comme étant codé en UTF-8.

Alors, comment résoudre ce problème? Pour votre navigateur, veuillez vous reporter à la documentation de votre navigateur pour savoir comment vous pouvez indiquer à votre navigateur dans quel encodage le site Web que vous consultez actuellement. Chaque navigateur que je connais possède une sorte de menu où vous pouvez le spécifier. Le jeu de caractères que vous utilisez est commmon, donc même les navigateurs les plus anciens ont cela.

Même chose pour le terminal. Vous pouvez définir les parameters régionaux du shell ainsi que l’encodage du terminal. Consultez la documentation du shell que vous utilisez.

Pour le fichier texte, je parie que vous savez déjà comment y faire face: consultez les options proposées par votre éditeur.


Une dernière remarque: si vous souhaitez parsingr correctement le retour de votre serveur à une demande contenant la sortie du message d’exception, vous devez utiliser les outils de développement de votre navigateur pour rendre visibles les en-têtes de réponse du serveur. Vous verrez probablement une modification de votre configuration précédente (en erreur) indiquant que le contenu est codé en UTF-8 alors que le codage est latin-1. Corrigez cette erreur si vous ne souhaitez pas modifier manuellement l’encodage dans le navigateur. Pour ce faire, consultez la documentation PHP et la documentation de votre serveur Web.

[email protected] a proposé une explication:

https://bugs.php.net/bug.php?id=63426&edit=2

La raison pour laquelle il ne peut pas être fixé est complexe est simple. Depuis la version 5.4, l’encodage interne de PHP est UTF-8, où il était auparavant latin1. Tout le rest n’a presque pas de changement.

Chaque message d’erreur à afficher dans le contexte HTML doit avoir les entités converties. Pour cela, la même fonctionnalité que dans htmlspecialchars () est utilisée. Où avant PHP 5.4 il était obligé d’utiliser latin1, maintenant il est obligé d’utiliser UTF8. Il y en a par conception. L’utilisation de header () avec content-type ou default_charset n’affecte que le transfert de l’en-tête de type de contenu.

Ainsi, vous utilisez le texte d’erreur dans latin1, mais UTF-8 sera utilisé pour convertir des entités, et cela mourra au premier caractère non valide. L’emplacement approprié dans le code: http://lxr.php.net/xref/PHP_5_4/main/main.c#1083 , puis Determ_charset () fournira UTF8 pour le jeu de caractères de conversion. C’est la raison pour laquelle votre accent est avalé. Et c’est la raison pour laquelle Hui n’a pas pu reproduire ceci – si vous regardez son post plus tôt, en effet, latin1 est envoyé dans content-type, mais évidemment un script PHP encodé en UTF-8, donc le message d’erreur est “Erreur fatale: Uncaught exception ‘Exception’ avec le message ‘Ã ©’ in … “. La condition actuelle ne vous oblige cependant pas à avoir des scripts en UTF-8, dans votre script encodé en latin, vous pouvez toujours lancer l’exception en utilisant utf8_encode (‘é’). La raison pour laquelle il fonctionne avec l’interface de ligne de commande est qu’aucune entité HTML ne doit être codée, de sorte que les caractères sont transmis tels quels à la sortie.

Tout cela signifie que ce problème était toujours présent, mais il était en faveur des utilisateurs par défaut iso-8859-1. Désormais, les utilisateurs avec UTF-8 par défaut en profitent. L’examen des codes pour résoudre ce problème peut nécessiter une intrusion globale plus importante que celle requirejse par ce ticket.

Pour le comportement de htmlspecialchars (), voir aussi le bogue # 61354

Avez-vous essayé cela sur un serveur différent?

Je pense que c’est votre configuration, j’ai créé un fichier de test sur mon serveur, vous pouvez le voir ici http://cai.tlacaelelrl.com/tests/test.php

le contenu est

  ini_set('display_errors', 1); error_reporting(E_ALL); print 'Character encoding is: '.mb_internal_encoding(); throw new Exception('é'); 

Le jeu de caractères est appliqué au fichier, j’ai également ajouté le jeu de caractères au fichier htaccess.

Je ne suis pas sûr que ce soit à cause de xdebug mais je ne pouvais pas faire de test avec cette option.

Pouvez-vous essayer d’append ceci

  AddCharset ISO-8859-1 .php 

Vers votre fichier .htaccess

J’ai le même problème et je n’ai pas trouvé de bonne solution (“AddCharset ISO-8859-1 .php” dans .htaccess ne fonctionne pas). Vous pouvez utiliser ceci:

lancer une nouvelle exception (htmlentities (‘é’, ENT_COMPAT, ‘ISO-8859-1’));

Mais Xdebug montrera:

&une tombe ;

C’est mieux que rien