Ich habe eine String zusammenhängende binäre 0 innerhalb von UTF-8 ( "A\u0000B" ). JAXB marshalliert glücklich ein XML-Dokument, das ein solches Zeichen enthält, kann es jedoch nicht entpacken:
Die Wurzelklasse ist einfach:
%Vor% Ausgabe-XML enthält auch binary 0 zwischen A und B (in hex: 41 00 42 ), was den folgenden Fehler während der Rückprogrammierung verursacht:
Interessanterweise wird mit der Raw-DOM-API ( Beispiel ) der Befehl escaped 0 : A�B erzeugt, aber der Versuch, sie zurückzulesen, ist ähnlich Error. Auch 0 (weder binär noch maskiert) ist von keinem XML-Parser oder xmllint erlaubt (siehe auch: Python + Expat: Fehler bei & amp; ; # 0; Entitäten ).
Warum ermöglicht die JAXB / DOM-API das Erstellen ungültiger XML-Dokumente, die nicht zurückgelesen werden können? Sollte es beim Marshalling nicht schnell scheitern?
Gibt es eine elegante und globale Lösung? Ich habe Menschen gesehen, die dieses Problem angehen:
Aber sollte XML-Stack in Java nicht reifer werden (ich benutze 1.7.0_05)? Behandle das entweder standardmäßig oder durch eine einfache Einstellung? Ich suche nach Entweichen, Ignorieren oder schnell scheitern - aber das Standardverhalten des Generierens ungültiger XML ist nicht akzeptabel. Ich glaube, dass eine solche grundlegende Funktionalität keine zusätzliche Codierung auf der Client-Seite erfordern sollte.
Warum ermöglicht JAXB / DOM API das Erstellen ungültiger XML-Dokumente, die nicht zurückgelesen werden können? Sollte es beim Marshalling nicht schnell scheitern?
Sie müssten die Implementierer fragen.
Es ist wahrscheinlich, dass sie dachten, dass die Kosten für die Überprüfung jedes serialisierten Datenzeichens nicht gerechtfertigt wären ... besonders wenn der Parser sie dann noch einmal überprüfen würde.
Nachdem Sie sich dazu entschlossen haben, den Serializer auf diese Weise zu implementieren (oder dies versehentlich getan haben), würden sie den vorhandenen Code, der davon abhängig ist, dass er serialisiert werden kann, standardmäßig deaktivieren, wenn er das Verhalten dann standardmäßig ändert XML.
Aber sollte XML Stack in Java nicht reifer werden (ich benutze 1.7.0_05) handle das entweder standardmäßig oder durch eine einfache Einstellung?
Nicht unbedingt ... wenn Sie den obigen Grund # 2 akzeptieren. Selbst einfache Einstellungen können sich messbar auf die Leistung auswirken.
Auch 0 (weder binär noch maskiert) ist von keinem XML-Parser oder xmllint erlaubt ...
Ganz zu Recht! Es ist durch die XML-Spezifikation verboten.
Ein interessanterer Test wäre jedoch, zu sehen, was passiert, wenn Sie versuchen XML mit einem ungültigen Zeichen zu generieren, indem Sie andere XML-Stacks verwenden.
Gibt es eine elegante und globale Lösung?
Wenn das Problem, das Sie lösen möchten, darin besteht, wie Sie \u0000 oder \u000B senden, müssen Sie eine anwendungsspezifische Kodierung auf die Zeichenfolge anwenden, bevor Sie in die Zeichenfolge einfügen DOM. Und das andere Ende muss die äquivalente Decodierung bereitstellen.
Wenn Sie versuchen, die fehlerhaften Daten zu erkennen, bevor es zu spät ist, können Sie dies mit einem Ausgabestream-Filter zwischen dem Serializer und dem endgültigen Ausgabestream tun. Aber wenn Sie die Schlechtigkeit erkennen, gibt es keine gute Möglichkeit (d. H. Transparent für den XML-Verbraucher), um es zu beheben.