Encodages, jeux de caractères et références d’entités (http://www.w3qc.org/presentations/20050425/index.html)

Enregistrement audio

Voici l’enregistrement de cette conférence (37 mn) sous plusieurs formats propriétaires ou libres. À vous de choisir… et de comparer! 🙂

• 4573 Ko – Format RealAudio 9 (http://www.w3qc.org/presentations/20050425/Normand_Lamoureux2.rm)
• 5559 Ko – Format QuickTime 6.5 (http://www.w3qc.org/presentations/20050425/Normand_Lamoureux.mov)
• 5647 Ko – Format Windows Media 8 (http://www.w3qc.org/presentations/20050425/Normand_Lamoureux.wma)
• 5821 Ko – Format Speex (http://www.w3qc.org/presentations/20050425/Normand_Lamoureux.spx)
• 8397 Ko – Format OGG (http://www.w3qc.org/presentations/20050425/Normand_Lamoureux.ogg)
• 11 136 Ko – Format MP4 (http://www.w3qc.org/presentations/20050425/Normand_Lamoureux.mp4)
• 13 449 Ko – Format MP3 (http://www.w3qc.org/presentations/20050425/Normand_Lamoureux.mp3)

Remarques sur la présentation

Désolé de ne pas avoir été là, mais je suis un peu loin. J’ai donc décidé de vous faire mes remarques ici.

Lorsque Normand présente le jeu de caractères ANSI et surtout la partie avec la validation des caractères problématiques, j’avoue être un peu sceptique quant à la méthode utilisée.

Je ne connais pas bien la norme ANSI, mais la table qui est présentée représente le jeu de caractère windows-1252 (ou cp1252). Il est un dérivé de l’iso-8859-1 effectué par Microsoft. Son principe était de reprendre le jeu de caractères internationale iso-8859-1 et d’ajouter les caractères manquants à des emplacements normalement réservés.

Finalement, il est tout à fait normal que la page présentée ne valide pas puisqu’elle est indiquée comme utilisant une charset iso-8859-1 qui a pour zone réservée les caractères de 128 à 159, il est donc tout à fait normal que le validateur n’autorise pas la présence de ces caractères. D’ailleurs, si on force le charset windows-1252 dans le validateur, on peut voir que seul le caractère 127 n’est plus accepté et que tous les autres caractères de la page sont acceptés.

Cependant, on pourrait se demander pourquoi les navigateurs ne se plaignent pas comme l’a fait le validateur. Et bien cela vient d’un problème de compatibilité. En effet, beaucoup de webmasters déclarent un charset iso-8859-1 alors que leur site est en fait en windows-1252. Les navigateurs ont alors décidé de passer systèmatiquement au windows-1252 lorsqu’ils rencontrent une déclaration iso-8859-1 afin de corriger une grossière erreur rencontrés dans une majorité des sites conçus sous Windows. Voir ce bug Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=228779) pour plus d’infos.

EDIT: Je n’étais pas allé assez loin et vous ajoutez que ANSI = windows-1252

EDIT 2: Je ne suis pas d’accord non plus avec le fait qu’ iso-8859-1 soit le standard Internet, il s’agit simplement du charset le plus utilisé aujourd’hui dans les système mais ne constitue en rien un standard. On pourrait notamment citer les documents XML qui doivent être interprétés en utf-8 en cas d’absence d’information de charset (d’après la norme XML).

–VincentRobert 26 avr 2005 à 15:54 (PDT)

Merci, Vincent.

La méthode utilisée visait à mettre en évidence les caractères qui poseront problème lorsque l’encodage utilisé est ANSI/Windows-1252, alors que l’encodage déclaré est ISO-8859-1. Ce point n’était effectivement pas clair et je rectifierai en conséquence.

Je me souviens avoir dit qu’ISO-8859-1 était l’encodage par défaut sur Internet, mais pas d’avoir dit qu’il s’agissait d’un standard. Si je l’ai dit, je retire mes paroles car ce n’est effectivement pas le cas.

Normand Lamoureux, 30 avril 2005

Hum désolé, j’ai utilisé le terme standard alors qu’il ne me semble pas non plus être utilisé dans la présentation. Mais le fait de dire qu’iso-8859-1 est l’encodage par défaut sur Internet me gène toujours autant.

Déjà le mot Internet ne signifie pas grand chose dans ce contexte. Internet est un réseau dont les protocoles de base n’utilisent pas de chaînes de caractères et dont la notion d’encodage est donc forcément absente (TCP/UDP et IP).

Tu voulais peut-être parler des applications et protocoles utilisables sur Internet (irc, http, ftp, etc.), dans ce cas, il ne s’agit pas non plus d’un encodage par défaut. Ces protocoles ont généralement fait un choix d’encodage bien précis dans leur spécification, ou alors intègre la notion d’encodage dans le protocole, mais on ne peut pas parler d’encodage par défaut.

Chaque norme, chaque protocole définit les encodages avec lesquelles il faut travailler. Lorsque ce n’est pas la cas, les applications ont généralement fait un choix arbitraire qui se portait bien souvent sur iso-8859-1 ou windows-1252, très souvent par simple incompréhension et qu’il s’agit des encodages généralement configurés sur les systèmes d’exploitation Windows ou Linux.

À propos de la méthode de démonstration des caractères invalides, je comprends tout à fait ton point de vue. Mon avis est simplement que je ne suis pas d’accord avec la méthode. Lorsque l’on souhaite comprendre les encodages, le but n’est pas d’apprendre par cœur la liste des caractères problématiques lorsqu’une page en windows-1252 est déclaré en iso-8859-1.

Je connais pas mal la problématique que j’étudie depuis maintenant quelques années, et je ne connais toujours pas par cœur ces caractères, et je n’en ai pas besoin. Il me suffit à chaque fois de consulter les tables pour comprendre les caractères que j’ai le droit d’utiliser et ceux que je ne peux pas.

Un point très important de ta présentation — qui fait que je l’ai beaucoup appréciée — est que tu es un des seuls à mentionner qu’un fichier est avant tout une suite d’octets et donc de nombres. Cette notion est très importante lorsque l’on commence à travailler avec les encodages, et je pense qu’il serait possible d’encore plus la développer, notamment dans cette démonstration. Peut-être une prochaine fois 😉

Voilà, j’espère que toutes ces remarques t’auront été utiles et que tu continueras de bien éduquer les québécois avec ton superbe accent 🙂

–VincentRobert 11 mai 2005 à 14:54 (PDT)