Caractèress non imprimables et XML - Page 1

Bonsoir,

J'ai besoin d'envoyer des caractères non imprimables à un port série via un programme dédié, je n'ai pas la main sur le programme.
Le programme parse un fichier xml avec la syntaxe suivante:

<facturette>
<libre>texte libre</libre> </facturette>

Quand j'ai besoin d'envoyer des séquences de caractères non imprimables au port série (en fait au périphérique qui est derrière, à savoir une imprimante à reçu) je passe par les entités xml, par exemple: &#x1B;t, jusuqu'à là ça marche très bien.

Maintenant comme ces commandes sont fastidieuses à taper (souvent synonyme de fautes de frappe) donc j'ai eu l'idée de les déclarer en tant qu'entité XML et c'est là que ça coince, les valeurs ASCII non imprimables n'ont pas l'air de passer.

Voici ce que j'ai mis dans l'entête de mon fichier xml:

<!DOCTYPE facturette SYSTEM "billentities.dtd">

et voici ce qu'il y a dans mon fichier DTD

<!ENTITY accents "&#x1B; t ">

quand je fais un appel à &accent; dans mon fichier xml rien ne ce passe. Quand je remplace les valeurs hexa dans ma DTD par des valeurs imprimables alors ça passe.

Avez-vous une idée de comment je pourrais m'en sortir?

Merci.

avec cdata?

<facturette>
<libre><![CDATA[texte libre]]></libre>
</facturette>

Même problème que l'autre fois je parie (je sais plus de qui, mais le topic devrait pas être trop dur à trouver...)
Ton dtd est externe...

C'est bizarre, normalement ce que tu as écrit dans ton fichier DTD devrait marcher... mais peut-être que le parseur XML du programme que tu utilises est buggué. Est-ce que ça marche si tu remplaces ce code hexa par un autre code hexa mais correspondant à un caractère imprimable ? juste histoire de tester d'où vient le problème.

Tu peux peut-être essayer d'insérer littéralement le caractère non-imprimable dans ton fichier DTD (avec un éditeur hexa) à la place de la référence hexadécimale mais je ne sais pas si ça résoudra le problème.

@squalyl: justement non je veux externaliser ces données pour pas avoir à les retaper à chaque fois. Elles passent sans problème "en brut" (&#valeur_hexa entre mes balises libres sinon. C'est juste quand je les fait passer par la DTD que ça plante.

@Sally: le parseur me laisse passer les caractères hexa en brut quand je les mets directement dans le fichier xml donc sauf erreur je ne pense pas que ça puisse venir de là (si?).

GoldenCrystal (./3) :
Ton dtd est externe...

(Bis)

(GoldenCrystal > ça fait quoi que la DTD soit externe ? si son parseur ne prenait pas en compte les entités définies dans des DTD externes ça ne marcherait pas non plus quand il utilise des caractères imprimables, donc ça ne peut pas être ça le problème, du coup je ne vois pas ce que tu veux dire)

JoNas > ça dépend, il se peut que ton parseur n'aime pas le fait qu'une entité apparaisse dans une autre entité (bien que normalement ce soit correct en XML), c'est pour ça que je suggérais de tester en écrivant sous forme d'entité un caractère imprimable. Si ça ne marche pas c'est que le problème n'est pas lié aux caractères non-imprimables.

Je m'explique, essaie de mettre dans ta DTD :
<!ENTITY accents "&#x58;">

normalement &accents; devrait maintenant être remplacé par la lettre X. Si c'est pas le cas c'est que le problème n'a rien à voir avec les caractères non-imprimables mais est lié au fait d'utiliser une entité dans une entité. À ce moment-là tu peux peut-être le résoudre en insérant le caractère non-imprimable directement dans la DTD à coup d'éditeur hexa.

edit : mince j'avais pas vu que quand on tape une entité hexa dans un post ça la remplace par le caractère en question à l'affichage ^^

Ah oui, en fait en lisant tout à l'heure, j'avais compris que ça marchait quand il mettait les valeurs imprimables à la place des entités en fait… Et quand il t'as répondu après ça disait ce que j'avais compris plus tôt du coup j'ai pas fait gaffe.
Cela dit, je testerais quand même avec un DTD embarqué pour être sur

Après, les entités définies par un code numérique, c'est sensé fonctionner, donc c'est peut-être juste un problème au niveau du parser utilisé… (Quel est-il si tu le connais ?)

ça fonctionne avec des caractères imprimables dans les entities, donc du coup ça doit être le parseur. je ne connais pas le parseur mais l'appli est développée en .NET C# donc je pense sans trop me tromper que ça doit être du M$ derrière tout ça. Dans ce cas là que faudrait-il changer à ce parseur pour qu'il accepte les caractères non imprimables? faire une table de correspondance "en dur"? changer l'encodage?

(JoNas, tu es KoKas )

En fait si c'est du .NET, c'est System.Xml qui est utilisé (enfin probablement, sinon ça peut aussi être System.Xml.Linq…), du coup ça devrait être assez facile de faire des tests pour voir ce qui ne fonctionne pas
(Il y a pas mal de réglages possibles sur XmlReader… Mais je ne sais pas si ça vient de là. Comme les DTD sont une fonctionnalité peu utilisée, il peut éventuellement y avoir des bugs que personne n'aura remarqué… (même si ça me semble étrange ^^))
xmlDocument.Load(Console.In); xmlDocument.Save(Console.Out); } } }Pour les tests réduits (sans toute l'application qui va derrière), un truc de ce genre devrait suffire : namespace Test { using System; using System.Xml; public static class Program { public static void Main() { var xmlDocument = new XmlDocument(); (À compiler avec csc.exe qui devrait se trouver dans ton répertoire c:\Windows\Microsoft.NET\Framework\vXXX, avec XXX à remplacer par la version qui va bien… Ou bien à compiler avec gmcs/dmcs de mono sous Linux/OSX… J'ai pas testé mais j'espère ne pas avoir fait d'erreurs dans ce code )
Ça devrait permettre de comparer directement l'entrée et la sortie (et avec quelques modifs pour utiliser XmlReader, tu peux ajuster les options de lecture, mais je ne crois pas que tu en aies besoin ici…), au moins tu sera vite fixé si c'est un bug de .NET ^^
(Par contre si c'est le cas, tu ne pourras pas le résoudre toi-même )

Merci GoldenCrystal.

J'ai essayé de compiler le code mais ça me renvoit des erreurs.

C:\Users\jonas>c:\windows\Microsoft.NET\Framework\v4.0.30319\csc.exe c:
test.cs
Compilateur Microsoft (R) Visual C# 2010 version 4.0.30319.1
Copyright (C) Microsoft Corporation. Tous droits réservés.

c:\test.cs(7,19): error CS1518: Class, delegate, enum, interface ou struct
attendu
c:\test.cs(9,31): error CS1518: Class, delegate, enum, interface ou struct
attendu
c:\test.cs(14,1): error CS1022: Définition de type ou d'espace de noms, ou fin
de fichier attendue

Ouais en fait j'ai vu ça tard hier soir... J'ai oublié de mettre la méthode dans une classe (Bon à la base je prévoyais de mettre que la méthode dans le post, j'ai rajouté le namespace et les using après )
Je vais éditer le post

Bon en fait ça viens vraiment du parseur, en mettant les entities en interne (dans le fichier xml) j'ai une levée d'exception au niveau de l'appli. Je vais essayer de prendre contact avec les dev de l'appli, mais avant tout j'aimerai savoir comment le problème peut-il être règlé (s'il peut l'être), dois-je leur indiquer d'utiliser un autre parseur? dois-je leur suggérer de changer l'encodage?

Pour info voici la pile d'appel.

à System.Xml.XmlTextReaderImpl.Throw(Exception e)
à System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
à System.Xml.XmlTextReaderImpl.Throw(Int32 pos, String res, String[] args)
à System.Xml.XmlTextReaderImpl.ThrowInvalidChar(Int32 pos, Char invChar)
à System.Xml.XmlTextReaderImpl.ParseText(Int32& startPos, Int32& endPos, Int32& outOrChars)
à System.Xml.XmlTextReaderImpl.ParseText()
à System.Xml.XmlTextReaderImpl.ParseElementContent()
à System.Xml.XmlTextReaderImpl.Read()
à System.Xml.XmlLoader.LoadEntityReferenceNode(Boolean direct)
à System.Xml.XmlLoader.LoadNode(Boolean skipOverWhitespace)
à System.Xml.XmlLoader.LoadDocSequence(XmlDocument parentDoc)
à System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
à System.Xml.XmlDocument.Load(XmlReader reader)
à System.Xml.XmlDocument.LoadXml(String xml)

Ça crash comme ça avec ton application directement ?
(Car si ça crash avec dtd interne et pas avec dtd externe, il y a un sérieux problème je pense... )
Au fait, tu as essayé avec deux zéros après le "x" dans tes entités ?

Le message ne s'affiche pas avec une DTD externe mais les données ne sont pas envoyés au port série. en DTD interne le comportement est identique sauf que le message est affiché.

Pas bête l'idée des deux zéros mais ça ne fonctionne pas non plus.

J'ai commencé à jeter un coup d'oeil sur le net mais pour le moement je ne trouve pas de référence à une résolution de ce problème avec le parseur .NET.

Ah d'accord...
J'avais déjà regardé avec Google si y'avait quelque chose d'intéressant pour ton problème, mais comme je l'ai dit, les dtd ne sont pas utilisés des masses. (Loin d'être inutilisés certes, mais... )
Une solution qui pourrait peut-être résoudre ton problème initial, d'une manière différente, serait d'utiliser une transformation xsl... (Quitte à devoir coder un mini outil pour faire la transformation)

(tout ce bordel pour envoyer des octets sur un bête port série... vous êtes sûr qu'utiliser .NET c'est un gain de temps finalement ? )

(Je comprends pas vraiment pourquoi utiliser du XML pour ça à la base surtout. ^^
Le .NET c'est un environnement très bien quand tu ne tombes pas sur des problèmes/bugs comme celui-ci (Habituellement c'est plutôt dans SWF les "bugs" )
Mais je dois avouer que je suis un peu déçu pour le coup. Les parser XML de Microsoft sont sensés être pas mauvais et respecter assez bien les normes... Là si ça ne supporte pas un truc valide (Faudrait se plonger dans les spec des DTD Pour être sur, mais ça attendra) ça craint )