XMLStreamWriter Escape bei Sonderzeichen

[Guest_asking]

Hallo alle zusammen,
Ich habe folgendes Problem, unzwar möchte ich mit einem XMLStreamWriter eine XML-Datei erstellen, funktioniert auch alles wunderbar ausser das ich bei

writer.writeEmptyElement("element");
					writer.writeAttribute("value", "a < b");

das problem habe das ich in der XML-Datei statt a < b a&lt;b stehen habe.
Danke im Voraus für jede Hilfe.

 

[Gast2]

XMLStreamWriter writeCharacters without escaping - Stack Overflow

 

[SlaterB]

@Guest
ist dir schon einmal aufgefallen, dass XML etwa so aussieht:

<tag>  a < b  </tag>

da willst du wirklich ein einzelnes < drin stehen haben? wie sollen so Tags mit <> richtig erkannt werden?

 

[Gast2]

Mit CDATA geht das schon, aber schön ist es nicht.

 

[Guest_asking]

Ich möchte das in der XML-Datei so stehen haben:
<element value="a<b"/> und das ist valides XML. Geht das nicht ohne writeCData?

 

[Gast2]

Geht das nicht ohne writeCData?

Nein.

 

[SlaterB]

hmm, dann war mein Kommentar ja nicht so hilfreich, im Attribut könnte es wohl gehen, ja

ich kann noch folgende Taktik vorschlagen:
wozu sich auf unbekannte Klassen wie XMLStreamWriter verlassen?
eine Txt-Datei mit Tags und Klartext kann man doch wirklich auch mit wenig Code selber erstellen,

ich benutze eine Fortsetzung von Ansätzen wie
XML Document Writer : WriterXMLJava

und dort sieht es so aus, als wenn das < auch in Attributen ersetzt wird, aber man kann genau den Aufruf erkennen,
und für Attribute auf Wunsch eben nicht fixup() verwenden oder der Methode einen boolean-Parameter geben damit zumindest Anführungszeichen korrigiert werden

XMLDocumentWriter arbeitet mit dom.Document, für deine Aufrufe müsste das sicher ganz anders aussehen,
oder du baust deinen Code so um, dass es einen XML-Baum in Java zusammenstellt, der am Ende dann geschrieben wird

 

[Gast2]

Das geht aber auch nur in Attributen da die schon als CDATA deklariert sind:
Extensible Markup Language (XML) 1.0 (Fifth Edition)
Somit sollte schon [c]writeCData()[/c] der richtige Weg sein.

 

[Guest_asking]

Also das mit CData ist nicht das wonach ich gesucht habe und einen anderen writer kann ich nicht benutzen. Gibt es denn keine andere Möglichkeit. Mit writeCData sieht es danach so aus und muss nebenbei noch nach dem letzten attribut kommen weil wenn es zwischen anderen writeattribute methoden ist kann es zu keinem element zugeordnet werden:
<![CDATA[
value="a<b"]]> und so sieht das besch..eiden aus

 

[Guest_asking]

Oh Man, hat denn niemand eine Idee??

 

[SlaterB]

API sagt

The XMLStreamWriter does not perform well formedness checking on its input.
However the writeCharacters method is required to escape & , < and >
For attribute values the writeAttribute method will escape the above characters plus " to ensure that all character content and attribute values are well formed.

die Klasse an sich bietet keine Möglichkeit das zu ändern, wird garantiert so agieren,
dir bleiben als Möglichkeiten:
- XMLStreamWriter durch Subklasse modifizieren
- dann sehe ich aber nicht ein, warum du nicht gleich einen anderen Writer verwendest
- das erzeugte Result im Nachhinein zu modifizieren, im Grunde auch nicht viel 'sauberer'

dogmatisches 'einen anderen writer kann ich nicht benutzen' passt eben nicht zu 'ich will ein anderes Ergebnis haben'

 

[Cage Hunter]

Noch ne Möglichkeit : Bau das Modell um...
<element value="a" smallerThan="b">
oder sowas in der Richtung
Ich denke, dass es in XML keine gute Idee ist "2 Werte" in ein Attribut zu packen, dafür gibt es ja die Möglichkeit beliebige Attribute zu definieren bzw auch noch viele andere Möglichkeiten wie zb mit Referenzen etc zu arbeiten

 

[Meno Hochschild]

Ich möchte das in der XML-Datei so stehen haben:
<element value="a<b"/> und das ist valides XML. Geht das nicht ohne writeCData?

Meiner bescheidenen Meinung nach ist das NICHT valides XML. Das Zeichen < ist nicht erlaubt. Siehe hierzu die XML-Spezifikation 1.0 Abschnitt 3.1 (wellformedness constraint: No < in attribute values).

Siehe auch die folgende Erklärung, was die Motivation hinter dieser Einschränkung ist:

NoLTinAtt