Cách sửa mã hóa - dấu nháy đơn xuất hiện dưới dạng ‰ Ûª

Tôi có một tệp văn bản trong đó tất cả các ký tự ASCII xuất hiện chính xác nhưng một số ký tự khác thì không. Đặc biệt có từ này:

don‰Ûªt

Trong hex các byte là 64 6f 6e 89 db aa 74. Rõ ràng, gần như chắc chắn rằng ‰Ûª nên là một dấu nháy đơn U + 02BC , U + 2019 , hoặc là U + 0092 . [ Chỉnh sửa để thêm: Dựa trên việc sao chép dấu nháy đơn chính xác từ tệp PDF có chứa cùng một văn bản, bây giờ tôi chắc chắn chắc chắn rằng đó là U + 2019 .]

Trang web này nói

Nếu một chuỗi các bit không có ý nghĩa (đối với con người) trong bất kỳ mã hóa nào, tài liệu hầu như có thể được chuyển đổi không chính xác tại một số điểm. ... Nếu một tài liệu đã bị hiểu sai và chuyển đổi sang một mã hóa khác, nó sẽ bị hỏng. Cố gắng "sửa chữa" nó có thể hoặc không thể thành công, thường thì không. Bất kỳ dịch chuyển bit thủ công hoặc voodoo mã hóa khác chủ yếu là vậy, voodoo.

Nhưng chắc chắn tôi phải có khả năng tìm ra những gì đã xảy ra với tệp của mình, với điều kiện là tôi biết các byte và tôi biết chúng có nghĩa là gì. Bất cứ ai có thể cho tôi biết làm thế nào để tìm ra làm thế nào các tập tin bị hỏng, và làm thế nào để sửa nó?

Bất cứ ai có thể cho tôi biết làm thế nào để làm thế nào các tập tin bị hỏng, ...

Tôi không thể, nhưng có lẽ bạn sẽ gặp may mắn.

Với một cấu hình được xáo trộn của khối Rubik, rất dễ dàng thực hiện một bộ di chuyển để đưa nó về trạng thái bắt đầu. Thông thường không thể tìm ra di chuyển nào được sử dụng để đến trạng thái bị xáo trộn - bởi vì số lượng các chuỗi di chuyển có thể có là rất lớn.

Vấn đề của bạn là tương tự. Một phần vì bạn không đưa ra manh mối nào về nền tảng, ngôn ngữ và công cụ có thể đã được sử dụng để tạo tệp văn bản này.

0x89 không phải là byte đầu tiên hợp lệ cho mã hóa UTF8 ba byte của một ký tự. 0xDBAA là điểm dừng trung tâm trống Ả Rập. Đó là tất nhiên không thể tin được. Có lẽ UTF8 đã bị hiểu sai là một số mã hóa 8 bit và sau đó được lưu dưới dạng mã hóa 8 bit khác. Nếu tệp đã ở gần Nhật Bản, bạn có thể ném một số lỗi lạm dụng JIS, Shift-JIS và EUC vào hỗn hợp.

Có thể có một tá các ký tự Unicode hợp lý và có thể có số lượng mã hóa 8 bit và 16 bit hợp lý hơn. Đó là quá nhiều hoán vị để thử bằng tay. Nếu nó đủ quan trọng, tôi có thể viết mã để thử tất cả các hoán vị của ký tự bắt đầu cộng với hai lần tranh giành và xem liệu có đến 0x89DBAA không.

Theo thống kê, tôi mong đợi kịch bản rất có thể là một cái gì đó gần như nhưng không hoàn toàn không giống như:

1. Tạo tệp văn bản UTF8 không có BOM (như khuyến nghị của tập đoàn Unicode).
2. Đọc tệp đó bằng MS-Windows Notepad trong ngôn ngữ "Windows-Latin-1". Notepad đọc sai UTF8 là CP-1252,  một phần vì UTF-8 không có Dấu Byte-Order và vì  nhiều công cụ Microsoft lạm dụng / lạm dụng Dấu hiệu đơn hàng Byte như một  Chỉ báo mã hóa.
3. Lưu tệp dưới dạng "Unicode". Notepad sử dụng thuật ngữ không chính xác của Microsoft và dịch những gì nó nghĩ là CP-1252 thành UTF-16 little endian (với BOM)

Nhưng điều đó quá dễ dàng (vì vậy tôi đã không thử nó).

Tôi chắc chắn câu trả lời sẽ rõ ràng rõ ràng khi nhìn lại. Nhưng đó là sự thoải mái nhỏ bây giờ.

... Và làm thế nào để khắc phục nó?

Cho rằng nội dung được tiết lộ duy nhất là từ tiếng Anh don't chúng ta có thể suy luận rằng toàn bộ dữ liệu là 95% ASCII . Điều đó làm cho nếu khả thi để sử dụng kiểm tra thủ công ...

1. Lập danh sách tất cả các trình tự gobbledegook khác nhau và thay thế hợp lý bắt đầu bằng 0x89dbaa - & gt; '.

2. Sử dụng công cụ hướng byte (ví dụ: sed ) để thực hiện những thay thế.

3. ???

4. Lợi nhuận!