Suite à une judicieuse remarque de Patrice et de Jb Evain il semblerait que je faisais fausse route. Dans mon précédent billet sur le sujet je sous entendais que le BOM (Byte Order Mark) utilisé par les encodings UTF faisaient planter XDocument.

Ce qui est vrai pour la méthode Parse dont l’objectif est de créer un XDocument depuis une chaine, mais pour pour la méthode Load qui prend un stream en paramètre. En effet si je passe mon stream directement à la méthode Load j’obtiens bien le résultat attendu et sans avoir à enlever le BOM. Il semblerait que je n’utilisais juste pas la bonne méthode.

Merci à vous deux.

J’y ai pensé un petit peu de temps avant de comprendre…

Le contexte : je récupère un texte représentant le contenu d’un fichier xml depuis une base de données. Le contenu est alors représenté sous la forme d’un tableau de byte. J’essaie plusieurs encoding avant d’utiliser le fameux UTF8 dont une référence est faite dans l’en-tête du fichier.

Je me dis que c’est forcément le bon puisqu’auparavant j’obtenais une chaine contenant systématiquement 3 caractères inintelligibles, ce qui n’est plus le cas. Je décide donc de parser cette chaine avec XDocument, une classe du namespace System.Xml.Linq. Et là … c’est le drame : le XDocument.Parse génère une exception.

L’explication : En fait les 3 caractères inintelligibles n’avaient pas disparu suite à l’utilisation du bon encoding. Ils étaient toujours bel et bien présent. Il s’agissait du Byte Order Mark. Qu’est-ce que le BOM ? Il s’agit de 3 octets utilisés notamment dans les différents UTF afin de signaler l’ordre des octets. En effet au niveau le plus bas de représentation on appelle endianness l’ordre des unités d’adressages comme les octets, les bits ou les mots. En bref votre ordinateur peut soit être big-endian soit little-endian, ce qui respectivement implique, l’octet de poids le plus fort est le plus à droite (adresse mémoire la plus petite) et l’octet de poids le plus faible est le plus à droite. A noter que les PC x86 sont little-endian. Ce BOM sert donc à ce que l’ordinateur sache correctement décodé le fichier même si celui-ci a été transféré d’un ordinateur big-endian à un ordinateur little-endian.

La solution : Retirer le BOM du tableau de byte avant de le convertir en texte et d’essayer de le parser. Dans mon cas je dois retirer les trois premiers octets s’ils ont les valeurs : 239 187 191. Comme le dit le W3C c’est normalement une opération à effectuer uniquement si votre navigateur est vieux

Mais qu’est ce que c’est que ce bordel ? Je sais que ça faisait longtemps que j’utilisais plus trop Visual Studio… je passe plus de temps avec des sharpies maintenant. Mais est-ce vraiment la vengeance de Visual Studio 2008 ? Me mettre en double, triple ou quadruple chaque élément de la boite à outils ?!!

Si à vous aussi votre éditeur de code préféré vous en veux, rendez-vous sur MS Connect. La solution est expliquée, il suffit d’aller dans %localappdata%\Microsoft\VisualStudio\9.0 et de supprimer les fichiers cachés avec l’extension *.tbd.

Il est des habitudes de Jetbrains de proposer un Early Access Program pour chaque version majeure de Resharper. Depuis le 19 octobre Resharper 5.0 est accessible de cette manière.

Cependant hier ils ont enfin mis à disposition une version compatible avec la dernière beta de Visual Studio.

Foncez, c’est juste là !!!