Assistance pédagogique

Après avoir testé tes fichiers, il s'avèrent qu'ils passent parfaitement... une fois le fichier converti en utf8 avec un petit outil adapté

voir discussion http://moodle.org/mod/forum/discuss.php?d=75210

qui fait le point sur ces outis et les éditeurs de texte qui le font.

ci-joint, ton fichier réencodé correctement en UTF8 que j'ai importé dans ma 1.8.2, avec accents et tout. Je regarde l'export de suite...

L'informatique historique encode les caractères sur 7 bits, donc des valeurs de 0 à 127. Celà donne 128 caractères possibles, très peu pour tout imprimer. A l'époque on s'en fiche un peu : le jeu de caractère suffit à piloter une "imprimante télécommandée" (les anciens modèles IBM à boule ou à marguerite) : le télétype.

Dans la fin des années 60 apparaît le terminal cathodique, imprimant une matrice de points sur laquelle on peut évidemment imprimer toute une combinaison de glyphes. l'encodage passe de 128 à 256 valeurs (8 bits), mais une grande bataille a lieu pour savoir quels symboles prennent les 128 dernières positions. Les américains (ANSI : American National Standard Institute) imposent l'ASCII, que tout le monde ne suit pas (le système d'exploitation DOS choisit de mettre des caractères "pseudo-graphique" pour faire les bordures de fenêtres en mode texte).

L'ASCII étendu est négocié avec les européens pour englober les caractères accentués, il devient alors le latin-1. Mais d'autres variantes apparaissent pour gérer certaines particularités (tcheque, polonais, etc.). Toujours est-il que 256 codes possibles, c'est trop juste. Il n'y a rien à faire, surtout que l'informatique s'internationalise. Il faut prendre en compte le cyrillique, le grec, l'hébreu, l'arabe etc. On commence d'abord par produire des polices spéciales, qui en face des codes de caractères changent l'apparence de la lettre vue. Mais alors, suivant la police, un "a" ASCII peut valoir un "alpha" grec (assez logique sont-ils quand même), ou un autre caractère russe.

Avec cette logique, impossible d'ajouter des nouveaux caractères au delà de 256 caractères par document, et donc impossible de coder des documents multilingues.

Le Web pousse alors à trouver un format qui augmente réellement le nombre de caractères disponibles dans le même encodage : l'Unicode ("code unique") ou UTF16 qui utilise 16 bits, donc 65536 caractères. On peut penser à intégrer le chinois et les diverses représentations japonaises.

Le problème, c'est que pour 98% des textes diffusés dans l'informatique, il faut doubler le volume de code (un octet nul + le code ASCII) avec des données "inutiles". L'idée est donc de dire : si on écrit en ASCII, on écrit en 8 bits, si on veut sortir et utiliser des caractères hors ASCII, on écrit une petite séquence spéciale qui permet d'écrire un caractère "multi-octet". C'est finalement l'UTF8, puissant mais efficace.

Pourquoi le texte semble pareil dans l'éditeur de texte quand on le convertit ?

 Parce que l'éditeur est "conscient" du codage réel des caractères et sait afficher le glyphe correct. Si le fichier est en UTF8, l'éditeur va rechercher le glyphe adéquat selon la séquence multi-octet (ou la lettre simple ASCII). Même notepad sait faire cette détection (mais pas wordpad, qui ne connaît que l'ANSI !!)