Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Ces fonctions sont-elles utf8 compliant sous php 4+ ?
11 views
Skip to first unread message
Jean Francois Ortolo
Apr 24, 2013, 4:56:41 PM4/24/13
to
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
Olivier Miakinen
Apr 24, 2013, 6:03:56 PM4/24/13
to
Bonjour,
Le 24/04/2013 22:56, Jean Francois Ortolo a écrit :
>
> [...]
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
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
> 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() (
> strrpos().
>
> Par quelle magie, ces fonctions iso ,qui traitent dans mes scripts
> des chaînes de caractères en utf8 , fonctionnent normalement ?
>
> Par quelle magie, ces fonctions iso ,qui traitent dans mes scripts
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 ),
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
Apr 25, 2013, 4:32:34 AM4/25/13
to
Le 25/04/2013 00:03, Olivier Miakinen a écrit :
> Bonjour,
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
> 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
> 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,
>
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
Apr 25, 2013, 4:37:38 AM4/25/13
to
Jean Francois Ortolo <ortolo.jeanfr...@free.fr.invalid>
é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
écrivait :
> C'est-à-dire, sera-t-elle interdite en php 6 ?
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
Apr 25, 2013, 7:02:55 AM4/25/13
to
Le 25/04/2013 10:37, Otomatic a écrit :
> Jean Francois Ortolo <ortolo.jeanfr...@free.fr.invalid>
> é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
> Jean Francois Ortolo <ortolo.jeanfr...@free.fr.invalid>
> é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.
>
L'impossible n'existe pas.
Bien amicalement.
Jean François Ortolo
Jean Francois Ortolo
Apr 25, 2013, 8:17:18 AM4/25/13
to
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
Apr 25, 2013, 3:36:21 PM4/25/13
to
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.
Jean Francois Ortolo
Apr 26, 2013, 2:24:04 PM4/26/13
to
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 !
Jean Francois Ortolo
Apr 28, 2013, 4:32:35 AM4/28/13
to
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...
Jean Francois Ortolo
Apr 30, 2013, 6:30:44 AM4/30/13
to
Le 28/04/2013 10:32, Jean Francois Ortolo a écrit :
> Le 25/04/2013 21:36, Jean Francois Ortolo a écrit :
>
> Rebonjour
>
> 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
>
> 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
>
>
>
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
Olivier Miakinen
May 4, 2013, 5:31:11 PM5/4/13
to
Le 25/04/2013 14:17, Jean Francois Ortolo a écrit :
>
> Bonjour Monsieur
Bonjour jeune homme,
> [...]
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
>
> 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
> 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.
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
0 new messages