[spip-dev] utf-8 et backends

Dev
1

Attention, c'est chaud, utilisateurs avertis svp, on a besoin de tests :
dans la version CVS, un filtre est appliqué dans les backends pour que tous
les caractères émis soient au format unicode é etc...

Il faut donc passer votre site en codage utf-8 (configuration avancée) ou
iso-8859-1, taper quelques titres d'article en français accentué, en russe,
en chinois... et syndiquer le backend en question sur un autre site, ayant
le même codage ou pas. Et voir si tout colle... Bonne chance.

Si vous voulez vérifier les foncvtions elles-mêmes, elles se trouvent dans
inc_filtres, chercher autour de "iso_8859_1_to_unicode".

-- Fil

2

Il faut donc passer votre site en codage utf-8 (configuration avancée) ou

Mes essais commencent mal. Avec Mozilla, le site censé être en utf-8
n'accepte pas le caractère 'à' !!

-- Fil

3

> Il faut donc passer votre site en codage utf-8 (configuration avancée) ou
Mes essais commencent mal. Avec Mozilla, le site censé être en utf-8
n'accepte pas le caractère 'à' !!

Gasp. Que ce soit sur OS X ou Linux, SPIP a l'air d'avoir du mal avec
l'utf-8... j'ai essayé trois clients différents, j'obtiens toujours les
mêmes résultats : en tapant "déjà", le "é" est bon, le "à" est bouffé.

Mes précédents tests avaient tous été faits avec windows-1252, et je n'ai
constaté aucun problème... je ne sais pas pourquoi on a mis comme charset
proposé l'utf-8 si personne ne l'a testé :wink:

Maintenant, soit on corrige l'utf-8 (doit être faisable), soit on revient à
ce que j'avais mis comme réglage : iso-8859-1 ou "au choix".

-- Fil

4

Maintenant, soit on corrige l'utf-8 (doit être faisable)

Ah! C'est typo() qui n'est pas utf-8-clean. Le "à", par exemple, en utf8
c'est la suite des deux caractères 195-160. Or 160 est vu par typo() comme
un "blanc dur" de l'iso8859-1, et donc remplacé par un espace insécable, ce
qui explose la chaîne en question.

Le filtres corriger_caractères() doit, lui aussi, mettre la pagaille.

Sans parler de majuscules()...

Bon, ça fait beaucoup, je n'ai pas le temps de me plonger une semaine
là-dedans... ;(

-- Fil

5

Ah! C'est typo() qui n'est pas utf-8-clean. Le "à", par exemple, en utf8

...

Le filtres corriger_caractères() doit, lui aussi, mettre la pagaille.
Sans parler de majuscules()...

Bon, ça fait beaucoup, je n'ai pas le temps de me plonger une semaine
là-dedans... ;(

Il y aurait bien une solution (très crade?) : que ces fonctions
convertissent d'abord le texte en isolatin + &#xxx;, appliquent leurs
transformations, puis reconvertissent en utf-8.

-- Fil

6

Yo,

Il y aurait bien une solution (très crade?) : que ces fonctions
convertissent d'abord le texte en isolatin + &#xxx;, appliquent leurs
transformations, puis reconvertissent en utf-8.

J'ai bazardé utf-8 dans la config, ce sera plus simple comme ça...
Enfin, au vu des fonctions de conversion, j'espère que tu comprends
que cette histoire de charsets est une usine à gaz en puissance ;)))

a+

Antoine.

7

@ Fil <fil@rezo.net> :

> Ah! C'est typo() qui n'est pas utf-8-clean. Le "à", par exemple, en utf8
...
> Le filtres corriger_caractères() doit, lui aussi, mettre la pagaille.
> Sans parler de majuscules()...
>
> Bon, ça fait beaucoup, je n'ai pas le temps de me plonger une semaine
> là-dedans... ;(

Il y aurait bien une solution (très crade?) : que ces fonctions
convertissent d'abord le texte en isolatin + &#xxx;, appliquent leurs
transformations, puis reconvertissent en utf-8.

Bon, à bien y penser, les trucs crades que font ces fonctions (caractères
gênants, "blanc dur", reconnaissance de « comme étant un guillemet...) ne se
justifient QUE si le charset est iso-latin. Donc il faut qu'elles vérifient
lire_meta('charset').

Autre question ouverte : comment faire une fonction majuscules() qui
fonctionne pour les caractères isolatins, dans tous les charsets ? Ou est-ce
qu'on décide que majuscules() ne marche que si lire_meta('charset') ==
'iso-8859-1' ?

Si je réfléchis à voix haute depuis tout à l'heure, c'est parce que j'attends
des commentaires... :wink:

-- Fil

8

J'ai bazardé utf-8 dans la config, ce sera plus simple comme ça...

Plus simple, mais pas satisfaisant. Et ça ne résoud pas le problème du tout.
Si tu veux sortir une 1.5 sans config charset, vas-y, ça ne m'ennuie pas de
repousser ceci pour la version suivante (ce sera choérent avec l'i18n de
toutes façons). Mais la question reste ouverte.

Enfin, au vu des fonctions de conversion, j'espère que tu comprends
que cette histoire de charsets est une usine à gaz en puissance ;)))

Non, au contraire. Un inc_charset.php3 avec deux fonctions de conversion
vers un point central (utf-8 ou isolatin + &#nnn:wink: pour chaque charset
supporté, c'est plutôt clean. Ce qui est crade, c'est iso-latin, à cause des
windowseries et des mauvaises habitudes liées à sa longue histoire...

-- Fil

9

Autre question ouverte : comment faire une fonction majuscules() qui
fonctionne pour les caractères isolatins, dans tous les charsets ? Ou est-ce
qu'on décide que majuscules() ne marche que si lire_meta('charset') ==
'iso-8859-1' ?

Mwopf, majuscules n'a pas beaucoup d'utilité puisqu'on peut faire
la même chose avec des CSS, et que le brouteur s'y connaît mieux que
nous en jeux de caractères :
http://www.w3.org/TR/REC-CSS2/text.html#propdef-text-transform

Ce serait même marrant de reprogrammer majuscules pour faire :
<div style='text-transform: uppercase'>$texte</div>

Un avantage sympa des CSS, c'est que tu peux tester tes modifs sans
avoir à vider le cache (tant que le HTML ne change pas ;-)).

Plus simple, mais pas satisfaisant. Et ça ne résoud pas le problème du tout.
Si tu veux sortir une 1.5 sans config charset, vas-y, ça ne m'ennuie pas de
repousser ceci pour la version suivante (ce sera choérent avec l'i18n de
toutes façons). Mais la question reste ouverte.

La config charset est toujours là, c'est l'option spécifique "utf-8" qui
est enlevée puisqu'elle est trompeuse (elle donne à croire que SPIP fonctionne
avec ;-)). Mais tu peux toujours demander utf-8 comme charset "custom".

Non, au contraire. Un inc_charset.php3 avec deux fonctions de conversion
vers un point central (utf-8 ou isolatin + &#nnn:wink: pour chaque charset
supporté, c'est plutôt clean. Ce qui est crade, c'est iso-latin, à cause des
windowseries et des mauvaises habitudes liées à sa longue histoire...

Oui mais tout ça va donner un bon gros paquet de code, et de plus PHP
n'est absolument pas adapté à de la conversion caractère par caractère.

10

> Autre question ouverte : comment faire une fonction majuscules() qui
> fonctionne pour les caractères isolatins, dans tous les charsets ? Ou est-ce
> qu'on décide que majuscules() ne marche que si lire_meta('charset') ==
> 'iso-8859-1' ?

Mwopf, majuscules n'a pas beaucoup d'utilité puisqu'on peut faire
la même chose avec des CSS, et que le brouteur s'y connaît mieux que
nous en jeux de caractères :
http://www.w3.org/TR/REC-CSS2/text.html#propdef-text-transform

Ouaip, il faut le garder pour la compatibilité ascendante, mais je pense
qu'on peut le...

Ce serait même marrant de reprogrammer majuscules pour faire :
<div style='text-transform: uppercase'>$texte</div>

dans les autres charsets au moins.

Un avantage sympa des CSS, c'est que tu peux tester tes modifs sans
avoir à vider le cache (tant que le HTML ne change pas ;-)).

Il faut reloader le CSS, je n'y arrive jamais !

La config charset est toujours là, c'est l'option spécifique "utf-8" qui
est enlevée puisqu'elle est trompeuse (elle donne à croire que SPIP
fonctionne avec ;-)).

OK

Mais tu peux toujours demander utf-8 comme charset "custom".

Bin, euh, non, puisqu'alors spip va te bouffer des caractères. Tout ça ne
supprime pas le problème, donc.

> Non, au contraire. Un inc_charset.php3 avec deux fonctions de conversion
> vers un point central (utf-8 ou isolatin + &#nnn:wink: pour chaque charset
> supporté, c'est plutôt clean. Ce qui est crade, c'est iso-latin, à cause des
> windowseries et des mauvaises habitudes liées à sa longue histoire...

Oui mais tout ça va donner un bon gros paquet de code, et de plus PHP
n'est absolument pas adapté à de la conversion caractère par caractère.

De la conversion, il n'y en aura pas souvent : sur les syndications,
essentiellement. Car pour ce qui est de rendre plus propres les fonctions
citées (typo et corriger_caractères) il suffit de n'y appliquer le truc
crade que si lire_meta('charset') == 'iso-8859-1'. (Et non pas suivre ma
proposition intiale d'une double conversion). Ca te paraît bon ?

-- Fil

11

> Un avantage sympa des CSS, c'est que tu peux tester tes modifs sans
> avoir à vider le cache (tant que le HTML ne change pas ;-)).

Il faut reloader le CSS, je n'y arrive jamais !

Sous Mozilla, le bouton recharger fait l'affaire.

De la conversion, il n'y en aura pas souvent : sur les syndications,
essentiellement. Car pour ce qui est de rendre plus propres les fonctions
citées (typo et corriger_caractères) il suffit de n'y appliquer le truc
crade que si lire_meta('charset') == 'iso-8859-1'. (Et non pas suivre ma
proposition intiale d'une double conversion). Ca te paraît bon ?

Oui.