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
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 ?
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.
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.
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]+ ).
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]+ ).
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
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 <ortolo.jeanfrancois_nospam@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
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 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
Le 25/04/2013 10:37, Otomatic a écrit :
Jean Francois Ortolo <ortolo.jeanfrancois_nospam@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.
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
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
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. )
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
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
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.
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 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
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.
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 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
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.
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 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
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 !" ;)
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 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
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.
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.
