Neunhundertdreiundzwanzig

Vor einiger Zeit mailte mir ein Kunde eine Datei zu, die sich mit den üblichen entsprechenden Anwendungen nicht öffnen ließ.

Ich bin auf dieses Format spezialisiert, und habe natürlich die Möglichkeiten, mir haarklein im Debugger anzuschauen, wo genau der (erste) fatale Fehler auftritt.
Meine Anwendungen sind – zumindest in einem bestimmten Modus – möglichst fehlertolerant, aber dennoch stiegen sie schon nach wenigen Schritten aus.

OK. Dann schaute ich mir die Datei eben erst einmal in einem Hex-Editor an.
Das sah auf den ersten Blick nicht außergewöhnlich aus, eine typische Datei in diesem Format. In der rechten Spalte werden die Zeichen dargestellt. Das ist halt mehr oder weniger ein Wust aus irgendwelchen Sonderzeichen. Die linke Spalte enthält die korrespondierenden Paare hexadezimaler Ziffern.
Wer schon mal einen Hex-Editor benutzt hat, kann sich vorstellen, wie das aussieht. Wer nicht, hat vermutlich nichts verpasst.

Da ich das Datei-Format notgedrungen gut kenne, ging ich die Werte von vorne einzeln durch.
Einen Hinweis hatte mir der Debugger schon gegeben, nämlich dass die kodierte Längeninformation nicht immer zu stimmen schien.
Es war eine im Grunde stupide Arbeit, die aber vollste (ja, ja, Superlativ von „voll“ gibt es eigentlich nicht, dennoch ist etwa bei einem „vollen“ Glas oder Eimer doch noch ein Stückchen Platz zum Rand, so dass eine Steigerung noch möglich ist) Konzentration und Aufmerksamkeit verlangte.

Glücklicherweise fand ich schon bald eine Längenangabe, die keinesfalls stimmen konnte, und auch nicht mit den referenzierten Daten übereinstimmte.
Ich schaute mir also die Werte genauer an. Eigentlich war dieser Datenbereich nur 10 Bytes lang. Angegeben waren aber 13, gefolgt von einer zusätzlichen 10.
Wer sich ein bisschen mit ASCII-Codes auskennt, wird schon – genau wie ich zu diesem Zeitpunkt – eine Vermutung haben, was passiert ist.

Im Interesse der übrigen Leser gibt es aber keinen Cliffhanger, und ich löse gleich auf.
Ich bestätigte meine Vermutung natürlich erst einmal an den weiteren Daten. Das Phänomen trat immer wieder in dieser Datei auf. Sämtliche 0xA und 0xD waren jedesmal durch die Folge 0xD, 0xA ersetzt. Das brachte die ganze Datei durcheinander und alle Daten verrutschten undefinierbar, so dass es unmöglich war, die Daten tatsächlich einzusehen.
Irgend ein DAU muss die Datei einmal in einem Texteditor geöffnet, und wieder abgespeichert haben. Dabei wurden die Line Feeds (LF, 0xA, 10) und Carriage Returns (CR, 0xD, 13) durch die unter Windows übliche Kombination CR LF für einen Zeilenumbruch ersetzt. Um es verständlicher für Nicht-Computer-Nerds zu formulieren: Die Datei wurde beim Abspeichern so modifiziert, dass sie nur noch unnützen Daten-Müll enthielt.

Ich unternahm noch einen Versuch, und schrieb schnell ein Progrämmchen, das alle Zeilenumbrüche zurück in 0xA konvertieren (erfahrungsgemäß ist 10 ein Standardwert, während 13 nur selten vorkommen dürfte, auch Zeilenumbrüche könnten durchaus vorhanden gewesen sein, sei es als eingekapselter Text, oder durch puren Zufall – die Information, welcher Wert vorher dagewesen war, war ja verschwunden) sollte, in der Hoffnung, dass die Datei sich dann möglicherweise wieder regulär öffnen ließe.

Tatsächlich sah ich danach im Debugger, dass meine Anwendung deutlich weiter kam, aber irgendwo stieg sie dann doch aus. Da waren wohl auch etliche Zehnen die eigentlich Dreizehn hätten sein sollen.
Es gelang mir, manuell noch ein weiteres Stück der Datei zu rekonstruieren, aber dann – mitten in einer Binärwüste – gab ich doch auf, und schnitt den Rest der Datei an definierter Stelle einfach ab, so dass zumindest der Teil, den ich rekonstruiert hatte, konsistent und lesbar war.

Mehr als meinem Kunden diese Ergebnisse in einem Bericht mitzuteilen, und die bearbeitete Datei zuzuschicken, konnte ich leider nicht tun. Wenigstens hatte es sich nicht um wirklich wichtige Daten gehandelt.
Immerhin honorierte der Kunde meine Dienste angemessen, so dass es nicht nur verschwendete Zeit war.

Advertisements

Über breakpoint AKA Anne Nühm

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

16 Antworten zu Neunhundertdreiundzwanzig

  1. schaum schreibt:

    ich bin ja genau so, vor annähernd 30 jahren in die EDV wie es damals hiess eingestiegen. und ich konnte damals auch noch hex-dumps lesen…….manches verändert sich eben an der basis doch nicht….. 🙂

    es schäumt gutso

    Gefällt mir

  2. ednong schreibt:

    Hach ja,
    ich hab doch nix gemacht, hab mir die Datei nur mal in Wo*d angeschaut. und dann hat er gefragt, ob er Speichern soll. War das nicht gut? 😉

    Oh ja, man kann schon so einiges erleben.

    Gefällt mir

  3. Molly schreibt:

    Ich steh auf Beiträge wie diesen: Ich versteh kein Wort, fühle mich aber hinterher immer ein bisschen schlauer! 😀

    Gefällt mir

  4. engywuck schreibt:

    und genau deshalb nutzt man XML für jegliches Dateiformat 😉

    Gefällt mir

    • breakpoint schreibt:

      Ist aber nun mal kein XML, sondern das Format, mit dem ich mir meine Brötchen verdiene.

      Der Gerechtigkeit halber muss man erwähnen, dass die gleiche Datenmenge in einer XML-Datei ein Vielfaches an Platz einnehmen würde, und dass ein vorgeschalteter XML-Parser niemals die gleiche Performance erreicht, wie eine auf ein binäres Format optimierte Anwendung.

      Gefällt mir

      • engywuck schreibt:

        aber dafür menschenlesbar und vor allem „more enterprisy“.

        XML hat so ziemlich alles falsch gemacht was denkbar war: riesige Dateien mit enormer Redundanz (dafür gut komprimierbar); jeder darf Tags selber definieren; Parser sind ar*lahm; „echte“ Binärdaten sind schwer abbildbar — nur das „ansatzweise durch Menschen parsebar“ klappt so lala. Wobei ich manchmal sogar PostScript besser lesbar finde 😉

        Nur leider waren die Alternativen vor XML halt auch nicht wirklich brauch- bzw. skalierbar. Immer diese Kompromisse…

        Gefällt mir

        • breakpoint schreibt:

          Tja, es ist halt ein himmelweiter Unterschied, ob die Datei gut (auch) von Menschen oder nur von Computern gelesen werden soll.

          Für relativ kleine Datenmengen ist XML schon OK (kann man auch händisch editieren :> ), aber bei wirklich umfangreichen Daten geht nichts über ein – gut durchdachtes – Binärformat.

          Gefällt mir

  5. RAID schreibt:

    Genau das Gleiche hat mich auch schon zum Wahnsinn getrieben.. Zum Glück bezahlt 😉

    Gefällt mir

  6. Pingback: Elfhundertfünfzehn | 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