Discussion :

[bulbo]

Bonjour,

Voila mon probleme: j'ai defini dans un schema XML un element contenant du texte.

Il est possible que ce texte contienne des carateres du genre "&" et je ne voudrais pas que cela soit parse..

Si je definis mon element comme ca:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
<xs:element name="monElement" >
  <xs:complexType>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="name" type="xs:string" use="required" />
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:element>

L'element suivant plante au parsing:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
<monElement name="elt">
un texte avec un &
</monElement>

Pour info le fichier est parse avec Castor, une librairie java qui fait du mapping XML.

Bulbo

[GrandFather]

Bonjour,

Dans ton fichier XML tu n'as pas moyen de remplacer & par l'entité XML & ?

[Swoög]

Bonjour,

l'utilisation de & et < seuls (notamment) est interdite dans tout fichiers xml, cela relève, non pas, de la validation, mais du "bien-formé" d'un xml, les & servent pour les entités, et les < pour les ouvertures de balises...

il vous faudrait remplacer & par &amp;

ou alors, inclure vos & ou < dans une section CDATA :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<![CDATA[&]]>

[bulbo]

Je savais qu'on allait me repondre ca

Le probleme c'est que mon fichier XML va contenir des templates de scripts unix par exemple et il arrive que le caractere & apparaisse.

Le &amp; est une solution mais c'est un poil degeu au milieu d'un script, j'aurais preferre une option du schema qui precise que le texte de l'element ne doit pas etre parse, du genre d'un CDATA ...

Enfin je vais voir ce que ca donne ...

Bulbo

[bulbo]

Bon il semblerait que le &amp; soit encore ce qu'il y a de moins crade.. ce probleme est donc regle ..

Par contre j'avais lu dans une doc que normalement le texte restait le meme dans le cas d'un type xs:string, et la je m'apercois que ce sagouin m'a viré tout les carriage return

J'ai raison de trouver ca anormal et castor se fout de moi.. ou alors j'ai encore tout compris de travers .. :

Bulbo

[GrandFather]

Le &amp; est une solution mais c'est un poil degeu au milieu d'un script, j'aurais preferre une option du schema qui precise que le texte de l'element ne doit pas etre parse, du genre d'un CDATA ...

Dans ce cas, pourquoi n'utilises-tu pas <![CDATA[]]> ? Et tu n'as rien à préciser au niveau du Schema.

[bulbo]

Le &amp; est une solution mais c'est un poil degeu au milieu d'un script, j'aurais preferre une option du schema qui precise que le texte de l'element ne doit pas etre parse, du genre d'un CDATA ...

Dans ce cas, pourquoi n'utilises-tu pas <![CDATA[]]> ? Et tu n'as rien à préciser au niveau du Schema.

Bonne idee, j'ai colle tout le template dans le <![CDATA[]]> et ca marche nickel .. c'est pas super joli ce crochet qui se referme 10 lignes plus bas.. mais mon script est preserve alors on pardonne

Par contre les retours chariots sont toujours aux abonnes absent qqun a une idee ??

Bulbo

[Swoög]

pour les retours chariots, je n'arrive pas à très bien comprendre ce que tu veux dire ?? quand est-ce qu'il sautent ? dans le XML lui-même ?

au moment du parsage ?

[bulbo]

C'est apres le parsing ..

Le texte est sur plusieurs lignes mais lorsque je le recupere apres le parsing tout est sur une ligne

Par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
<![CDATA[
Voici un texte sur
plusieurs ligne & avec
des caracteres a ne pas parser
]]>

Me donne apres le parsing la chaine de caractere suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Voici un texte surplusieurs ligne & avecdes caracteres a ne pas parser

Autant dire que dans le cas qui me preoccupe, un script genere a partir d'un template sur une ligne risque fort de m'exploser au visage

A mon avis c'est Castor qui ne parse pas bien ce genre de chose ou alors je dois ruser et essayer de passer des options au parser SAX utilisé par Castor...

Bulbo

[Swoög]

je sais pas, moi, à chaque fois que j'ai du texte, il me le sors tel quel, nouvelles lignes, espace, tabulations comprises...
désolé de ne pouvoir aider sur ce point...

[GrandFather]

A mon avis c'est Castor qui ne parse pas bien ce genre de chose ou alors je dois ruser et essayer de passer des options au parser SAX utilisé par Castor...

Ce ne doit pas être au niveau du parseur qu'est le problème ; le contenu du <![CDATA[]]> n'est pas parsé ce qui garantit une restitution intégrale du contenu de la balise.

Le problème doit plutôt se trouver au niveau de Castor, ou peut-être la différence de codage des saut de lignes entre Unix et Windows ?

[Swoög]

Le problème doit plutôt se trouver au niveau de Castor, ou peut-être la différence de codage des saut de lignes entre Unix et Windows ?

pourquoi pas, possible, pour assurer une copatibilité, il faut s'assurer que les saut de ligne sont bien représenter par des \r\n (0x0A+0x0D)...

[bulbo]

Merci encore pour votre aide ..

Pour ce qui est des retours chariots ce n'est pas un probleme Unix/windows, le fichier xml a ete ecris sur la meme machine que le programme et c'est un windows donc a priori \r\n pour les retours ...

Je pense aussi que c'est un probleme castor .. pour en avoir le coeur net je vais ecrire un petit parser SAX utilisant xerces, le parser utilise par defaut par castor, et on va voir ce qu'il en est ..

Bulbo

[bulbo]

C'est bon, j'ai resolu mon probleme de retour chariot ..

Il s'agissait bien d'un bug de la version 9.5.3 de Castor, c'est corrige dans la 9.5.4 ..

Bulbo