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.