web-dev-qa-db-ja.com

この文字セットの破損は何ですか？ （ISO-2022？）

破損した文字を含むレガシーソースからのテキストファイルがあります。

最初は、破損は単なる意味不明だと思っていましたが、詳しく調べてみると、破損したテキストの一部はおそらく再構築できるようです。

私の努力を集中するために、私がそれを完全に再構築することができなくても、オリジナルがどのように見えたかを理解することは役に立ちます。

残念ながら、このドキュメントは私が自由に共有できないコレクションからのものですが、ここにスニペットがあります。メッセージはUTF-8に変換されましたが、どこかで変換に失敗したため、ほとんど判読できません。チェコ語のテキストの断片が表示され、アクセント付きのチェコ語の文字がキリル文字に置き換えられています（変換前はおそらく完全に異なっていたものです）。

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

エンコーディングが ISO-2022 に関連しているのではないかと漠然と推測していますが、私はそれを十分に理解していないので、本当に確信が持てません。このようになる前に、明らかに少なくとも1つの壊れたフィルター、場合によっては複数のフィルターを通過しました。

最初の行を見ると、d1 93はѓであり、変換前はおそらく単一の8ビットバイトでした。一般的なパターンは、~XFFの後にシグナルバイトが続くようです。ここで、FFはプレーンな16進シーケンスですASCII（ここではほとんど83ですが、全体で一般的に80から9Eです）サンプル）、最後のバイトはUTF-8文字になりました（もちろん、入力でも複数バイトである可能性があります）。このシーケンスは単語間（常に~X83ѓ？）に表示され、場合によっては内部に表示されます。言葉。

これは、現在UTF-8でレンダリングされているため、単なるテキストと同じフラグメントです。

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

私は他の言語で他のサンプルを持っているので、チェコ語を整理することは本当に私の焦点では​​ありません。これが、おそらく極東の言語での始まりです。

 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^?~

（^?：sはリテラルDEL文字、ASCII 0x7F。）

最初のチルダの場所のスペースは、変換で何がうまくいかなかったかについてのヒントかもしれませんが、これは野蛮な憶測です。

ESC %0は「他のコーディングシステムを指定する」ためのISO-2022コードのように見えますが、ここで0は何を表していますか？私はおそらく密度が高すぎて、ウィキペディアの記事をさらに例なしで理解することはできません。他に見つけることができるものはすべて、ISO-2022-JPなどのサブセットに非常に焦点を当てているようです。

これまでの私の分析はあなたにとって意味がありますか？何が起こったのかを理解するのを手伝ってくれませんか、そしておそらく腐敗を元に戻す方法についてアドバイスを提供することさえできますか？

これら2つの例の拡張フラグメントの16進ダンプを http://Pastebin.com/ffn7CtdG に投稿しました。

unicodecharacter-encodingfile-corruptionforensics
4
tripleee

この回答では、これらのファイルのソースについての私の考えを詳しく説明します。より詳細なフォレンジック分析では、完全なファイルの少なくとも一部のサブセットに実際にアクセスする必要があるため、これは完全な答えではありません。

私が見た断片の中で私を襲ういくつかのポイント：

  1. 言葉はチェコ語です
  2. 単語を区切る奇妙なシーケンスがあり、それらは何度も繰り返されます
  3. これらの奇妙なシーケンスはUTF-8文字で構成されており、一部がキリル文字である点を除いて、まったく意味がありません。

私の結論は、これらのファイルは元々テキストファイルではなかったが、キリル文字を含むコードページを使用して、テキストであるかのように誤ってUTF-8に変換されたということです。

たとえば、d193の遍在するシーケンスは、キリル文字 small gje であり、その異なるコードページ表現は次のとおりです。

image

これにより、元のオペレーティングシステムに依存する、元のファイルの可能なエンコーディングのリストが表示されます。それらがWindowsコンピューターで作成された場合、元のコードページはおそらくWindows-1251でしたが、MacではおそらくMacintoshキリル文字でした。もちろん、UTF-8への変換で間違ったエンコーディングが使用された可能性もあります。

たとえば、シーケンスSPT~X83..Telecomが見つかります。 「SPTTelecom」という会社は、1993年に設立されたチェコの全国電気通信会社であり、ロイターのニュースワイヤーテキストでの存在は非常に論理的です。ただし、2つの単語の間の空白の横に区切り文字がある理由はありません。

単語間で繰り返されるこれらの不可解な文字列に対する私の説明は、それらがテキストの一部ではなかったし、そうではなかったということです。その場合、それらは単語の間に配置されたバイナリ文字であったに違いないと思います。これはおそらくファイルのフォーマットに何らかの関係がありました。したがって、ファイルをUTF-8に変換した変換プログラムは、ファイルを意味のないUTF-8文字に盲目的に変換しました。

上記のリストのコードページのいずれかを使用して、このシーケンスをバイナリに変換しようとしても、意味のあるシーケンスは得られません。ただし、表示を目的とせず、表示を制御することを目的として、テキストに「非表示」の文字を配置した古いテキストエディタからのテキストファイルを使用した経験があります。

これがこれらのファイルの説明だと思いますが、この奇妙なファイル形式はわかりません。それはいくつかの未知のチェコ語のテキストエディタであった可能性があります（少なくとも私には未知です）。テキストに含まれる日付についてファイルをスキャンできる場合、これは可能性を絞り込むのに役立つ可能性があります。

これらの奇妙なシーケンスはISO-2022制御シーケンスではないように見える（またはこれまでにない）ため、元のファイルが適切に構築され、 ISO-2022 でエンコードされているというあなたの理論を信じていません。 。

1
harrymc