Das Verhalten dieser Methode hat sich in Java 8 geändert. Ich brauche eine schnelle Lösung für mein Problem.
Das Problem ist, dass ich einen Code habe, der CR und LF nach jedem XML-Knoten namens <row> schreibt. Jetzt (wie wir zu Java 8 migriert haben) werden die Zeichen 
 anstelle von CR und LF ausgegeben.
Noch einmal, ich brauche eine schnelle Lösung, ich kann die StaX-Implementierung nicht ändern oder so etwas Großes machen.
%Vor% Sie müssen Zugriff auf den zugrunde liegenden Writer haben, der den Writer darstellt, den Sie mit dem XMLStreamWriter dekoriert haben (hoffentlich, wenn es einen Writer gibt, den Sie in createXMLStreamWriter() übergeben haben) oder Sie müssen das Deployment vorübergehend deaktivieren .
Der Grund für die seltsamen Zeichen ist, dass der XMLStreamWriter keine Ahnung hat, wo Sie diese Zeichen schreiben, so dass er standardmäßig XML-Attribut-Escaping, das strenger ist als das Element (Inhalt), das es gibt . Das Escaping basiert in der Regel auch auf CharacterEncoder . Meine Vermutung ist, dass in älteren Versionen von Java der XML-Element-Escaping standardmäßig fehlte, der nicht in Leerraum wie Zeilenumbrüche mündete oder eine andere Zeichencodierung verwendet wurde. Ich kann sehen, warum sie dies behoben haben, denn eindeutig ist das Entkommen von Attributen der richtige Weg, dies zu tun. Ich habe auch keine Ahnung, welche XMLStreamWriter oder CharacterEncoder Sie tatsächlich verwenden und wahrscheinlich, was wahrscheinlicher passiert ist, dass die standardmäßige XMLStreamWriter oder Zeichencodierungsimplementierung geändert hat (Sie sollten im Debugger überprüfen, welche ausgewählt wird).
Unabhängig davon, ob Sie Zugriff auf den zugrunde liegenden Writer erhalten, können Sie die Zeichen einfach direkt schreiben und sie werden nicht maskiert. Stellen Sie jedoch sicher, dass der Schreiber, den Sie verwenden, derjenige ist, der dekoriert ist und nicht einen tiefer (wenn Sie beispielsweise einen BufferWriter haben, der einen FileWriter schmückt, verwenden Sie den BufferWriter).
Für diejenigen, die nicht denken writeCharacters entkommt, Sie können sich den Code ansehen .
BEARBEITEN
Offenbar, nachdem du dir den Code angesehen hast, kannst du writer.setEscapeCharacters(false) auf dem Standard-Sun-Impl aufrufen (leider musst du wahrscheinlich ein Casting machen), bevor du writeCharacters aufruft, was wahrscheinlich besser ist, als den ursprünglichen Writer zu bekommen.
Ich wusste nichts von dieser Flagge.
BEARBEITEN 2
Eine weitere mögliche schnelle Lösung, wenn Sie hoffentlich die Sun StaX-Implementierung verwenden, ist das Ändern der Zeichencodierung auf Systemebene und das Auswählen einer Codierung, sodass die CRLF im Idealfall nicht vor dem JDK-Upgrade geschützt wird. Dies ist davon auszugehen, dass die Zeichencodierung von Windows oder ISO in UTF-8 beim Java-Upgrade geändert wurde, aber ich kann nicht sicher sein, da Sie Ihr Betriebssystem nicht angegeben haben. Wenn es sich beim Upgrade nicht geändert hat (dh, Sie haben hoffentlich immer auf UTF-8 gesetzt), ignorieren Sie diese Option.
EDIT 3
Nachdem ich einige Tests durchgeführt habe, bin ich mir ziemlich sicher, dass Ihre StaX-Implementierung nicht die Standard-Java-Sun-Implementierung ist, sondern Woodstox . Woodstox . Ich habe Woodstox nicht getestet, aber es scheint, dass die Bibliothek sich aus Performance-Gründen ziemlich viel um Whitespaces kümmert und anscheinend unterschiedliche Regeln hat, wenn sie UTF-8 und ISO (wieder Zeichencodierung) verwenden.
Was ich getan habe, war, einfach die folgende Methode aufzurufen.
writer.writeCharacters(System.lineSeparator());
Das funktioniert einwandfrei und erzeugte RAW- (und nicht XML-maskierte) CR / LF-Daten.
Außerdem stellte sich heraus, dass ich mein Problem mit Linux hatte, während es unter Windows funktionierte.