j'ai fait une sorte de résumé de la question charset sous forme d'article
soumis à la discussion dans uZine.net, on verra comment ça évolue, mais
j'aimerais avoir l'avis et les corrections/ajouts/suggestions de tous les
gens que ça intéresse.
Fil wrote:
> j'ai fait une sorte de résumé de la question charset sous forme d'article
> soumis à la discussion dans uZine.net, on verra comment ça évolue, mais
> j'aimerais avoir l'avis et les corrections/ajouts/suggestions de tous les
> gens que ça intéresse.
>
> http://www.uzine.net/ecrire/articles.php3?id_article=1785
Merci Fil.
Ton article est vraiment limpide pour les néophytes des charsets.
(ça éclaire ma lanterne sur les récentes discussions)
a+
Fabrice
Ps
1.
quelques IMAGES pour montrer le rendu serait agréable
Il y a des navigateurs corrects aujourd'hui sur le marché : Mozilla,
Chimera, Omniweb, certaines version récentes d'Internet Explorer, etc.
Si vous n'avez pas déchiffré ci-dessus quelque chose qui évoque ILIADOZA
ou LIATCH, il est temps d'aller télécharger quelque chose de plus
moderne, ou d'abandonner toute idée de faire un site en idéogrammes
japonais... à propos, lisez-vous le passage ci-dessous ?
???
(C'est du copier-coller depuis le web, on n'abordera pas ici la question
de savoir comment entrer ces caractères au clavier.)
//////////// ////////////
Que fallait-il lire ?
J'ai essayé de poster un message en coréen sur le forum d'uZine.
(j'ai juste cliqué sur le bouton "voir ce message avant de le poster").
ça semble marcher correctement.
Pour ceux qui n'ont pas de problèmes avec les mels, ce texte est en fin de
ce mel.
Pour info, on a bossé sur le sujet de l'unicode au boulot (on a des clients
Coréens).
En fait avec un navigateur, on peut mettre des messages unicode dans un
formulaire, le stocker dans la base (ici MySQL) puis le réafficher.
ça ne pose pas de problèmes à MySQL. Le seul "truc", c'est que MySQL risque
de faire des tri alphabétiques foireux car il sera paramétré avec un charset
différent de celui utilisé avec le navigateur.
En clair, il faut vérifier que l'on peut effectivement mettre des messages
dans des langues ésotériques, mais aussi que les tris s'effectuent
correctement.
Que se passe-t-il si on demande à MySQL de mettre les chaînes en majuscules
par exemple, ou de les tronquer ? (le problème ne se pose pas si SPIP fait
tout le travail lui-même ?)
ça ne pose pas de problèmes à MySQL. Le seul "truc", c'est que MySQL risque
de faire des tri alphabétiques foireux car il sera paramétré avec un charset
différent de celui utilisé avec le navigateur.
Pour SPIP, c'est un problème accessoire. Après tout, si tout ce qui foire
est le tri par ordre alphabétique, c'est presque parfait
Les principaux obstacles (bloquants) sont :
1) Beaucoup de brouteurs ne sont pas compatibles UTF-8 et refuseront d'afficher
correctement les pages HTML écrites en unicode (y compris les bêtes accents
français). Il faudrait avoir des statistiques plus précises à ce sujet (je
n'ai pas réussi à en trouver) mais c'est un blocage majeur.
2) PHP n'est pas en l'état "compatible" UTF-8, en tout cas plein de fonctions
ne le sont pas. Comme on ne veut pas imposer une version ou une extension
spécifique de PHP, ça veut dire que le code de SPIP doit être écrit et vérifié
de façon à éviter ou compenser l'emploi de fonctions incompatibles Unicode.
Grosses prises de chou en perspective...
3) Il faut convertir la base de données (format actuel : par défaut iso-8859-1)
en Unicode. Comme MySQL n'a pas de fonction dédiée pour faire ça, cela signifie
qu'il faut faire une bonne grosse usine à gaz en PHP.
