Ich mag Markup - egal in welcher Form (ich habe hin und wieder darüber berichtet). XML - wie der Name schon sagt - gehört auch dazu und zu meinem Erstaunen habe ich neulich wieder mal etwas Neues darüber gelernt...

Auf Arbeit wurde ich neulich mit einem Ticket konfrontiert, das als Attachment ein Log angehängt hatte. In diesem Log stellte sich als Ursache der häufigen Exceptions heraus, dass ein XML versucht wurde zu parsen, das ungültige Zeichen enthielt.

Damit meine ich nicht solche, die man über Entities abbilden kann wie etwa & oder > sondern solche, die wirklich nicht auftreten dürfen - wie etwa 0x0b (Cursor runter oder vertical tab) oder 0x01 oder 0x6823 oder, oder, oder....

Solche waren in die Datenbank gelangt und wann immer der (proprietäre) OR-Mapper ein Objekt daraus zauberte und dieses Objekt dann vom (proprietären) XML-Serialisierer in ein XML-Fragment umgewandelt wurde entstand ungültiges HTML. Der Fic war schnell gefunden, aber die gesamte Aktion (Forensik, Tests, Alternativen, Implementieren, Testen) hatte mich nachdenklich gemacht: In Java existiert ja bereits ein XML-Serialisierer (java.beans.XMLEncoder), der mit diesem Problem ebenso umgehen können sollte - oder konnte es wirklich sein, dass ich damit ein Loophole in Java entdeckt haben könnte? Diesen Gedanken verwarf ich nach ein wenig Nachdenken sofort wieder: Der XMLEncoder ist dafür da, JavaBeans zu serialisieren. Diese haben häufig String-Properties. Es kann keine Einschränkungen hinsichtlich der verwendbaren Unicode-Zeichen geben, wenn der Serialisierer universell für jegliche JavaBeans eingesetzt werden können soll - neugierig war ich aber jetzt darauf, wie die Entwickler das geschafft hatten...

Ich probierte dazu ein kleines Java-fragment aus, das wie folgt beschaffen war:

		XMLBean bean=new XMLBean();
		bean.setData("huhu\u000bhallo");
		System.out.println(bean);
		java.io.ByteArrayOutputStream baos = new java.io.ByteArrayOutputStream();
		java.beans.XMLEncoder enc=new java.beans.XMLEncoder(baos);
		enc.writeObject(bean);
		enc.close();
		baos.close();
		java.lang.String encoded=baos.toString();
		System.out.println(encoded);
		java.io.ByteArrayInputStream bais=new java.io.ByteArrayInputStream(baos.toByteArray());
		java.beans.XMLDecoder dec=new java.beans.XMLDecoder(bais);
		java.lang.Object obj=dec.readObject();
		dec.close();
		bais.close();
		System.out.println(obj.toString());

Die XMLBean-Klasse war trivial:

public class XMLBean extends java.lang.Object
{
	private java.lang.String data;
	public String getData()
	{
		return data;
	}
	public void setData(String data)
	{
		this.data = data;
	}
	@Override
	public String toString()
	{
		return getData();
	}
}

Die Ausgabe dieses Testprogramms sieht wie folgt aus:

huhuhallo
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.8.0_51" class="java.beans.XMLDecoder">
 <object class="de.elbosso.scratch.misc.XMLBean">
  <void property="data">
   <string>huhu<char code="#1b"/>hallo</string>
  </void>
 </object>
</java>

huhuhallo

Das in XML nicht gültige Steuerzeichen wird hier über ein eigenes Vokabular abgedeckt - genauer über ein Tag namens char mit einem Attribut namens code, das den hexadezimalen Codepoint für das in XML nicht erlaubte Zeichen enthält.

Das Gegenstück java.beans.XMLDecoder kennt dieses Tag natürlich und setzt die Property korrekt wieder zusammen, was man am Ende der Ausgabe des Testprogrammes erkennen kann. Damit ist das Ergebnis der Serialisierung gültiges XML, das von jedem Parser verstanden werden kann.

Eine wie ich finde clevere Idee - kennt man dieses Vorgehen, kann man es zum Beispiel in eigenen XSLT-Templates nutzen...

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )