Transformator.setOutputProperty(OutputKeys.ENCODING, "UTF-8") funktioniert NICHT

Habe ich die folgende Methode schreiben, die ein XMLDom zu einem stream:

public void writeToOutputStream(Document fDoc, OutputStream out) throws Exception {
    fDoc.setXmlStandalone(true);
    DOMSource docSource = new DOMSource(fDoc);
    Transformer transformer = TransformerFactory.newInstance().newTransformer();
    transformer.setOutputProperty(OutputKeys.METHOD, "xml");
    transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8");
    transformer.setOutputProperty(OutputKeys.INDENT, "no");
    transformer.transform(docSource, new StreamResult(out));
}

Teste ich einige andere XML-Funktionen, und dies ist nur die Methode, die ich verwenden, um eine Datei zu schreiben. Mein test-Programm erzeugt 33 test-Fälle, in denen Dateien geschrieben werden. 28 von Ihnen haben den folgenden header:

<?xml version="1.0" encoding="UTF-8"?>...

Aber für einige Grund, 1 der Testfälle erzeugen jetzt:

<?xml version="1.0" encoding="ISO-8859-1"?>...

Vier weitere zu produzieren:

<?xml version="1.0" encoding="Windows-1252"?>...

Wie Sie deutlich sehen können, ich bin Einstellung der ZEICHENCODIERUNG Ausgabe-Taste, um UTF-8. Diese tests verwendet, um die Arbeit auf eine frühere Java-version. Ich habe nicht die tests ausführen, die in eine Weile (mehr als ein Jahr) aber läuft heute auf "Java(TM) SE Runtime Environment (build 1.6.0_22-b04)" ich bekomme dieses komische Verhalten.

Habe ich festgestellt, dass die Dokumente, die das problem verursacht wurden, Lesen aus Dateien, die Sie ursprünglich hatten diese Codierung. Es scheint, dass die neuen Versionen der Bibliotheken, die versuchen zu bewahren, Sie die Kodierung der Quelldatei gelesen wurde. Aber das ist nicht das, was ich will ... ich will wirklich die Ausgabe in UTF-8.

Kennt jemand eine andere Faktor, der möglicherweise den Transformator zu ignorieren, die UTF-8-Kodierung einstellen? Gibt es etwas anderes, das gesetzt werden muss, um auf das Dokument zu sagen, zu vergessen, die Codierung der Datei, die ursprünglich gelesen?

UPDATE:

Ich habe das gleiche Projekt auf einem anderen Rechner gebaut und ran an die tests dort. Auf dieser Maschine alle tests übergeben! Alle Dateien mit "UTF-8" im header. Diese Maschine hat "Java(TM) SE Runtime Environment (build 1.6.0_29-b11)" Beide Maschinen unter Windows 7. Auf dem neuen Computer, der ordnungsgemäß funktioniert, jdk1.5.0_11 verwendet wird, um die zu bauen, aber auf dem alten Rechner jdk1.6.0_26 verwendet wird, um die zu bauen. Die Bibliothek für beide builds sind exakt die gleichen. Kann es sein das JDK 1.6 Inkompatibilität mit 1.5 zu erstellen?

UPDATE:

Nach 4,5 Jahren, die Java-Bibliothek ist immer noch gebrochen, aber aufgrund der Anregung durch Vyrx unten, habe ich endlich eine richtige Lösung!

public void writeToOutputStream(Document fDoc, OutputStream out) throws Exception {
    fDoc.setXmlStandalone(true);
    DOMSource docSource = new DOMSource(fDoc);
    Transformer transformer = TransformerFactory.newInstance().newTransformer();
    transformer.setOutputProperty(OutputKeys.METHOD, "xml");
    transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8");
    transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes");
    transformer.setOutputProperty(OutputKeys.INDENT, "no");
    out.write("<?xml version=\"1.0\" encoding=\"UTF-8\"?>".getBytes("UTF-8"));
    transformer.transform(docSource, new StreamResult(out));
}

Die Lösung ist das deaktivieren der Schrift der Kopfzeile, und schreiben Sie die richtigen header, nur vor dem serialisieren der XML-Ausgabe Dampf. Lame, aber es erzeugt die richtigen Ergebnisse. Tests kaputt über 4 Jahren laufen nun wieder!

Diese tatsächlich Aussehen einige bug oder eine Inkompatibilität problem. Es ist unwahrscheinlich, dass jemand helfen kann, ohne einen reproduzierbaren testcase. Können Sie eine SSCCE, und eine Liste mit allen Versionen der tools/Bibliotheken?
Es gibt mehrere Orte, um zu überprüfen, die für Ihr Gebietsschema. Ihre lokalen computer ein Gebietsschema, die IDE haben könnte ein Gebietsschema, und Ihre JVM-Prozess hat ein Gebietsschema. Ich habe gesehen, Probleme wie diese vor, wenn mein Locales verändert wurden. Wie sind Sie mit der Ausführung der tests? java.exe, maven, IDE?
Ich habe wie angegeben UTF-8 direkt, das Gebietsschema, sollte keine Rolle spielen, aber zur Beantwortung Ihrer Frage direkt, den test-code aufgerufen wird, wird als Kommandozeilen-Aufruf Java.exe auf einem windows-system, das sich auf der Pazifischen Küste der USA, und konfiguriert für Englisch (USA) und Pacific-Zeitzone.
Sollten Sie SSCCE. Sonst niemand kann Ihr problem reproduzieren, weder eine Antwort geben.
können Sie überprüfen, wie ist der Ausgabestrom angelegt ?

InformationsquelleAutor AgilePro | 2013-03-23

1

Ich hatte das gleiche problem auf Android beim serialisieren von emoji-Zeichen. Bei der Verwendung von UTF-8-Codierung in der Transformator wurde die Ausgabe von HTML Zeichen-Entitäten (UTF-16-Ersatzzeichen Paare), die später brechen andere Parser, der die Daten zu Lesen.

Dies ist, wie ich landete Lösung:
```
StringWriter sw = new StringWriter();
sw.write("<?xml version=\"1.0\" encoding=\"UTF-8\" ?>");
Transformer t = TransformerFactory.newInstance().newTransformer();

//this will work because we are creating a Java string, not writing to an output
t.setOutputProperty(OutputKeys.ENCODING, "UTF-16"); 
t.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes");
t.transform(new DOMSource(elementNode), new StreamResult(sw));

return IOUtils.toInputStream(sw.toString(), Charset.forName("UTF-8"));
```
Ja, das sieht aus wie es funktioniert. Ich bin KEIN fan von der Umstellung meiner gesamten XML-Baum in einen string im Speicher (vor allem in Anbetracht dessen, dass StringWriter ist nicht effizient). Ich wirklich darauf bestehen, das streaming direkt auf den Ausgang. Eine mögliche Lösung ist, statt das hinzufügen der Kopfzeile nach der Serialisierung zu schreiben, die header zu den output-stream VOR dem serialisieren der XML ohne header, um den gleichen output-stream. Ich werde sehen, ob das funktioniert.
Ich habe umgeschrieben, diese Idee richtig verwenden, Bäche und geben Sie den Kredit für die Antwort. (vielen Dank!) Wie du geschrieben hätten, hätten Sie drei Kopien des Dokuments im Speicher an der gleichen Zeit. Für kleine XML kein problem, aber in der Regel mit drei Kopien von wichtigen Daten-Datei im Speicher ist nicht effizient. Ein besserer Ansatz ist, einfach mal den header vor dem serialisieren der XML-writer. Ich schrieb Ihre Antwort zu machen, nur 2 Kopien der XML-Datei in Speicher.

InformationsquelleAutor Vyrx

Zur Beantwortung der Frage folgende code funktioniert für mich. Dieser kann in Eingabe-Codierung und konvertieren Sie die Daten in der Ausgabe-Kodierung.

        ByteArrayInputStream inStreamXMLElement = new ByteArrayInputStream(strXMLElement.getBytes(input_encoding));
        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
        DocumentBuilder db = dbf.newDocumentBuilder(); 
        Document docRepeat = db.parse(new InputSource(new InputStreamReader(inStreamXMLElement, input_encoding)));
        Node elementNode = docRepeat.getElementsByTagName(strRepeat).item(0);

        TransformerFactory tFactory = null;
        Transformer transformer = null;
        DOMSource domSourceRepeat = new DOMSource(elementNode);
        tFactory = TransformerFactory.newInstance();
        transformer = tFactory.newTransformer();
        transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes");
        transformer.setOutputProperty(OutputKeys.ENCODING, output_encoding);

        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        StreamResult sr = new StreamResult(new OutputStreamWriter(bos, output_encoding));


        transformer.transform(domSourceRepeat, sr);
        byte[] outputBytes = bos.toByteArray();
        strRepeatString = new String(outputBytes, output_encoding);

Der Fehler tritt nur bei einigen Versionen von Java. Ich hatte nicht die Zeit, um führen Sie eine vollständige Untersuchung, was genau Umgebung die das problem verursacht, noch nicht einmal die Zeit, um nach den test-code hier, aber es ist im wesentlichen ähnlich zu dem, was Sie veröffentlichen. Was war ein Fehlschlag war, automatisierte tests laufen hatte für die Jahre. Der code, den Sie enthalten, sieht aus wie ein gutes Beispiel dafür, wie test für das problem. Ich weiß nicht, ob ich in der Lage sein zu gehen zurück zu der ursprünglichen Umgebung, die scheiterte und re-führen Sie die tests dort. Alle, in der fülle der Zeit...

InformationsquelleAutor Ramesh Reddy

1

Hab ich verbrachte viel viel Zeit zum Debuggen dieses Thema, weil es funktioniert gut auf meinem Rechner (Ubuntu 14 + Java 1.8.0_45), war aber nicht richtig arbeiten in der Produktion (Alpine Linux + Java 1.7).

Entgegen meiner Erwartung folgt aus der oben genannten Antwort nicht helfen.
```
ByteArrayOutputStream bos = new ByteArrayOutputStream();
StreamResult sr = new StreamResult(new OutputStreamWriter(bos, "UTF-8"));
```
aber diese funktionierte wie erwartet
```
val out = new StringWriter()
val result = new StreamResult(out)
```
InformationsquelleAutor expert

was?:

public static String documentToString(Document doc) throws Exception{ return(documentToString(doc,"UTF-8")); }//
   public static String documentToString(Document doc, String encoding) throws Exception{
     TransformerFactory transformerFactory =TransformerFactory.newInstance();
     Transformer transformer = null;

if ( "".equals(validateNullString(encoding) ) ) encoding = "UTF-8";
try{
    transformer = transformerFactory.newTransformer();
    transformer.setOutputProperty(OutputKeys.INDENT, "yes") ;
    transformer.setOutputProperty(OutputKeys.ENCODING, encoding) ;
}catch (javax.xml.transform.TransformerConfigurationException error){
    return null;
}

Source source = new DOMSource(doc);    
StringWriter writer = new StringWriter();
Result result = new StreamResult(writer);

try{
    transformer.transform(source,result);
}catch (javax.xml.transform.TransformerException error){
    return null;
}
return writer.toString();    
}//documentToString

InformationsquelleAutor Kintan K

0

Konnte ich das problem umgehen, indem er das Document-Objekt übergeben, um die DOMSource Konstruktor. Die Methode getXmlEncoding meiner wrapper-gibt immer null, alle anderen Methoden sind Delegierte an der eingebundenen Dokument-Objekt.

InformationsquelleAutor Andreas Flueckiger
-1

Ich bin dabei, ein wilder Schuss hier, aber Sie erwähnen, dass Sie das Lesen von Dateien für die Daten der tests.
Können Sie sicherstellen, dass Sie die Dateien Lesen, die mit der richtigen Codierung, so dass, wenn Sie schreiben in Ihren Ausgabestrom haben Sie bereits die Daten in der richtigen Codierung?

So etwas wie new InputStreamReader(new FileInputStream(fileDir), "UTF8").

Vergessen Sie nicht, dass single-argument Konstruktoren von FileReader verwenden Sie immer die Plattform-default-encoding : Die Konstruktoren dieser Klasse davon ausgegangen, dass die Standard-Zeichenkodierung und die Standard-byte-Puffer-Größe angemessen sind.

Ich benutze nie den FileReader. --- DOM "Dokument" verwendet Zeichenfolge-Werte, das heißt, Sie haben bereits umgestellt von Ihrer ursprünglichen form. Ich bin mit der Java-DOM-utilities zum Lesen der Datei direkt aus dem byte-stream. Der stream wird voraussichtlich interpretiert werden, die gemäß dem XML-header, der angibt, Codierung. Dies ist, wie XML funktioniert. --- Die Datei scheint korrekt gelesen werden, und geschrieben ist es in der angegebenen Codierung-nur nicht die Codierung, die ich beantragt, dass das schreiben in.

InformationsquelleAutor Carlos
-1

Versuchen Sie, die Codierung auf Ihre StreamResult speziell:
```
StreamResult result = new StreamResult(new OutputStreamWriter(out, "UTF-8"));
```
So, sollte es nur in der Lage sein zu schreiben, die in UTF-8.

Das problem ist, dass der 'header' ist falsch. Wenn der header sagt, dass es ISO-8859-1, dann würde ich nicht wollen, dass es tatsächlich codiert in irgendeiner anderen Art und Weise. Ich brauche sowohl den header und die eigentliche Codierung des Streams. Das ist, warum mit diesen Bibliotheken, die ich immer verwenden-input - /output-streams und keine reader/writer ... weil der standard sagt, dass Sie zum Lesen des headers, um herauszufinden, was die Codierung ist.

InformationsquelleAutor Steve K

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.