[Woodstox] Invalid UTF-8 start byte 0x68

Version imprimable

29/06/2012, 12h53
Jimmy_

[Woodstox] Invalid UTF-8 start byte 0x68

Bonjour,

Je suis en train de parser un fichier avec Woodstox et je rencontre le soucis suivant :

com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x68 (at char #859, byte #-1)

Je n'arrive pas à interpréter le message : je comprend bien que j'ai un soucis de codage UTF-8.

Pour moi j'ai un UTF-8 qui commence par le byte 0x68 et qui au caractère position 859 contient la valeur -1 ? Mais je ne comprend pas comment c'est possible.

Est-ce que quelqu'un peut m'expliquer ce message , d'avance merci.
29/06/2012, 13h09
thelvin

Non, il contient la valeur 0x68. Je ne comprends pas ce que signifie byte #-1, ça m'a l'air mal fichu comme message.

Mais c'est pas grave, le reste est clair : il y a dans ton XML des octets qui ne forment pas du utf-8 correct. Apparemment au 859e caractère.
Tu n'as plus qu'à aller regarder.
Un éditeur hexa peut aider.

Merci pour la réponse,

Non pas de soucis de fichier, il est bien en UTF-8.

J'ai trouvé la signification du -1, c'est la position du byte à décoder.

Code:

1
2
3
4
5
6
com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x68 (at char #859, byte #-1)
                at com.ctc.wstx.sr.StreamScanner.constructFromIOE(StreamScanner.java:626)
                at com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:999)
                at com.ctc.wstx.sr.StreamScanner.getNext(StreamScanner.java:756)
                at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:1980)
                at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1117)

Or ça n'a pas de sens dans :

Code:

1
2
3
4
5
6
7
8
9
10
11
 private void reportInvalidInitial(int mask, int offset)
        throws IOException
    {
        // input (byte) ptr has been advanced by one, by now:
        int bytePos = mByteCount + mBytePtr - 1;
        int charPos = mCharCount + offset + 1;
 
        throw new CharConversionException("Invalid UTF-8 start byte 0x"
                                          +Integer.toHexString(mask)
                                          +" (at char #"+charPos+", byte #"+bytePos+")");
    }

Le mByteCount et le mBytePtr à 0 est impossible il me semble, mByteCount vaut au moins 2 sinon pas la peine de le décoder.

Comme la JVM est un peu spéciale et qu'avec la version d'avant ça marchait, on penche pour un soucis d'allocation mémoire.

29/06/2012, 15h47
thelvin

Hum. Moi je vérifierais quand même :

- Si absolument tout le fichier est bien en utf-8 correct. (Peut-être que si ça marchait avant, c'est parce que seul ce fichier-là a un problème, et que les autres n'en avaient pas ?)
- Quel est l'état véritable des variables du parseur/décodeur, avec un breakpoint. Au lieu de supposer des trucs.

Mais bon, si c'est une JVM custom et qu'il peut y avoir des inconsistances de mémoire (ou une JVM normale et des threads qui provoquent une inconsistance mémoire,) on peut tout supposer, c'est sûr. 'Faudrait nous parler des nouvelles règles à respecter pour cette JVM.
29/06/2012, 16h15
Jimmy_

Ca plante sur le mot é c h é a n c e :

Ca donne :

00E9 0063 0068 00E9 0061 006E 0063 0065
-----------------^

Ca plante là, ce qui est étonnant c'est d'avoir encore précisément le 68 dans le buffer au lieu du 00E9. Par contre je ne contrôle pas l'API Woodstock ni la JVM IBM, pas de trace possible.

On va passer sur la version d'avant je pense.
29/06/2012, 16h27
thelvin

Hum, effectivement on peut se demander ce qui lui prend de planter là et de donner ce message d'erreur.

Enfin, je me demande, le dump hexa que tu nous as montré, là, c'est des octets ou c'est des caractères ?
Parce que si c'est des octets, c'est pas de l'utf-8, ton truc. Mais alors il devrait planter sur le premier é, pas le second.

Citation:

Par contre je ne contrôle pas l'API Woodstock ni la JVM IBM, pas de trace possible.

Bien pour ça que j'ai parlé de breakpoints, pas de traces.
Et puis bon, pour la JVM encore, je dis pas, mais l'API Woodstock est open source. Si vraiment ça pouvait aider de mettre des traces, ce ne serait pas bien compliqué.

Citation:

On va passer sur la version d'avant je pense.

Je suis assez curieux des résultats, pour être honnête.
29/06/2012, 16h40
Jimmy_

Citation:

Envoyé par thelvin

Hum, effectivement on peut se demander ce qui lui prend de planter là et de donner ce message d'erreur.

Enfin, je me demande, le dump hexa que tu nous as montré, là, c'est des octets ou c'est des caractères ?
Parce que si c'est des octets, c'est pas de l'utf-8, ton truc. Mais alors il devrait planter sur le premier é, pas le second.

C'est le fichier sous ultra edit au format hexa donc c'est les caractères lu depuis un fichier en UTF-8.

Mais c'est bien de l'UTF-8, j'arrive à la parser avec un parser SAX sans soucis, mais pas sur cette JVM.

Je vous tiendrai au courant de toute façon, ça intrigue pas mal de monde.
29/06/2012, 17h13
thelvin

Citation:

Envoyé par Jimmy_

C'est le fichier sous ultra edit au format hexa donc c'est les caractères lu depuis un fichier en UTF-8.

Mais c'est bien de l'UTF-8, j'arrive à la parser avec un parser SAX sans soucis, mais pas sur cette JVM.

Je n'ai pas UltraEdit et il n'est pas gratuit, alors je ne sais pas trop ce que tu nous as montré au juste.

Mais si c'est un dump normal d'octets hexadécimaux, alors ceci n'est pas de l'utf-8. Le é ne se code pas E9 en utf-8, il se code C3 A9. De toute façon, c'est évident, 8 caractères avec des accents prennent forcément plus de 8 octets en utf-8.

Quant à pourquoi ça passerait avec un parseur SAX, on peut imaginer plein de raisons.
03/07/2012, 14h26
bblpsv

Je rencontre le même problème

Bonjour,
Sur quel système rencontrez-vous ce problème?
Je rencontre le même problème depuis que le système a été upgradé de SR8 à SR9 FP2.

?Une adaptation de woodstox serait t'elle la meilleure solution?
? Woodstox aurat t'il un meilleur comportement avec SR10?

Cdlt,