« DéniQu'a donc fumé Benoît XVI ? »

php m'a tuer

31.03.12 | par Le Grincheux | Catégories: Mauvaise humeur, Je hais l'informatique

Vous avez dû remarquer que j'étais silencieux depuis quelques jours. Bien malgré moi, j'étais simplement en train d'essayer de contourner les aberrations de php qui fonctionne derrière ce site. Je savais déjà que php était une bouse innommable mais je ne pensais tout de même pas que cela l'était à ce point, partant du principe certainement idiot qu'à l'imposible, nul n'est réellement tenu.

php 6 a été abandonné. Je pensais naïvement qu'en voilà une bonne nouvelle. Ma joie n'a été que de courte durée puisque php 6 a été remplacé par une version numérotée 5.4. Or la 5.3 que j'utilisais jusqu'à présent avec succès affichait un certain nombre de failles de sécurité qu'il me fallait boucher au plus vite. De 5.3 à 5.4, on pouvait s'attendre à une révision mineure. Raté, des tas de choses ne fonctionnent plus de la même façon et il m'a fallu contourner un bon nombre de nouvelles fonctionnalités tout à fait originales dont on se demande s'il ne s'agit pas tout simplement de gros bogues.

Depuis que je suis contraint à maintenir des serveurs embarquant php, c'est-à-dire depuis une dizaine d'années, j'ai toujours eu l'impression que l'équipe de développement de ce sale truc naviguait à vue. Passer d'une version à une autre, même entre deux versions mineures consécutives, est un parcours du combattant. Mais cette fois-ci, je dois leur tirer mon chapeau, ces développeurs se sont réellement surpassés !

Outre les habituels messages d'erreurs, d'information et de tout ce que vous pouvez imaginer sur la sortie standard — donc entre autres sur les pages publiques — apparaissant on ne sait pourquoi avec la nouvelle version de php et impliquant une revue complète du code des applications, cette fois-ci, nous avons essuyé les plâtres d'une subtile refonte du mécanisme d'encodage des caractères non strictement ASCII. L'encodage interne utilisé par php de ces caractères ne suit plus l'ordre immuable utilisé jusque-là.

Vous allez me dire que ce n'est pas votre problème. Pourtant, si, car notre belle langue comporte un certain nombre de caractères non strictement ASCII (tous les caractères contenant des diacritiques). php, dans sa grande bonté convertit maintenant les caractères en entrée en format connu et spécifié dans son fichier de configuration. Mais il ne convertit pas sa sortie, ou il oublie de le faire, ce qui revient au même ! En d'autres termes, les caractères entrés lorsque j'écris un papier ou que vous écrivez un commentaire qui étaient en ISO-8859-1 (ancien encodage de php) étaient convertis en UTF-8 pour le fonctionnement interne de php, mais ce même php oubliait de les reconvertir en ISO-8859-1 lorsqu'il les envoyait au serveur apache ou WASD. D'où des textes impossibles à corriger, des boutons qui perdaient leurs labels et j'en passe.

Je viens de terminer ce soir ma revue de code. Tous les problèmes que j'ai pu voir semblent corrigés. Merci de me faire savoir s'il reste d'autres dysfonctionnements.

 

5 commentaires

Commentaire de: ®om
®om

Pourquoi n’y avait-il pas de l’UTF-8 sur toute la chaîne ? Ça évite les problèmes ;-)

31.03.12 @ 22:56
Commentaire de: Le Grincheux

Pour la simple raison qu’avant php 5.4, la localisation interne au langage était ISO-8859 quelque chose et non UTF-8. Heureusement que la base de données derrière était déjà en UTF-8 !

Il n’empêche que pour un langage aussi utilisé, cela fait un peu tache de décréter du jour au lendemain que l’encodage interne va changer sans s’assurer des mécanismes de contournement des bogues introduits par ce changement.

01.04.12 @ 10:05
Commentaire de: Le Grincheux

Tiens, ça me rappelle avoir écrit un jour une extension au RPL/2 capable de s’interfacer à un serveur Apache au travers du mécanisme cgi. Je m’en vais voir s’il ne serait pas possible de remplacer l’immonde php par des scripts RPL/2 et RPL/C qui, eux, ont été validés par le CERT et surtout savent effectuer des translitérations sans aucun problème.

cauchy:[~/rpl/modules/cgi] > ls -l
-rw-r–r– 1 bertrand bertrand 55084 oct. 26 2009 cgic.c
-rw-r–r– 1 bertrand bertrand 7403 oct. 26 2009 cgic.h
-rw-r–r– 1 bertrand bertrand 115784 oct. 26 2009 cgic.o
-rw-r–r– 1 bertrand bertrand 10832 oct. 26 2009 cgi.o
-rw-r–r– 1 bertrand bertrand 1555 oct. 26 2009 cgi.rplc
-rw-r–r– 1 bertrand bertrand 99494 oct. 26 2009 cgi.rplso
-rw-r–r– 1 bertrand bertrand 133 oct. 26 2009 Makefile
cauchy:[~/rpl/modules/cgi] >

01.04.12 @ 15:39
Commentaire de: Bertrand
Bertrand

Je savais pas que j’étais fiché. C’est déclaré à la CNIL, tout ça ?

02.04.12 @ 09:45
Commentaire de: Henri

Ah la CNIL !
Faites attention !
http://forum.pcastuces.com/sujet.asp?f=25&s=69678
La CNIL diffuse un logiciel pour prévenir de cookies sur le site sourceforge, connu comme dangereux, et vous vous faites installer un tas de logiciels malveillants. La CNIL alertée plusieurs fois n’a toujours pas réagi.
Espérons que l’Armée française n’a pas les mêmes pratiques !

07.01.14 @ 16:14


Formulaire en cours de chargement...