Was ist das für eine Zeichensatzbeschädigung? (ISO-2022?)

Question

Ich habe eine Textdatei aus einer älteren Quelle, die beschädigte Zeichen enthält.

Zuerst dachte ich, dass es sich bei der Beschädigung nur um Kauderwelsch handelte, aber bei näherer Betrachtung scheint es, dass ein Teil des beschädigten Textes wahrscheinlich rekonstruiert werden könnte.

Um meine Bemühungen fokussieren zu können, wäre es hilfreich zu verstehen, wie das Original aussah, auch wenn ich es nicht vollständig rekonstruieren kann.

Leider stammt das Dokument aus einer Sammlung, die ich nicht freigeben kann, aber hier ist ein Ausschnitt. Die Nachricht wurde in UTF-8 konvertiert, aber die Konvertierung ist irgendwo fehlgeschlagen, sodass sie größtenteils unleserlich ist. Es sind Textfragmente in tschechischer Sprache sichtbar, in denen die tschechischen Akzentbuchstaben durch kyrillische Buchstaben ersetzt wurden (die vor der Konvertierung wahrscheinlich etwas völlig anderes waren).

0001f80: 33d1 936e 6576 79d1 87d0 bd7a 656e d18c  3..nevy....zen..
0001f90: 6368 7e58 3833 d193 7e58 3945 d19b d0b1  ch~X83..~X9E....
0001fa0: 646f 7374 d0bd 7e58 3833 d193 6e61 7e58  dost..~X83..na~X
0001fb0: 3833 d193 7ad1 87d0 bd7a 656e 20d0 bd7e  83..z....zen ..~
0001fc0: 5838 33d1 936e 6562 6f7e 5838 33d1 9370  X83..nebo~X83..p
0001fd0: d187 656b 6cd0 b164 6b75 7e58 3833 d193  ..ekl..dku~X83..
0001fe0: 7465 6c65 666f 6e6e d0bd 7e58 3833 d193  telefonn..~X83..
0001ff0: 7374 616e 6963 657e 5838 33d1 9376 207e  stanice~X83..v ~
0002000: 5838 33d1 9372 6567 696f 6e75 7e58 3833  X83..regionu~X83
0002010: d193 5072 6168 617e 5838 33d1 9365 7669  ..Praha~X83..evi
0002020: 6475 6a65 7e58 3833 d193 5350 547e 5838  duje~X83..SPT~X8
0002030: 33d1 9354 656c 6563 6f6d 2e7e 5838 33d1  3..Telecom.~X83.
0002040: 934e 617e 5838 33d1 9364 6e65 7e58 2039  .Na~X83..dne~X 9
0002050: 41d1 996e d0bd 7e58 3833 d193 7469 736b  A..n..~X83..tisk
0002060: 6f76 d0b9 7e58 3833 d193 6b6f 6e66 6572  ov..~X83..konfer
0002070: 656e 6369 7e58 3833 d193 746f 7e58 3833  enci~X83..to~X83
0002080: d193 d187 656b 6c7e 5838 33d1 93d1 8765  ....ekl~X83....e

Ich vermute vage, dass die Kodierung damit zusammenhängen könnteISO-2022, aber ich kenne mich damit nicht gut genug aus, um wirklich sicher zu sein. Es ist offensichtlich durch mindestens einen defekten Filter gegangen, möglicherweise durch mehrere, bevor es so endete.

Betrachtet man die erste Zeile, d1 93ist es ѓ und war vor der Konvertierung wahrscheinlich ein einzelnes 8-Bit-Byte. Einem allgemeinen Muster scheint ~XFFein Signalbyte zu folgen, wobei das FF eine Hex-Sequenz in einfachem ASCII ist (hier meistens 83, aber im Allgemeinen von 80 bis 9E in der gesamten Stichprobe) und das letzte Byte jetzt ein UTF-8-Zeichen ist. (Es könnten natürlich auch mehrere Bytes in der Eingabe gewesen sein.) Diese Sequenz erscheint zwischen Wörtern (immer ~X83ѓ?) und manchmal innerhalb von Wörtern.

Hier ist dasselbe Fragment als reiner Text, wie es jetzt unter UTF-8 gerendert wird.

3ѓnevyчнzenьch~X83ѓ~X9Eћбdostн~X83ѓna~X83ѓzчнzen н~X83ѓnebo
~X83ѓpчeklбdku~X83ѓtelefonnн~X83ѓstanice~X83ѓv ~X83ѓregionu
~X83ѓPraha~X83ѓeviduje~X83ѓSPT~X83ѓTelecom.~X83ѓNa~X83ѓdne~
X 9Aљnн~X83ѓtiskovй~X83ѓkonferenci~X83ѓto~X83ѓчekl~X83ѓчe

Ich habe andere Beispiele in anderen Sprachen, daher liegt mein Schwerpunkt nicht wirklich darin, das Tschechische zu klären. Hier ist der Anfang eines Beispiels in, ich weiß nicht, wahrscheinlich irgendeiner fernöstlichen Sprache?

 X1B%0 ~XD0^?~X98^?~XD0^?^?^?~X82^?~XD0^?~XB5^?^?~X80^?^?~X84^?~XD0^?~XB0^?~XD0
^?^?^?~X81^? ~XD0^?~XB1^?^?~X83^?~XD0^?^?~XD0^?~XB2^?~XD0^?~XB0^?~XD0^?^?^?~X8C
^?~XD0^?^?~XD0^?~XBE^? ~XD0^?~XB7^?~XD0^?~XB0^? ~XD0^?^?~XD0^?~XB5^?^?~X81^?~XD
0^?^?~XD0^?~XBE^?~XD0^?^?^?~X8C^?~XD0^?^?~XD0^?~XBE^? ~XD0^?^?~XD0^?~XB8^?~XD0^
?^?^?~X83^?^?~X82^? ~XD0^?~XB4^?~XD0^?~XBE^? ^?~X81^?~

(Die ^?:s sind wörtliche DEL-Zeichen, ASCII 0x7F.)

Das Leerzeichen anstelle einer Tilde am Anfang könnte ein Hinweis darauf sein, was bei der Konvertierung schief gelaufen ist, aber das ist wilde Spekulation.

ESC % 0sieht aus wie der ISO-2022-Code zur „Bezeichnung eines anderen Kodierungssystems“, aber wofür steht es 0hier? Ich bin wahrscheinlich zu dumm, um den Wikipedia-Artikel ohne weitere Beispiele zu verstehen, und alles andere, was ich finden konnte, scheint sehr auf eine Teilmenge wie ISO-2022-JP fokussiert zu sein.

Ist meine bisherige Analyse für Sie verständlich? Können Sie mir helfen, herauszufinden, was passiert ist, und mir vielleicht sogar Ratschläge geben, wie ich die Beschädigung rückgängig machen kann?

Ich habe Hex-Dumps von erweiterten Fragmenten dieser beiden Beispiele veröffentlicht unterhttp://pastebin.com/ffn7CtdG

Answer 1

In dieser Antwort erläutere ich ausführlich meine Vorstellungen zur Quelle dieser Dateien. Dies ist keine vollständige Antwort, da für eine detailliertere forensische Analyse praktischer Zugriff auf zumindest eine Teilmenge vollständiger Dateien erforderlich ist.

Einige Punkte, die mir in den Fragmenten, die ich gesehen habe, auffallen:

1. Die Wörter sind auf Tschechisch
2. Es gibt seltsame Sequenzen zwischen den Wörtern und sie wiederholen sich oft
3. Diese seltsamen Sequenzen bestehen aus UTF-8-Zeichen, die überhaupt keinen Sinn ergeben, außer dass einige von ihnen kyrillischer Natur sind.

Mein Fazit ist, dass diese Dateien ursprünglich keine Textdateien waren, sondern fälschlicherweise wie Text in UTF-8 konvertiert wurden, wobei eine Codepage verwendet wurde, die kyrillische Zeichen enthielt.

Die allgegenwärtige Folge von ist beispielsweise d193der kyrillische Buchstabekleines Gjederen unterschiedliche Codepage-Darstellungen sind:

Dadurch erhalten wir eine Liste möglicher Kodierungen der Originaldateien, die von den ursprünglichen Betriebssystemen abhängen. Wenn sie auf einem Windows-Computer erstellt wurden, war ihre ursprüngliche Codepage wahrscheinlich Windows-1251, auf einem Mac waren sie jedoch wahrscheinlich in Macintosh-Kyrillisch. Natürlich ist es auch durchaus möglich, dass bei der Übersetzung in UTF-8 die falsche Kodierung verwendet wurde.

So finden wir beispielsweise die Sequenz SPT~X83..Telecom. Das Unternehmen „SPT Telecom“ ist kein anderes als das 1993 gegründete tschechische nationale Telekommunikationsunternehmen, dessen Präsenz in einem Reuters-Newswire-Text durchaus logisch ist. Außer einem Leerzeichen zwischen den beiden Wörtern gibt es jedoch keinen Grund für ein Trennzeichen.

Meine Erklärung für diese rätselhaften Zeichenfolgen, die sich zwischen den Wörtern wiederholen, ist, dass sie nicht Teil des Textes waren und auch nicht sein konnten. Ich glaube, dass es sich dabei um Binärzeichen gehandelt haben muss, die zwischen den Wörtern platziert wurden und wahrscheinlich etwas mit der Formatierung der Dateien zu tun hatten. Das Konvertierungsprogramm, das die Dateien in UTF-8 konvertierte, konvertierte sie daher blind in UTF-8-Zeichen, die keinen Sinn ergeben.

Selbst wenn ich versuche, diese Sequenzen mit einer der Codeseiten in der obigen Liste in Binärcode umzuwandeln, erhalte ich keine sinnvollen Sequenzen. Ich habe jedoch Erfahrung mit Textdateien aus einigen alten Texteditoren, die „unsichtbare“ Zeichen in den Text eingefügt haben, deren Zweck nicht darin bestand, angezeigt zu werden, sondern die Anzeige zu steuern.

Ich glaube, das ist die Erklärung für diese Dateien, aber ich kenne dieses seltsame Dateiformat nicht. Es könnte sich um einen unbekannten tschechischen Texteditor handeln (zumindest mir unbekannt). Wenn die Dateien nach im Text enthaltenen Daten durchsucht werden können, könnte dies helfen, die Möglichkeiten einzugrenzen.

Ich glaube nicht an Ihre Theorie, dass die Originaldateien gut aufgebaut und kodiert sind inISO-2022, da diese seltsamen Sequenzen keine ISO-2022-Steuersequenzen zu sein scheinen (oder nie gewesen sind).