☰

この文字セットの破損とは何ですか? (ISO-2022?)

tag-icon • tag-icon unicode character-encoding file-corruption forensics
この文字セットの破損とは何ですか? (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ѓ であり、変換前はおそらく 1 つの 8 ビット バイトでした。一般的なパターン~XFFの後にシグナル バイトが続くようです。ここで、FF はプレーン ASCII の 16 進シーケンス (ここでは主に 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^?~

( ^?: はリテラル DEL 文字、ASCII 0x7F です。)

先頭のチルダの代わりにスペースが入っているのは、変換で何がうまくいかなかったかを示すヒントになるかもしれませんが、これは推測にすぎません。

ESC は% 0「他のコーディング システムを指定する」ための ISO-2022 コードのように見えますが、0ここでは何の略ですか? おそらく、私は Wikipedia の記事をさらなる例なしで理解するには鈍感すぎるでしょうし、私が見つけた他のすべては、ISO-2022-JP などの一部のサブセットに非常に重点を置いているようです。

これまでの私の分析はあなたにとって意味をなしていますか? 何が起こったのかを解明するのを手伝っていただけますか? また、破損を元に戻す方法についてのアドバイスもいただけませんか?

私はこれら2つの例の拡張フラグメントの16進ダンプを次の場所に掲載しました。http://pastebin.com/ffn7CtdG

答え1

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

私が見た断片の中で印象に残ったいくつかの点:

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

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

例えば、至る所で見られるのがd193キリル文字の小さなGJE異なるコードページ表現は次のとおりです。

画像

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

たとえば、次のシーケンスが見つかりますSPT~X83..Telecom。「SPT Telecom」は、1993 年に設立されたチェコの国営通信会社に他なりません。ロイター通信のテキストにこの会社が登場するのは当然のことです。ただし、2 つの単語の間に空白以外の区切り文字を置く必要はありません。

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

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

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

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

関連情報