transformer.setOutputProperty (OutputKeys.ENCODING, "UTF-8") non funziona

Question

ho il seguente metodo di scrivere un XMLDOM ad un flusso:

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)); 
} 

sto testando alcune altre funzionalità XML, e questo è solo il metodo che uso per scrivere su un file. Il mio programma di test genera 33 casi di test in cui i file sono scritti. 28 di loro hanno la seguente intestazione:

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

Ma per qualche ragione, 1 dei casi di test ora producono:

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

E altri quattro prodotti:

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

come si può vedere chiaramente, sto impostando la chiave di uscita ENCODING su UTF-8. Questi test utilizzati per lavorare su una versione precedente di Java. Non ho eseguito i test in un istante (più di un anno) ma in esecuzione oggi su "Java (TM) SE Runtime Environment (build 1.6.0_22-b04)" Ho questo comportamento divertente.

Ho verificato che i documenti che causano il problema sono stati letti da file che in origine erano codificati. Sembra che le nuove versioni delle librerie stiano tentando di preservare la codifica del file sorgente che è stato letto. Ma non è quello che voglio ... Voglio davvero che l'output sia in UTF-8.

Qualcuno sa di altri fattori che potrebbero impedire al trasformatore di ignorare le impostazioni di codifica UTF-8? C'è qualcos'altro che deve essere impostato sul documento per dire di dimenticare la codifica del file che è stato letto in origine?

UPDATE:

ho verificato lo stesso progetto su un'altra macchina, costruito e ha eseguito i test lì. Su quella macchina passano tutti i test! Tutti i file hanno "UTF-8" nella loro intestazione. Quella macchina ha "Java (TM) SE Runtime Environment (build 1.6.0_29-b11)" Entrambe le macchine eseguono Windows 7. Sulla nuova macchina che funziona correttamente, jdk1.5.0_11 viene utilizzato per creare la build, ma sul vecchio la macchina jdk1.6.0_26 viene utilizzata per creare la build. Le librerie utilizzate per entrambe le build sono esattamente le stesse. Può essere una incompatibilità JDK 1.6 con 1.5 al momento della compilazione?

UPDATE:

Dopo 4,5 anni, la libreria Java è ancora rotto, ma a causa del suggerimento di Vyrx di seguito, ho finalmente avere una soluzione adeguata!

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)); 
} 

La soluzione è quella di disabilitare la scrittura dell'intestazione, e scrivere l'intestazione corretta prima serializzazione XML per il vapore in uscita. Lame, ma produce i risultati corretti. I test interrotti più di 4 anni fa sono di nuovo in esecuzione!

Answer 1

Ho avuto lo stesso problema su Android durante la serializzazione di caratteri emoji. Quando si utilizza la codifica UTF-8 nel trasformatore, l'output era costituito da entità carattere HTML (coppie di surrogati UTF-16), che successivamente avrebbero interrotto altri parser che leggevano i dati.

Questo è come ho finito per risolverlo:

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")); 

Answer 2

Qui sto prendendo una foto selvaggia, ma lei dice che stai leggendo i file per i dati dei test. Puoi assicurarti di leggere i file usando la codifica corretta, quindi quando scrivi in ​​OutputStream hai già i dati nella codifica corretta?

Quindi avere qualcosa come nuovo InputStreamReader (nuovo FileInputStream (fileDir), "UTF8").

Non dimenticate che i costruttori singolo argomento FileReader usano sempre la codifica piattaforma predefinita: The constructors of this class assume that the default character encoding and the default byte-buffer size are appropriate.

Answer 3

di rispondere alla domanda seguente codice funziona per me. Ciò può richiedere la codifica dell'input e convertire i dati in codifica di output.

 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); 

Answer 4

provare a impostare la codifica sul StreamResult particolare:

StreamResult result = new StreamResult(new OutputStreamWriter(out, "UTF-8")); 

In questo modo, dovrebbe essere solo in grado di scrivere in UTF-8.

Answer 5

che dire ?:

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 

Answer 6

Ho passato notevole quantità di tempo di debug questo problema perché stava lavorando bene sulla mia macchina (Ubuntu 14 + Java 1.8.0_45), ma non funzionava correttamente in produzione (Alpine Linux + Java 1.7).

Contrariamente alle mie aspettative in seguito alla risposta di cui sopra non ha aiutato.

ByteArrayOutputStream bos = new ByteArrayOutputStream(); 
StreamResult sr = new StreamResult(new OutputStreamWriter(bos, "UTF-8")); 

ma questo ha funzionato come previsto

val out = new StringWriter() 
val result = new StreamResult(out) 

Answer 7

potrei aggirare il problema avvolgendo l'oggetto Document passato al costruttore DOMSource. Il metodo getXmlEncoding del mio wrapper restituisce sempre null, tutti gli altri metodi sono delegati all'oggetto Document avvolto.