☰

這是什麼字符集損壞？ （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，但我對它還不夠熟悉，無法真正確定。顯然，在最終變成這樣之前，它至少經歷了一個破損的過濾器，可能是多個。

查看第一行，d1 93是 ѓ，在轉換之前可能是 8 位元位元組。一般模式似乎~XFF後面跟著一個訊號位元組，其中FF 是純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。

到目前為止我的分析對您來說有意義嗎？您能幫我弄清楚發生了什麼，甚至可以提供有關如何恢復損壞的建議嗎？

我已將這兩個範例的擴展片段的十六進制轉儲發佈在http://pastebin.com/ffn7CtdG

答案1

在這個答案中，我詳細介紹了我對這些文件來源的想法。這不是一個完整的答案，因為更詳細的取證分析需要親自訪問至少完整文件的某些子集。

在我看到的片段中，有一些讓我印象深刻的點：

  1. 這些字是捷克語
  2. 單字之間有奇怪的序列，而且它們重複很多
  3. 這些奇怪的序列由毫無意義的 UTF-8 字元組成，除了其中一些本質上是西里爾字母。

我的結論是，這些文件最初不是文字文件，而是使用包含西里爾字元的代碼頁將其錯誤地轉換為 UTF-8，就好像它們是文字一樣。

例如，無所不在的序列d193是西里爾字母小吉傑其不同的代碼頁表示是：

影像

這為我們提供了原始文件的可能編碼列表，這些編碼取決於原始作業系統。如果它們是在 Windows 電腦上建立的，則它們的原始程式碼頁可能是 Windows-1251，但在 Mac 上它們可能是 Macintosh Cyrillic。當然，UTF-8 的翻譯也完全有可能使用了錯誤的編碼。

例如，我們找到序列SPT~X83..Telecom。 「SPT Telecom」公司正是成立於 1993 年的捷克國家電信公司，它出現在路透社新聞專線文本中是很合乎邏輯的。但是，除了兩個單字之間的空格之外，沒有任何分隔符號。

我對這些在單字中重複出現的令人費解的字串的解釋是，它們不是也不可能是文字的一部分。我相信它們一定是放置在單字之間的二進位字符，這可能與文件的格式有某種聯繫。因此，將檔案轉換為 UTF-8 的轉換程式會盲目地將它們轉換為毫無意義的 UTF-8 字元。

即使嘗試使用上面列表中的任何代碼頁將此序列轉換為二進制，我也沒有得到任何有意義的序列。但是，我對來自一些舊文本編輯器的文本文件有經驗，這些文本編輯器在文本中放置“不可見”字符，其目的永遠不會顯示，而是控制顯示。

我相信這是對這些文件的解釋，但我不知道這種奇怪的文件格式。它可能是一些未知的捷克文字編輯器（至少我不知道）。如果可以掃描文件以查找文字中包含的日期，這可能有助於縮小可能性。

我不相信您關於原始文件結構良好並編碼的理論ISO-2022，因為這些奇怪的序列似乎不是（或曾經是）ISO-2022 控制序列。

相關內容