Ces fonctions sont-elles utf8 compliant sous php 4+ ?

Le
Jean Francois Ortolo
Bonsoir

J'ai presque terminé de convertir mon site en mode utf8.

J'ai programmé un script contenant les équivalents des fonctions de
traitement de chaînes de caractères :


strpos() => _strpos()

strrpos() => _strrpos()

susbtr() => _substr()

ststr() => _strtr()

str_replace() => _str_replace()


Etc avec les fonctions de type mbstring, et avec une constante
ENCODING que je met comme je veux à : 'UTF-8' ou 'ISO-8859-1'.


Ma question est :

Mon ordinateur est sous php 5.4.13.

Or, bizarre d e chez bizarre, j'ai du convertir tous mes scripts,
sauf mes scripts contenant des fonctions de parsing html.

Ces fonctions utilisent toujours strpos(), str_replace() (
uniquement pour remplacer une chaîne ascii par une autre ), subtr() et
strrpos().

Par quelle magie, ces fonctions iso ,qui traitent dans mes scripts
des chaînes de caractères en utf8 , fonctionnent normalement ?

Est-il possible, que pour certaines versions de php ( 4 et plus ),
ces fonctions détectent automatiquement l'utf8, et le traitent normalement ?

Merci beaucoup de m'éclairer, car je nage dans le brouillard.

Bien amicalement.

Jean François Ortolo
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Olivier Miakinen
Le #25361132
Bonjour,

Le 24/04/2013 22:56, Jean Francois Ortolo a écrit :

[...]

Or, bizarre d e chez bizarre, j'ai du convertir tous mes scripts,
sauf mes scripts contenant des fonctions de parsing html.

Ces fonctions utilisent toujours strpos(), str_replace() (
uniquement pour remplacer une chaîne ascii par une autre ), subtr() et
strrpos().

Par quelle magie, ces fonctions iso ,qui traitent dans mes scripts
des chaînes de caractères en utf8 , fonctionnent normalement ?



Tout dépend du traitement que tu fais, il n'y a pas forcément de raison
que cela plante. Par exemple, si tu cherches "déjà" en UTF-8 dans une
chaîne UTF-8 valant "Je suis déjà passé à UTF-8", ce sera comme si tu
cherchais "déjà " en Latin1 dans "Je suis déjà passé à UTF-8", et
forcément il y est.

C'est assez logique, puisque contrairement à ce que tu sembles penser
les fonctions strpos(), str_replace() et autres ne connaissent rien à
ISO-8859-1 : elles se contentent de travailler sur des octets.

En outre, si les mots que tu cherches sont de l'ASCII 7 bits, alors ils
sont strictement identiques en UTF-8 et en ISO-8859-1, et donc tu peux
même mélanger les deux encodages dans ce cas précis.

Est-il possible, que pour certaines versions de php ( 4 et plus ),
ces fonctions détectent automatiquement l'utf8, et le traitent normalement ?



Absolument pas. Ces fonctions traitent normalement des octets non nuls
(valeurs comprises entre 1 et 255, ou entre 0x01 et 0xff) en se foutant
royalement de savoir si c'est de l'UTF-8, du Big5 ou de l'EBCDIC. Il se
pourrait même que la valeur 0 soit gérée, je ne sais plus ce que j'avais
lu dans la doc car il n'y a pas de raison de la rencontrer dans un texte
normal.

Et donc, ça ne marche pas parce que l'encodage est détecté, ça marche
parce que la plupart du temps on se contrefout de l'encodage. Bien sûr,
si tu comptes que strlen("déjà") fasse 4 et pas 6, là l'encodage est
important.


Cordialement,
--
Olivier Miakinen
Jean Francois Ortolo
Le #25361662
Le 25/04/2013 00:03, Olivier Miakinen a écrit :
Bonjour,

Tout dépend du traitement que tu fais, il n'y a pas forcément de raison
que cela plante. Par exemple, si tu cherches "déjà" en UTF-8 dans une
chaîne UTF-8 valant "Je suis déjà passé à UTF-8", ce sera comme si tu
cherchais "déjà " en Latin1 dans "Je suis déjà passé à UTF-8", et
forcément il y est.

C'est assez logique, puisque contrairement à ce que tu sembles penser
les fonctions strpos(), str_replace() et autres ne connaissent rien à
ISO-8859-1 : elles se contentent de travailler sur des octets.

En outre, si les mots que tu cherches sont de l'ASCII 7 bits, alors ils
sont strictement identiques en UTF-8 et en ISO-8859-1, et donc tu peux
même mélanger les deux encodages dans ce cas précis.

Est-il possible, que pour certaines versions de php ( 4 et plus ),
ces fonctions détectent automatiquement l'utf8, et le traitent normalement ?



Absolument pas. Ces fonctions traitent normalement des octets non nuls
(valeurs comprises entre 1 et 255, ou entre 0x01 et 0xff) en se foutant
royalement de savoir si c'est de l'UTF-8, du Big5 ou de l'EBCDIC. Il se
pourrait même que la valeur 0 soit gérée, je ne sais plus ce que j'avais
lu dans la doc car il n'y a pas de raison de la rencontrer dans un texte
normal.

Et donc, ça ne marche pas parce que l'encodage est détecté, ça marche
parce que la plupart du temps on se contrefout de l'encodage. Bien sûr,
si tu comptes que strlen("déjà") fasse 4 et pas 6, là l'encodage est
important.


Cordialement,





Bonjour Monsieur

Je vais vérifier si l'utilisation que je fais de strlen() le cas
échéant, n'a pas d'incidence sur le fonctionnement de mes scripts de
parsing html.

Je suis pratiquement sûr que j'utilise strlen() ( je l'avais vu hier
ou avant-hier ),mais il se peut que l'algorithme utilisé, ne nécessite
pas que les longueurs rendues par cette fonction, soient rigoureusement
exactes.

Je vais vérifier aussi, si j'utilise le fait de traiter des strings
comme des arrays, ( avec l'opérateur [] ).

Dans ce dernier cas, je suppose que cet opérateur, traite aussi comme
des octets des octets même en utf8 ?

Cette pratique, de traiter des strings avec cet opérateur [],
est-elle pérenne ?

C'est-à-dire, sera-t-elle interdite en php 6 ?

En ce qui concerne les motifs recherchés par strpos() et strrpos(),
et substitués par str_replace(), effectivement c'est toujours de l'ascii
pur( genre "<", ">", ou "/", ou bien une chaîne purement du type [a-z]+ ).

Merci beaucoup beaucoup de votre aide.

Très respectueusement.

Jean François Ortolo
Otomatic
Le #25361652
Jean Francois Ortolo écrivait :

C'est-à-dire, sera-t-elle interdite en php 6 ?


Bonjour,

Nulle part, sur http://php.net/ je ne vois une quelconque référence à
PHP 6.
Il existe PHP 5.5 beta3, mais que dalle, nada, rien au sujet de PHP 6.
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort
qu'ils ont forcément raison. Coluche
Jean Francois Ortolo
Le #25362072
Le 25/04/2013 10:37, Otomatic a écrit :
Jean Francois Ortolo écrivait :

C'est-à-dire, sera-t-elle interdite en php 6 ?


Bonjour,

Nulle part, sur http://php.net/ je ne vois une quelconque référence à
PHP 6.
Il existe PHP 5.5 beta3, mais que dalle, nada, rien au sujet de PHP 6.





Bonjour Monsieur

L'impossible n'existe pas.

Bien amicalement.

Jean François Ortolo
Jean Francois Ortolo
Le #25362372
Bonjour Monsieur

J'utilise effectivement strlen() avec l'opérateur [] sur des strings,
pour parser des strings en utf8, jusqu'à rencontrer le caractère "<" ou
">", qui ont même code sous iso et utf8.

Egalement, je l'utilise en lecture pour détecter le caractère / après
le caractère < ( balise fermante ).

D'autre part, je n'utilise cet opérateur (] sur des strings qu'en
lecture, pas en écriture.

L'ensemble des opérations de toutes mes fonctions de parsing se
faisant sur des octets, il semble logique que la fonction strlen() ne
pose pas de problème, puisqu'elle opère sur des octets.

Le seul problème éventuel qui aurait pu se produire, aurait été que
les code ascii ( ou utf8 identiques ), des caractères < ou > ou /,
puissent apparaître dans des chaînes en utf8, en dehors de l'existence
de ces caractères spécifiques.

Maintenant le seul problème, est de savoir si toutes ces fonctions
substr(), strlen(), strpos(), strrpos(), str_replace(), strstr(),
strtoupper() et strtolower(), ainsi que l'usage de l'opérateur indice []
pour les strings, seront encore valables sous php6, ( ou pour php >
5.9.99, pour satisfaire les puristes. )

Merci beaucoup de me le confirmer.

Bien respectueusement.

Jean François Ortolo
Jean Francois Ortolo
Le #25363652
Rebonjour

En fait j'ai intérêt à convertir aussi mes fonctions de parsing html
en utf8.

Comme l'opérateur indice [] prend en compte les octets, cette
migration ne sera possible, que si je remplace ces accès indicés par
l'utilisation de la fonction adaptée à utf8 : _substr($str, $n, 1), où
$n sera l'indice de la string $str.

Je vais faire çà, c'est pas la mer à boire, au moins je serai
indépendant de cet opérateur [], et j'espère que les autres fonctions, (
str*() , substr(), strtolower(), strtoupper() ), resteront sur les
versions future de php.

Bien amicalement.

Jean François Ortolo
Jean Francois Ortolo
Le #25366172
Le 25/04/2013 21:36, Jean Francois Ortolo a écrit :


Rebonjour

En fait j'ai intérêt à convertir aussi mes fonctions de parsing html
en utf8.

Comme l'opérateur indice [] prend en compte les octets, cette
migration ne sera possible, que si je remplace ces accès indicés par
l'utilisation de la fonction adaptée à utf8 : _substr($str, $n, 1), où
$n sera l'indice de la string $str.

Je vais faire çà, c'est pas la mer à boire, au moins je serai
indépendant de cet opérateur [], et j'espère que les autres fonctions, (
str*() , substr(), strtolower(), strtoupper() ), resteront sur les
versions future de php.

Bien amicalement.

Jean François Ortolo







Voilà c'est fait.

Cà marche.

Je sais maintenant qu'il faut que je me passe de l'opérateur [] pour
accéder aux chaînes de caractères.

Pour que mon site entier soit en utf8, je n'ai plus qu'à convertir le
répertoire /php/paiement/ , qui contient quelques scripts préparés pour
les paiements par Allopass ( mon site est gratuit, je peux toujours voir
venir... ;( ), plus quelques babioles utilisées par mon site.

Schtroumpf !

Bien amicalement.

Jean François Ortolo
Jean Francois Ortolo
Le #25369962
Le 25/04/2013 21:36, Jean Francois Ortolo a écrit :


Rebonjour

En fait j'ai intérêt à convertir aussi mes fonctions de parsing html
en utf8.

Comme l'opérateur indice [] prend en compte les octets, cette
migration ne sera possible, que si je remplace ces accès indicés par
l'utilisation de la fonction adaptée à utf8 : _substr($str, $n, 1), où
$n sera l'indice de la string $str.

Je vais faire çà, c'est pas la mer à boire, au moins je serai
indépendant de cet opérateur [], et j'espère que les autres fonctions, (
str*() , substr(), strtolower(), strtoupper() ), resteront sur les
versions future de php.

Bien amicalement.

Jean François Ortolo







Rebonjour

Voilà, j'ai tout fait sur mon ordi en local.

Je migre mon site entier en moins d'un quart d'heure demain lundi
soir vers 20h.

La check-list de migration est fixée.

Je convertirai d'abord la database, vérifierai si la conversion vers
utf8 s'est bien passée ( 45 secondes sur mon ordi ).

Sinon, je remettrai la database à l'état initial.

Si oui, copie de tous les scripts php utf8 à leurs emplacements, puis
redémarrage de Apache2.

Accessoirement, modification d'un seul script lancé par cron, le
script de sauvegarde pour le site et la database ( mode utf8 et non plus
latin1 ).

Eventuellement, changement du charset par défaut de la database.

C'est tout.

Cà roule.

Je serai obligé de couper l'accès à mon site ( serveur web Apache2
down ), pendant quelques minutes.

J'ai un VPS chez OVH. ;)

On va voir...

Bien amicalement.

Jean François Ortolo
Jean Francois Ortolo
Le #25374042
Le 28/04/2013 10:32, Jean Francois Ortolo a écrit :
Le 25/04/2013 21:36, Jean Francois Ortolo a écrit :

Rebonjour

Voilà, j'ai tout fait sur mon ordi en local.

Je migre mon site entier en moins d'un quart d'heure demain lundi
soir vers 20h.

La check-list de migration est fixée.

Je convertirai d'abord la database, vérifierai si la conversion vers
utf8 s'est bien passée ( 45 secondes sur mon ordi ).

Sinon, je remettrai la database à l'état initial.

Si oui, copie de tous les scripts php utf8 à leurs emplacements, puis
redémarrage de Apache2.

Accessoirement, modification d'un seul script lancé par cron, le
script de sauvegarde pour le site et la database ( mode utf8 et non plus
latin1 ).

Eventuellement, changement du charset par défaut de la database.

C'est tout.

Cà roule.

Je serai obligé de couper l'accès à mon site ( serveur web Apache2
down ), pendant quelques minutes.

J'ai un VPS chez OVH. ;)

On va voir...

Bien amicalement.

Jean François Ortolo







Rebonjour

Voilà c'est fait.

Migration vers utf8 réussie.

J'ai eu peur.

Comme disait Pinte dan s "Le Roman de Renard" : "Et nous avons eu
peur !" ;)

Voir le site : www.pronostics-courses.fr

Bien amicalement.

Jean François Ortolo
Olivier Miakinen
Le #25384062
Le 25/04/2013 14:17, Jean Francois Ortolo a écrit :

Bonjour Monsieur



Bonjour jeune homme,

[...]

Le seul problème éventuel qui aurait pu se produire, aurait été que
les code ascii ( ou utf8 identiques ), des caractères < ou > ou /,
puissent apparaître dans des chaînes en utf8, en dehors de l'existence
de ces caractères spécifiques.



Sois rassuré, ceci est absolument impossible. Tu peux pointer
n'importe où au hasard dans un texte en UTF-8, même en plein milieu
d'une séquence, en étant assuré de ne pas prendre un caractère pour
un autre. En particulier, une valeur comprise entre 0 et 127 (ce qui
inclut donc la totalité d'US-ASCII) ne peut jamais se trouver dans
un caractère UTF-8 non-ASCII.

Cordialement,
--
Olivier Miakinen
Publicité
Poster une réponse
Anonyme