Encodage des caractères sur le forum

aleph · Le 12/03/2008, à 10:38

> Le pb n'est pas si inextricable smile Si tu as un melange de é et de bidules chelous, ca veut dire que tu as des trucs encodés et en iso, et en utf8 - les 2 étant valides en utf8.

Hélas, non. C'est l'éternelle confusion en Unicode et codage des caractères Unicode.

aleph · Le 12/03/2008, à 10:45

Erratum

Lire ... entre Unicode et codage des caractères Unicode.

®om · Le 12/03/2008, à 11:09

Faudrait juste parcourir les posts 1 par 1 avant la date du plantage dans la base de données, et faire un iconv dessus, et les updater dans la base... ça n'est pas sorcier de faire un programme qui fait ça... mais ça tarde trop, du coup certains ont déjà réécrit d'anciens posts, donc la conversion les casserait.

Dernière modification par ®om (Le 12/03/2008, à 11:09)

Yann · Le 12/03/2008, à 11:38

salut rom, le forum est un punbb.
"Yaka", fait le, on le relira et le lancera, et tant pis si 2-3 posts merdent si ca corrigent les 1.5M autres

®om · Le 12/03/2008, à 11:41

Yann a écrit :

salut rom, le forum est un punbb.
"Yaka", fait le, on le relira et le lancera, et tant pis si 2-3 posts merdent si ca corrigent les 1.5M autres

OK, si tu me donnes un accès à la base de données (mot de passe admin...) ainsi que la date jusqu'à laquelle c'est buggué, je veux bien essayer si j'ai un peu de temps ce week-end...

EDIT: j'ai relu ton post, ok alors je testerai sur un punbb que j'installerai sur un serveur...

Dernière modification par ®om (Le 12/03/2008, à 11:44)

Yann · Le 12/03/2008, à 12:17

Tu peux installer punbb en local Tiens moi au courant via ce topic, merci!

®om · Le 12/03/2008, à 12:20

OK, je t'ai envoyé un mail pour quelques question aussi

®om · Le 12/03/2008, à 13:30

Bon, en fait, ça n'est plus un problème d'encodage de caractères (ça n'est pas comme si la page était écrite en iso et qu'on la lisait en utf8).
Ce qui s'est passé, c'est que le texte était en utf8, a été lu comme de l'iso pour être réécrit en utf8.

Je m'explique.
Par exemple, pour le caractère 'é', le code utf8 est 0xc3a9 :
1100 0011 1010 1001
ce qui donne le caractère numéro 000 1110 1001, c'est à dire 0xe9, soit 233, qui quand on vérifie dans une table, correspond bien au 'é'.

Ce code a été interprété comme de l'iso lors de la conversion, donc :
1100 0011 1010 1001
a été interprété en iso comme le caractère 0xc3 (ce magnifique caractère Ã), suivi du caractère 0xa9 (le caractère ©)

Mais ces caractères mal interprétés en iso ont finalement été écrits en UTF-8 :
1100 0011 1000 0011 // caractère 0xc3 encodé en utf-8
1100 0010 1010 1001 // caractère 0xa9 encodé en utf-8
(je dis ça après avoir lu le code source d'un post avec des caractères "mal encodés" en hexa, ce sont bien ces octets là que l'on reçoit)

Donc ça n'est plus un problème d'encodage de caractères, il n'y a maintenant plus de différence entre quelqu'un qui voudrait réellement écrire un Ã suivi d'un © (même si c'est rare les gens qui le font volontairement ) et ce qui se trouve dans la base de données. Ce n'est pas un problème de décodage.

Du coup, le problème est "assez simple" à résoudre, il suffit de faire des substitutions des Ã© par des 'é' (et pareil pour les autres caractères bizarres), en prenant justement comme hypothèse que chaque fois que Ã© a été écrit dans la base, ce n'est pas l'utilisateur qui a voulu écrire cela

Ça n'est d'ailleurs pas toujours vrai que l'utilisateur n'a pas voulu écrire cela, je me rappelle d'un post où quelqu'un avait posté volontairement les caractères Ã suivi de © pour indiquer ce qui se produisait lors de problèmes de décodage. Son post n'aura alors plus de sens après la correction s'il n'avait pas été touché par le mauvais encodage du backup ("un 'é' mal encodé s'affiche 'é'"). Mais bon je pense qu'il vaut mieux rendre son post incohérent que les milliers d'autres posts

aleph a écrit :

ON NE MODIFIE JAMAIS UN CODAGE DE CARACTERES PAR DES METHODES DE SUBSITUTION DE CARACTERES. C'EST ET CE SERA TOUJOURS UN ECHEC.

Ça c'est vrai quand c'est un problème de décodage de caractères, ce qui n'est pas le cas ici. Ça a juste été le cas lors du backup.

Dernière modification par ®om (Le 14/03/2008, à 21:39)

aeacides · Le 12/03/2008, à 14:53

:lol::lol::lol::lol::lol::lol::lol:

Marde, fallait le savoir

++ pour l'explication

aleph · Le 12/03/2008, à 17:00

> @rom
> ...il suffit de faire des substitutions des Ã© par des 'é' ...

Non, jamais et je le maintiens.

Mais ta compréhension est correcte, il est tout à fait possible de sélectionner un bout de texte ("correct ou non") et de le transcoder de façon "correctement visible" en gardant bien à l'esprit que l'on ne sélectionne pas des caractères mais des bytes.

On décode et/ou encode correctement là où c'est nécessaire avec les outils idoines. Dans ces problèmes de codage, il est nécessaire et fondamental de toujours savoir à quel codage on a à faire. C'est là la clé du problème ou de la solution.

Il y a trois étapes où la connaissance du codage joue un rôle et est nécessaire. Un "string" sans connaissance de son codage n'a aucune valeur.

1) La base de données et l'état du codage qui contient le infos.
2) Le moteur qui lit et écrit dans le base de donnée qui doit tenir compte du codage de ce qu'il lit ou écrit.
3) Le codage du dispositif de sortie (string, fichier html ou écran) et la préparation du codage nécessaire à ce dispositif de l'info recueillie sous 2)

On pourrait même ajouter ici encore le visualisateur (IE, Firefox...) de l'utilisateur. Possibilité de changer le codage.

Voici un petit script Python qui illustre mes propos. Attention: celui-ci a été écrit sous Windows, comprendre avec un éditeur dont je connais les codages d'entrée (cp1252). Sous Ubuntu, l'aspect pourrait être différent (codage d'entrée utf-8).

# -*- coding: cp1252 -*-

# mimicbd2html.py
# Python 2.5.2

# Un dictionnaire simulant une base de données dont le contenu texte est
# soit des "byte strings", soit des unicodes.
bd = {
    'item1': 'élève', # iso-8859-1 ou cp1252
    'item2': 'cœur',  # cp1252
    'item3': 'une strophoïde à 2 €', #  iso-8859-1 ou cp1252
    'item4': unicode('élève', 'cp1252'), #unicode, codage non donné
    }

#~ def moteur(item):
    #~ source = bd[item]
    #~ u = unicode(source, 'iso-8859-1', 'replace')
    #~ return u

# moteur pour lire/écrire dans la base de donnée.
# condition nécéssaire, connaître le codage de ce que l'on cherche
# renvoie un unicode, c'est uniquement mon choix (une conventions)
# ici moteur de lecture uniquement, 
def moteur(item, enc):
    source = bd[item]
    if enc in ['cp1252', 'iso-8859-1']:
        #ceci est un décodage
        return unicode(source, enc, 'replace')
    else:
        return source

# Affiche le résultat du moteur en tenant compte de l'affichage,
# c'est à dire de l'encodage du dispositif de sortie.
# Note ce pourrait être la création d'un fichier ou string html.
def affiche(txt, enc):
    tmp = txt.encode(enc, 'replace')
    print "source en %-10s -> : %s" % (enc, tmp)

#illustration
r = moteur('item1', 'iso-8859-1')
affiche(r, 'cp1252')
affiche(r, 'iso-8859-1')
affiche(r, 'utf-8')
affiche(r, 'utf-16')

print
r = moteur('item2', 'cp1252')
affiche(r, 'cp1252')
affiche(r, 'iso-8859-1')
affiche(r, 'utf-8')
affiche(r, 'utf-16')

print
r = moteur('item3', 'iso-8859-1')
affiche(r, 'cp1252')
affiche(r, 'iso-8859-1')
affiche(r, 'utf-8')
affiche(r, 'utf-16')

print
r = moteur('item4', 'utf-8')
affiche(r, 'cp1252')
affiche(r, 'iso-8859-1')
affiche(r, 'utf-8')
affiche(r, 'utf-16')

Ce qui donne à l'exécution (Un effet très pervers dans le suite des bytes du codage utf-16 fait que le résultat ne passe pas dans ce forum. Aussi, l'ai-je manuellement effacé. C'est aussi pour cela que j'ai laissé de côté des encodages comme utf-32 ou d'autres...

source en cp1252     -> : élève
source en iso-8859-1 -> : élève
source en utf-8      -> : Ã©lÃ¨ve

source en cp1252     -> : cœur
source en iso-8859-1 -> : c?ur
source en utf-8      -> : cÅ“ur

source en cp1252     -> : une strophoïde à 2 ?
source en iso-8859-1 -> : une strophoïde à 2 €
source en utf-8      -> : une strophoÃ¯de Ã  2 Â€

source en cp1252     -> : élève
source en iso-8859-1 -> : élève
source en utf-8      -> : Ã©lÃ¨ve

Un oeil averti notera la différence entre iso-8859-1 et cp1252. En effet, aucune des tables iso-8859-1 à iso-8859-15 normalisées ne sont complètes et satisfaisantes pour les langues ouest-européennes. Ce qui explique pourquoi cp1252 est et restera en vogue pendant longtemps.

En conclusion, tout transcodage s'effectue toujours avec des outils de décodage et d'encodage et non par des substitutions de caractères. Comme dit précédemment, ce n'est pas pour rien que ces outils existent sous toutes le plaformes dans tous les langages.

Ce n'est quand même pas difficile à s'imaginer que si ces outils ont été créés, c'est bien parce que de simples subsitutions ne suffisent pas, quelle que soit le niveau d'utilisation (base de données, affichage, code source, clavier, ...)

Reste à savoir où.

®om · Le 12/03/2008, à 17:21

Je suis totalement d'accord avec toi, sauf que là ce n'est pas un problème d'encodage de caractères ici...

Mais ta compréhension est correcte, il est tout à fait possible de sélectionner un bout de texte ("correct ou non") et de le transcoder de façon "correctement visible" en gardant bien à l'esprit que l'on ne sélectionne pas des caractères mais des bytes.

C'est bien pour cela que j'ai regardé en hexa où était les problèmes, et pas en texte.

1) La base de données et l'état du codage qui contient le infos.
2) Le moteur qui lit et écrit dans le base de donnée qui doit tenir compte du codage de ce qu'il lit ou écrit.
3) Le codage du dispositif de sortie (string, fichier html ou écran) et la préparation du codage nécessaire à ce dispositif de l'info recueillie sous 2)

Là je te l'accorde, il y a une partie un peu passée sous silence dans mon raisonnement précédent, je fais l'hypothèse que les octets reçus par le navigateurs pour les posts sont les mêmes que ceux stockés dans la base de données (et qu'il n'y ait pas de post-traitement par le serveur php).
Cependant, cela me semble plus que probable, étant donné que les octets représentant les caractères encodées en utf8 sont correctement transmis, et que quelqu'un qui écrit Ã© ou qui avait écrit 'é' qui est maintenant buggé donnent les mêmes octets.

On pourrait même ajouter ici encore le visualisateur (IE, Firefox...) de l'utilisateur. Possibilité de changer le codage.

Pareil que ma première remarque, ce que j'ai expliqué dans le précédent post ne concerne que des octets, à aucun moment des caractères. Ce sont les octets reçus qui ne sont pas bons, qu'il faut substituer par d'autres octets.

Dernière modification par ®om (Le 12/03/2008, à 18:57)

jrev · Le 13/03/2008, à 11:44

Bonjour à tous,

Si je comprends bien et pour résumer ce fil de discussion, l'utilisateur lambda de firefox 2.0.0.12 ne peut rien faire contre ce mauvais rendu des caractères accentués.

De plus, ce problème est tout à fait particulier à certaines pages du forum de ubuntu.fr

et ne concerne pas les autres sites explorés par notre navigateur favori
Merci de me confirmer que j'ai bien compris

Dernière modification par jrev (Le 13/03/2008, à 13:12)

jrev · Le 13/03/2008, à 11:48

je viens de modifier ma signature avec succès le "é" de réseau était mal rendu

Un exemple du bug pour ceux qui n'auraient pas suivi le dédale de ce fil et n'auraient encore rien constaté :

Dernière modification par jrev (Le 13/03/2008, à 13:31)

Laurent82 · Le 13/03/2008, à 12:11

aleph a écrit :

Autre problème. Modifier des caractères avec un outil comme sed dans un script n'est pas optimal. Il ne devrait pas être difficile de comprendre que modifier un million de caractères revient à exécuter un million de fois l'application sed. On ne travaille sérieusement pas comme cela.

Je viens de faire un test comparatif entre sed et perl sur un fichier .txt d'environ 100Mo

Le résultat est étonnant car perl se montre 5 fois plus rapide que sed pour effectuer la même substitution.

Sur ce fichier d'environ 100Mo, la substitution avec perl d'un caractère présent plus d'un million deux mille fois n'a pris qu'à peine plus de 3 secondes.
Donc même s'il y plusieurs substitutions et que le BDD est importante, je ne crois pas que ça soit la mer à boire non plus...

aleph · Le 13/03/2008, à 13:37

> Laurent82

Je te l'accorde bien volontiers...
... mais cela n'a rien à voir avec ce que j'ai écrit.

Pour moi la discussion est close.

jrev · Le 13/03/2008, à 21:01

aleph a écrit :

> Laurent82
Je te l'accorde bien volontiers...
... mais cela n'a rien à voir avec ce que j'ai écrit.
Pour moi la discussion est close.

Et le problème également ?

Carton · Le 14/03/2008, à 20:33

La tension est palpable...
aleph, puis-je avoir tes coordonnées, une adresse mail, où n'importe quoi qui me permettrait de te joindre ?

aleph · Le 14/03/2008, à 21:32

> La tension est palpable...

Main non, mais non. Quand je dis que la discussion est close, n'y vois pas une quelconque animosité ou nervosité de ma part. C'est simplement que dans ces discussions sur le codage de caractères, on tourne toujours et très vite en rond et je pense qu'il est préférable de laisser tomber.

®om · Le 14/03/2008, à 21:37

aleph a écrit :

je pense qu'il est préférable de laisser tomber.

Le but est principalement de résoudre le problème du forum...

D'après moi, pour les raisons que j'ai données en #33, ce n'est pas un problème d'encodage de caractères (pas directement), et la solution est de faire une substitution...

Je pense que ce problème est important à corriger, car ça fait plusieurs posts où des gens viennent d'installer ubuntu, et pensent que ça vient d'une mauvaise configuration de leur ubuntu, <extrapolation>se perdent dans des posts d'encodage de caractères pendant des heures (c'est pas très sympa de faire perdre du temps aux gens pour rien ^^), et finissent par se dire que linux c'est compliqué</extrapolation>... Ce qui n'a rien à voir.

Dernière modification par ®om (Le 14/03/2008, à 21:42)

®om · Le 18/03/2008, à 13:21

Du nouveau?

huats · Le 18/03/2008, à 15:06

je devais suivre ça, mais j'avoue qu'en ce moment je suis débordé ailleurs... On va refaire un point aujourd'hui entre admins et on vous tient au courant dans ce post.

Ishimaru Chiaki · Le 20/03/2008, à 19:30

Bonjour.

Je viens de remarquer ce problème en retournant voir un topic que j'avais posté il y a près d'un mois au sujet de problèmes avec le miroir canadien dans la page des downloads. Tous les "é", "è", "ç" et autres accents sont remplacés dans mon message, tandis que ce n'est pas le cas dans la réponse.

Pour info, je suis sous firefox 2.0.0.12 sous XP. Je n'ai pas encore testé ni installé ubuntu parce que je suis en pleins travaux sur mon site (passage de phpbb vers connectixboards, couplage forum-site, design). De plus, j'ai eu vent que des choses ont changé au niveau du partitionnement avec les MAJ d'ubuntu par rapport aux tutos du SdZ.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 12/03/2008, à 10:38

Re : Encodage des caractères sur le forum

#27 Le 12/03/2008, à 10:45

Re : Encodage des caractères sur le forum

#28 Le 12/03/2008, à 11:09

Re : Encodage des caractères sur le forum

#29 Le 12/03/2008, à 11:38

Re : Encodage des caractères sur le forum

#30 Le 12/03/2008, à 11:41

Re : Encodage des caractères sur le forum

#31 Le 12/03/2008, à 12:17

Re : Encodage des caractères sur le forum

#32 Le 12/03/2008, à 12:20

Re : Encodage des caractères sur le forum

#33 Le 12/03/2008, à 13:30

Re : Encodage des caractères sur le forum

#34 Le 12/03/2008, à 14:53

Re : Encodage des caractères sur le forum

#35 Le 12/03/2008, à 17:00

Re : Encodage des caractères sur le forum

#36 Le 12/03/2008, à 17:21

Re : Encodage des caractères sur le forum

#37 Le 13/03/2008, à 11:44

Re : Encodage des caractères sur le forum

#38 Le 13/03/2008, à 11:48

Re : Encodage des caractères sur le forum

#39 Le 13/03/2008, à 12:11

Re : Encodage des caractères sur le forum

#40 Le 13/03/2008, à 13:37

Re : Encodage des caractères sur le forum

#41 Le 13/03/2008, à 21:01

Re : Encodage des caractères sur le forum

#42 Le 14/03/2008, à 20:33

Re : Encodage des caractères sur le forum

#43 Le 14/03/2008, à 21:32

Re : Encodage des caractères sur le forum

#44 Le 14/03/2008, à 21:37

Re : Encodage des caractères sur le forum

#45 Le 18/03/2008, à 13:21

Re : Encodage des caractères sur le forum

#46 Le 18/03/2008, à 15:06

Re : Encodage des caractères sur le forum

#47 Le 20/03/2008, à 19:30

Re : Encodage des caractères sur le forum

Pied de page des forums