pourquoi ne xslt sortie encoding=utf-8 ne pas convertir iso-8859-1 personnage?

Pourquoi est iso-8859-1 personnage n'est pas converti en utf-8 dans le fichier de sortie lorsque le paramètre de sortie de l'encodage utf-8?

J'ai un fichier d'entrée xml en iso-8859-1 codage, et l'encodage est déclaré. Je veux un fichier de sortie au format utf-8. Ma compréhension est que le réglage de la sortie de l'encodage dans le fichier xslt doit gérer la conversion de caractères.

Est ma compréhension de mal? Si non, pourquoi ne le test simple suivant cas de sortie d'un iso-8859-1 en utf-8 déclarée fichier de sortie?

Mon fichier d'entrée ressemble à ceci:

<?xml version="1.0" encoding="ISO-8859-1"?>
<data>ö</data>

Mon transformer ressemble à ceci:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>
    <xsl:output encoding="UTF-8" />
    <xsl:template match="/">
        <result>
            <xsl:value-of select="." />
        </result>
    </xsl:template>
</xsl:stylesheet>

À l'aide de saxon9he à partir de la ligne de commande de mon résultat ressemble à ceci:

<?xml version="1.0" encoding="UTF-8"?>
<result>ö</result>

... Dans mon fichier résultat est 0xF6 selon BabelPad, qui est un invalide de caractères utf-8. Le ö semble être épargnée par la transformation.

Merci pour toute aide!

Je suppose que vous êtes en utilisant une bibliothèque de processus de la XLST transformations. En fournissant cette bibliothèque, et le code qui les interfaces avec elle, peut être utile. C'est peut-être un paramètre de la bibliothèque.
Ce qui vous fait penser que ö n'est pas valide de caractères UTF-8?
vous êtes victime d'une erreur de niveau. UTF-8 n'est pas un ensemble de caractères mais un encodage de caractères dans le Universal Character Set (UCS) défini par Unicode et ISO 10646. L'OP n'est pas en disant ö n'est pas un caractère, mais que xF6 n'est pas un UTF-8 codage de qui ou de n'importe quel caractère. En cela, l'OP est tout à fait correct.
Fwiw, je m'attends à tout processeur XSLT à se comporter comme vous le dites vous attendre. Et étant donné que vous êtes en utilisant Saxon, mon premier réflexe est de se demander: êtes-vous sûr que ni BabelPad ou quoi que ce soit d'autre est de jouer avec l'encodage des caractères après Saxon émet-il? Je ne suis pas familier avec BabelPad - êtes-vous sûr que vous êtes à interpréter ce qu'elle vous dit??? Ce n'hexdump dire? (Quand je lance Saxon-IL sur votre entrée, hexdump me dit ... est F6 dans l'entrée et la C3 B6 dans la sortie.)
Veuillez utiliser un navigateur (Google Chrome) pour ouvrir la fraîche fichier xml... ne vous obtenez une erreur xml? Si BabelPad est à droite, vous devriez voir error on line 2 at column 9: Encoding error

OriginalL'auteur user1981490 | 2013-02-08

  1. 5

    Je vois deux explications possibles (la pensée, il y a probablement d'autres).

    (a) l'étape finale de la sérialisation, c'est la conversion de caractères d'octets, n'est pas effectuée par le processeur XSLT, mais par un autre morceau de logiciel qui n'a pas accès à la feuille de style. Ce serait le cas, par exemple, si vous exécutez la transformation dans une application Java qui envoie la sortie d'un Écrivain plutôt qu'un OutputStream de l'Écrivain serait de convertir les caractères d'octets à l'aide de la plate-forme de codage par défaut, ce qui est probablement la norme iso-8859-1.

    (b) les octets que vous voyez dans votre écran ne sont pas les octets stockés sur le disque, mais une transformation quelconque d'entre eux. Cela peut se produire lorsque vous chargez un fichier dans un éditeur et ensuite demander un hex d'affichage; dans certains cas, vous obtiendrez un hex d'affichage de l'éditeur de la représentation en mémoire du document, et non de ce qui est stocké sur le disque.

    L'affaire a été b. J'ai été voir une représentation du point de code F6 et non pas la valeur de bit (encodage). L'encodage dans la transformation a bien fonctionné. Merci à tous pour votre aide!

    OriginalL'auteur Michael Kay