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.
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
LikeLike
Tja, an irgendeinem Punkt kommt man nicht darum herum, sich mit einzelnen Bytes herumzuschlagen.
Kritischer wird es, wenn man sogar auf Bitniveau herunter muss.
LikeLike
so schlimm brauchte ich das in der regel nicht treiben. wir haben nur einmal tatsächlich die registerlänge in der cpu geknackt, da haben wir lange frschen müssen. aber es waren coole zeiten 🙂
es schäumt dieerinnerung
LikeLike
In Bits und Bytes zu schwelgen, hat natürlich schon seinen Reiz, den aber nicht jeder nachvollziehen kann.
LikeLike
bedauerlicherweise nur zu wahr 🙂
es schäumt sherlockholmes
LikeLike
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.
LikeLike
So ähnlich muss es gewesen sein.
Ich tippe allerdings eher auf Not(e)pad. Das zeigt genau so ein Verhalten.
LikeLike
Ich steh auf Beiträge wie diesen: Ich versteh kein Wort, fühle mich aber hinterher immer ein bisschen schlauer! 😀
LikeLike
Ach, Molly, das freut mich, dass du dich wieder schlauer fühlst.
Da muss ich wohl in Zukunft noch ein paar Mal tief in die Nerdkiste greifen, dann kompensieren wir irgendwann den Miezi-Effekt.
LikeLike
und genau deshalb nutzt man XML für jegliches Dateiformat 😉
LikeLike
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.
LikeLike
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…
LikeLike
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.
LikeLike
Genau das Gleiche hat mich auch schon zum Wahnsinn getrieben.. Zum Glück bezahlt 😉
LikeLike
Es kann halt immer wieder Probleme geben, wenn jemand eine reine Binärdatei wie eine Textdatei behandelt.
LikeLike
Pingback: Elfhundertfünfzehn | breakpoint