octet invalide 2 de la séquence de codage UTF-8 4 octets durant le document analyse syntaxique

Question

J'essaie d'analyser un document à partir d'octets comme suit

String result = /* some valid xml document */ 
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); 
DocumentBuilder parser = factory.newDocumentBuilder(); 
try { 
    Document document = parser.parse(new ByteArrayInputStream(result.getBytes())); 
} catch (MalformedByteSequenceException e) { 
    System.out.println("(MalformedByteSequenceException) " + e.getMessage()); 
} 

A MalformedByteSequenceException est jeté et la suivante est imprimée dans la console

"(MalformedByteSequenceException) Invalid byte 2 of 4-byte UTF-8 sequence." 

la chose étrange est que le même code fonctionne dans mon environnement local (Windows 10), mais pas dans l'environnement à distance (Windows Server 2012)

j'ai essayé de reproduire le err ou dans mon environnement local changeant la version de TomEE, de 1.7.4 à 1.7.1, j'ai essayé de changer le JRE de 1.7.0_80 à 1.7.0, j'ai essayé de copier le dossier entier de Tomee du système à distance à ma machine locale, toujours le erreur se produit uniquement dans l'environnement distant

L'utilisation de result.getBytes(Charset.forName("UTF-8")) au lieu de result.getBytes() ne fonctionnait pas non plus.

Answer 1

J'ai trouvé une solution. Réglez ce au début de setenv.bat,

rem Set encoding 
set JAVA_OPTS=%JAVA_OPTS% -Dfile.encoding=UTF-8 

Je ne suis pas sûr de la raison d'être, mais semble que la machine virtuelle Java utilise un peu bizarre encodage Windows au lieu de l'UTF-8 que vous avez besoin

Answer 2

Appeler String.getBytes() est exactement le même que d'appeler String.getBytes("<value of file.encoding>").

Cependant, il n'est pas nécessaire d'appeler cela du tout. Appelez parse avec un InputSource mis en place sur un StringReader.