Conversion : entité perdue

Bonjour à tous

Je tourne un peu en rond sur un cas de conversion d'entité insécable dans le cadre d'une transformation XSL (il s'agit d'une transformation d'un XSL en XSL-FO)

J'ai dans le fichier source cette valeur

Code:

---

<th>& # 160 ;</th>

---

(je met ici des espaces entre les caractères car l'éditeur me transforme l'entité en "*")

qui n'est pas reprise dans ma transformation

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<xsl:template match="//th" > <fo:table-cell> <fo:block> <xsl:apply-templates select="*|node()" /> </fo:block> </fo:table-cell> </xsl:template>   <xsl:template match="@*|node()" > <xsl:copy> <xsl:apply-templates select="@*|node()" /> </xsl:copy> </xsl:template>

---

Je me retrouve avec :

Code:

---

<fo:block>(ici un espace)</fo:block>

---

Ca doit être tout bête mais comment conserver l'entité ?

D'avance merci

Hello,

pour information, ce n'est pas une entité. Ça s'appelle une référence de caractère. Une entité a un nom, du genre   . Une référence de caractère n'a qu'un nombre, qui est le code unicode du caractère référencé.

Et ce n'est pas perdu à proprement parler : cette référence de caractère qui représente un espace insécable, a été remplacée dans le document résultant, par un espace insécable, purement et simplement sans référence. Tout comme tu écrirais un a au lieu d'un & # 97 ; le moteur a écrit un espace insécable au lieu d'un & # 160 ;

Et si tu souhaites conserver le fait d'écrire une référence de caractère en lieu et place de l'espace insécable directement, ce n'est pas du tout tout simple, non.
Il te faudrait un moteur qui propose une extension qui fasse ça, comme Saxon.
Sinon si ton moteur gère disable-output-escaping, il y a moyen de faire un template récursif qui détecte les espaces insécables et les écrit sous forme & # 160 ; mais c'est un peu laborieux. Et il faut que le moteur le gère.

Ou enfin, faire un traitement post-XSLT avec un autre programme, qui remplace les espaces insécables natifs par & # 160 ; ce qui peut être fait avec un simple sed sur une invite freenux.

Mais tout cela me semble inutile. Si tu produis du XSL-FO, ce n'est sûrement pas pour en lire le code. C'est plutôt pour le transformer en autre chose, genre un PDF. Dans ce cas l'espace insécable est là et bien là, peu importe que ça ne se remarque pas trop à l’œil nu sans inspecter le code unicode du caractère.

L'entité & # 160; (sans le séparateur d'espace) ou  , qui se dit une référence numérique de caractère, réfère au code point de unicode U+00A0 (NO-BREAK SPACE) est sans ambiguité. Il va se rendre comme une espace en apparence. Mais si on regarde avec un éditeur hex, on verra bien un caractère encodé selon l'encodage instruit du document bien précis.

Par exemple, si on a ceci dans le xslt:

Code:

---

<xsl:output method="xml" version="1.0" encoding="utf-8" omit-xml-declaration="no" indent="yes" />

---

le contendu serait, entre l'élément fo:block

Code:

---

0xC2 0xA0

---

Si on met

Code:

---

<xsl:output method="xml" version="1.0" encoding="iso-8859-1" omit-xml-declaration="no" indent="yes" />

---

le contendu serait, entre l'élément fo:block

Code:

---

0xA0

---

Si on met (par défaut parfois, d'ailleurs)

Code:

---

<xsl:output method="xml" version="1.0" encoding="utf-16" omit-xml-declaration="no" indent="yes" />

---

le contendu serait, entre l'élément fo:block dépend le moteur du système

Code:

---

0x00 0xA0

---

ou

Code:

---

0xA0 0x00

---

Dans le système windows, plus probablement on va voir le dernier et dans *nix, le premier, avec l'information bom au début du document sortant.

Voilà! Est-ce que ça a répondu à la question ?

Merci à tous les 2 pour ces réponses. C'est très clair effectivement. La non conservation textuelle de la référence de caractère m'embêtait mais effectivement si il n'y a pas d'impact dans la production du PDF et conserve l'espace insécable c'est l'essentiel. Et si besoin j'utiliserai sed comme suggéré.