Dreizehnhundertdreiundneunzig

Wieder mal habe ich Probleme mit XML.

Ein Kunde möchte ein Programm, das jenes gewisse, von mir gelegentlich erwähnte Dateiformat nach bestimmten Vorgaben nach XML konvertiert.
Da es dafür keine allgemeingültige Dokumenttypdefinition gibt, habe ich die selbst entwickelt.

So weit, so gut.
Eigentlich war ich mit der Programmentwicklung schon weit vorangeschritten. Jetzt hat sich jedoch ein Fehler offenbart.

In weiser Voraussicht hatte ich die vorkommenden Zeichenketten in einen CDATA-Block eingekapselt, in der Annahme, dass dort auch einzelne Nicht-ASCII-Zeichen zulässig sind (zumindest wenn man UTF-8 als Encoding wählt).
Tja .. und jetzt hat es bei einer vom Kunden zur Verfügung gestellten Testdatei den XML-Parser, der die Gültigkeit des Dokumentes überprüfen sollte, rausgehaut.

Also habe ich nachgesehen, wo das Problem liegt, und siehe da: Da ist ein Nicht-ASCII-Zeichen in einem String, wo es eigentlich gar nicht sein dürfte.
Die Ursache liegt also in einer von vornherein nicht-validen Testdatei.
Das kommt gar nicht so selten vor, dass existierende Dateien eigentlich nicht konform zur Standardspezifikation sind. Die Hersteller schludern da alle mehr oder weniger.
Aber was soll ich machen? Ich darf den Inhalt ja nicht einfach verändern.

Als – vorübergehenden – Workaround ersetze ich jetzt alle entsprechenden Nicht-ASCII-Zeichen (also n > 127) in Textstrings durch eine äquivalente Entity der Form „&#n;“.
Das ist zwar keine Lösung, aber wenigstens komme ich erst mal weiter, und kann mir später noch Gedanken darüber machen, wie ich damit verfahre.


Nachtrag:
Mit dem folgenden Inhalt einer XML-Datei lässt sich das Problem reproduzieren:


<?xml version=“1.0″ encoding=“UTF-8″?>
<!– Test (C) breakpoint –>
<ABC>
<DEF>
<GHI>OK</GHI>
<JKL>Funktioniert</JKL>
<GHI><![CDATA[Geht]]></GHI>
<GHI><![CDATA[Geht nicht: º]]></GHI>
</DEF>
</ABC>
<!– Test © breakpoint –>


Kopieren, in Texteditor pasten, mit XML-Extension abspeichern.

Beispiel für Fehlermeldung:


XML-Verarbeitungsfehler: nicht wohlgeformt
Adresse: file://///cn/z/Test.xml
Zeile Nr. 8, Spalte 28: 

<GHI><![CDATA[Geht nicht: �]]></GHI>
----------------------------------^

Oder

An invalid character was found in text content. Error
processing resource 'file://///cn/z/Test.xml'. Line 8,
Position 28

(das nächste Mal mach‘ ich Screenshots ..)

Advertisements

Über breakpoint AKA Anne Nühm

Die Programmierschlampe.
Dieser Beitrag wurde unter Uncategorized abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

21 Antworten zu Dreizehnhundertdreiundneunzig

  1. LinustheSleepless schreibt:

    Das ist doch eine „Momentaufnahme“ oder.

    Auf z.B http://coderanch.com würde Dir bestimmt geholfen

    Gefällt mir

  2. stefanolix schreibt:

    Was ist denn das »gewisse« Dateiformat? Kann es sein, dass dort etwas nicht standardgerecht ist?

    Gefällt mir

  3. whocares schreibt:

    UTF8 heißt nicht, das man da in den Datenstrom einfach jedes beliebige Bitmuster reinknallen kann; so ist z.B. der Bereich 0x80 bis 0xBF nur zulässig, wenn zuvor ein Sequenzstart (obere beide Bits gesetzt / 0xC0-0xFF) kam. Man muß schon alle non-ASCII-Zeichen auch tatsächlich als UTF8 eincodieren.

    Das ungültige Zeichen im Beispiel ist 0xBA und ist damit ungültiges UTF8, weil zuvor kein Sequenzstart, sondern ein Whitespace (0x20) war. Richtig muß es als 0xC2 0xBA serialisiert werden, eben halt standardmäßiges UTF8.

    Gefällt mir

  4. Molly L. schreibt:

    Eieiei, was soll ich denn dazu kommentieren?
    If
    irgendwo ein Fehler then
    do it richtig
    or
    forget it
    End if
    😉

    Gefällt 1 Person

  5. Jezek1 schreibt:

    ???; mhhm, tja, interessant, also wenn man das so sieht ist das ja logisch…

    Kommt mir vor wie die Antwort meiner Software-Kollegen auf gelegentliche Fragen von mir, ob dadurch der Kunde irgendein Nachteil bekommt. aber diese Fragen verstehen meine Kollegen wiederum nicht.

    Also mache ich dann das Planspiel „Jezek mimt den dummen, zahlenden Kunden“: Wenn ich die Kiste jetzt einschalte, was passiert dann? Fahrt das Betriebssystem störungsfrei ´hoch? Ebenso die Anwendung? Kann ich das PW eingeben? usw. usw.

    Gefällt mir

  6. Plietsche Jung schreibt:

    Es war schön immer so, dass das Abfangen von Fehlern komplexer als die eigentliche Funktion ist.

    Gefällt 1 Person

  7. Pingback: Ein Tweet kommt selten allein – #SpeakFreely //1569 | breakpoint

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s