Tại nơi làm việc, dường như không có tuần nào trôi qua mà không có một số thông tin liên quan đến mã hóa, tai họa hoặc thảm họa. Vấn đề thường bắt nguồn từ các lập trình viên nghĩ rằng họ có thể xử lý một cách đáng tin cậy tệp “văn bản” mà không cần chỉ định mã hóa. Nhưng bạn không thể.

Vì vậy, từ đó nó đã được quyết định cấm các tệp có tên kết thúc bằng *.txthoặc *.text. Suy nghĩ là những phần mở rộng đó đánh lừa lập trình viên bình thường thành một sự tự mãn buồn tẻ liên quan đến mã hóa, và điều này dẫn đến việc xử lý không đúng cách. Hầu như sẽ tốt hơn nếu không có phần mở rộng nào cả, bởi vì ít nhất khi đó bạn biết rằng bạn không biết mình có gì.

Tuy nhiên, chúng tôi không muốn đi xa như vậy. Thay vào đó, bạn sẽ phải sử dụng tên tệp kết thúc bằng mã hóa. Vì vậy, cho các tập tin văn bản, ví dụ, đây sẽ là một cái gì đó giống như README.ascii, README.latin1,README.utf8 vv

Đối với các tệp yêu cầu một phần mở rộng cụ thể, nếu người ta có thể chỉ định mã hóa bên trong chính tệp đó, chẳng hạn như trong Perl hoặc Python, thì bạn sẽ làm điều đó. Đối với các tệp như nguồn Java mà không có cơ sở nào như vậy tồn tại bên trong tệp, bạn sẽ đặt mã hóa trước phần mở rộng, chẳng hạn nhưSomeClass-utf8.java .

Đối với đầu ra, UTF-8 phải mạnh mẽ ưa thích.

Nhưng đối với đầu vào, chúng ta cần tìm ra cách xử lý hàng nghìn tệp trong cơ sở mã của chúng ta có tên *.txt . Chúng tôi muốn đổi tên tất cả chúng để phù hợp với tiêu chuẩn mới của chúng tôi. Nhưng chúng ta không thể nhắm mắt lại tất cả. Vì vậy, chúng tôi cần một thư viện hoặc chương trình thực sự hoạt động.

Chúng có nhiều dạng ASCII, ISO-8859-1, UTF-8, Microsoft CP1252 hoặc Apple MacRoman. Mặc dù chúng tôi biết rằng chúng tôi có thể biết liệu thứ gì đó có phải là ASCII hay không và chúng tôi cho rằng một sự thay đổi tốt khi biết liệu thứ gì đó có thể là UTF-8 hay không, chúng tôi vẫn lo lắng về các mã hóa 8 bit. Bởi vì chúng tôi đang chạy trong môi trường Unix hỗn hợp (Solaris, Linux, Darwin) với hầu hết các máy tính để bàn là Mac, chúng tôi có một số tệp MacRoman khá khó chịu. Và những điều này đặc biệt là một vấn đề.

Trong một thời gian, tôi đang tìm cách để xác định theo chương trình

1. ASCII
2. ISO-8859-1
3. CP1252
4. MacRoman
5. UTF-8

có trong tệp và tôi chưa tìm thấy chương trình hoặc thư viện nào có thể phân biệt một cách đáng tin cậy giữa ba bảng mã 8 bit khác nhau đó. Chúng tôi có thể có hơn một nghìn tệp MacRoman, vì vậy bất kỳ bộ dò ký tự nào chúng tôi sử dụng đều phải có khả năng phát hiện ra chúng. Không có gì tôi đã nhìn có thể quản lý được mánh khóe. Tôi đã hy vọng lớn vào thư viện bộ dò mã ICU , nhưng nó không thể xử lý MacRoman. Tôi cũng đã xem xét các mô-đun để làm điều tương tự trong cả Perl và Python, nhưng lặp đi lặp lại nó luôn là một câu chuyện giống nhau: không hỗ trợ phát hiện MacRoman.

Do đó, những gì tôi đang tìm kiếm là một thư viện hoặc chương trình hiện có xác định một cách đáng tin cậy tệp nào trong số năm bảng mã đó — và tốt hơn là nhiều hơn thế. Đặc biệt, nó phải phân biệt giữa ba bảng mã 3 bit mà tôi đã trích dẫn, đặc biệt là MacRoman . Các tập tin có hơn 99% văn bản bằng tiếng Anh; có một số trong các ngôn ngữ khác, nhưng không nhiều.

Nếu đó là mã thư viện, thì tùy chọn ngôn ngữ của chúng tôi dành cho nó là Perl, C, Java hoặc Python và theo thứ tự đó. Nếu nó chỉ là một chương trình, thì chúng tôi không thực sự quan tâm đến ngôn ngữ của nó miễn là nó có nguồn gốc đầy đủ, chạy trên Unix và hoàn toàn không bị cản trở.

Có ai khác gặp vấn đề này với hàng nghìn tệp văn bản kế thừa được mã hóa ngẫu nhiên không? Nếu vậy, bạn đã cố gắng giải quyết nó như thế nào, và bạn đã thành công như thế nào? Đây là khía cạnh quan trọng nhất trong câu hỏi của tôi, nhưng tôi cũng quan tâm đến việc liệu bạn có nghĩ rằng việc khuyến khích các lập trình viên đặt tên (hoặc đổi tên) tệp của họ bằng mã hóa thực tế mà các tệp đó đang sử dụng sẽ giúp chúng tôi tránh được vấn đề trong tương lai hay không. Có ai đã từng cố gắng thực thi điều này trên cơ sở thể chế, và nếu vậy, điều đó có thành công hay không, và tại sao?

Và vâng, tôi hoàn toàn hiểu tại sao người ta không thể đảm bảo một câu trả lời chắc chắn cho bản chất của vấn đề. Điều này đặc biệt xảy ra với các tệp nhỏ, nơi bạn không có đủ dữ liệu để tiếp tục. May mắn thay, các tệp của chúng tôi hiếm khi nhỏ. Ngoài READMEtệp ngẫu nhiên , hầu hết đều có kích thước từ 50k đến 250 nghìn và nhiều tệp lớn hơn. Bất cứ thứ gì có kích thước lớn hơn vài K đều được đảm bảo bằng tiếng Anh.

Miền vấn đề là khai thác văn bản y sinh, vì vậy đôi khi chúng tôi xử lý kho tài liệu rộng lớn và cực kỳ lớn, như tất cả kho lưu trữ Truy cập Mở của PubMedCentral. Một tệp khá lớn là BioThesaurus 6.0, với dung lượng 5,7 gigabyte. Tệp này đặc biệt khó chịu vì nó gần như là UTF-8. Tuy nhiên, một số numbskull đã đi và mắc kẹt một vài dòng trong đó bằng một số mã hóa 8 bit — tôi tin là Microsoft CP1252. Phải mất một khoảng thời gian trước khi bạn đi trên chuyến đó. :(

Đầu tiên, các trường hợp dễ dàng:

ASCII

Nếu dữ liệu của bạn không chứa byte nào trên 0x7F, thì đó là ASCII. (Hoặc mã hóa ISO646 7 bit, nhưng chúng đã rất lỗi thời.)

UTF-8

Nếu dữ liệu của bạn xác thực là UTF-8, thì bạn có thể yên tâm cho rằng đó là UTF-8. Do các quy tắc xác thực nghiêm ngặt của UTF-8, trường hợp dương tính giả là rất hiếm.

ISO-8859-1 so với windows-1252

Sự khác biệt duy nhất giữa hai bảng mã này là ISO-8859-1 có các ký tự điều khiển C1 trong đó windows-1252 có các ký tự có thể in được € ‚ƒ„… † ‡ ˆ ‰ Š ‹ŒŽ ŒŽ ''“ “” • –—˜ ™ š › œžŸ. Tôi đã thấy nhiều tệp sử dụng dấu ngoặc kép hoặc dấu gạch ngang, nhưng không tệp nào sử dụng ký tự điều khiển C1. Vì vậy, thậm chí đừng bận tâm đến chúng, hoặc ISO-8859-1, thay vào đó, chỉ cần phát hiện windows-1252.

Điều đó bây giờ khiến bạn chỉ có một câu hỏi.

Làm thế nào để bạn phân biệt MacRoman với cp1252?

Điều này phức tạp hơn rất nhiều.

Ký tự không xác định

Các byte 0x81, 0x8D, 0x8F, 0x90, 0x9D không được sử dụng trong windows-1252. Nếu chúng xảy ra, thì giả sử dữ liệu là MacRoman.

Nhân vật giống hệt nhau

Các byte 0xA2 (¢), 0xA3 (£), 0xA9 (©), 0xB1 (±), 0xB5 (µ) xảy ra giống nhau trong cả hai bảng mã. Nếu đây là những byte duy nhất không phải ASCII thì bạn chọn MacRoman hay cp1252 cũng không thành vấn đề.

Phương pháp thống kê

Đếm tần số ký tự (KHÔNG phải byte!) Trong dữ liệu bạn biết là UTF-8. Xác định các ký tự thường xuyên nhất. Sau đó, sử dụng dữ liệu này để xác định xem các ký tự cp1252 hoặc MacRoman phổ biến hơn.

Ví dụ, trong một tìm kiếm mà tôi vừa thực hiện trên 100 bài báo ngẫu nhiên trên Wikipedia tiếng Anh, các ký tự không phải ASCII phổ biến nhất là ·•–é°®’èö—. Dựa trên thực tế này,

• Các byte 0x92, 0x95, 0x96, 0x97, 0xAE, 0xB0, 0xB7, 0xE8, 0xE9 hoặc 0xF6 đề xuất windows-1252.
• Các byte 0x8E, 0x8F, 0x9A, 0xA1, 0xA5, 0xA8, 0xD0, 0xD1, 0xD5 hoặc 0xE1 đề xuất MacRoman.

Đếm số byte đề xuất cp1252 và các byte đề xuất của MacRoman và chọn số nào lớn nhất.

Mozilla nsUniversalDetector (Perl bindings: Encode :: Detect / Encode :: Detect :: Detector ) đã được chứng minh hàng triệu lần.

Nỗ lực của tôi trong việc nghiên cứu như vậy (giả sử rằng bạn đã loại trừ ASCII và UTF-8):

• Nếu 0x7f đến 0x9f hoàn toàn không xuất hiện, có thể là ISO-8859-1, vì đó là những mã điều khiển rất hiếm khi được sử dụng.
• Nếu 0x91 đến 0x94 xuất hiện nhiều, có lẽ đó là Windows-1252, vì đó là "dấu ngoặc kép thông minh", cho đến nay các ký tự trong phạm vi đó có nhiều khả năng được sử dụng trong văn bản tiếng Anh. Để chắc chắn hơn, bạn có thể tìm kiếm các cặp.
• Mặt khác, đó là MacRoman, đặc biệt nếu bạn thấy rất nhiều từ 0xd2 đến 0xd5 (đó là nơi chứa các trích dẫn kiểu chữ trong MacRoman).

Lưu ý phụ:

Đối với các tệp như nguồn Java mà không có cơ sở nào như vậy tồn tại bên trong tệp, bạn sẽ đặt mã hóa trước phần mở rộng, chẳng hạn như SomeClass-utf8.java

Đừng làm điều này !!

Trình biên dịch Java mong đợi tên tệp phù hợp với tên lớp, vì vậy việc đổi tên tệp sẽ làm cho mã nguồn không thể biến đổi được. Điều chính xác sẽ là đoán mã hóa, sau đó sử dụng native2asciicông cụ để chuyển đổi tất cả các ký tự không phải ASCII thành chuỗi thoát Unicode .

"Perl, C, Java hoặc Python, và theo thứ tự đó": thái độ thú vị :-)

"Chúng tôi có một sự thay đổi tốt khi biết một thứ gì đó có thể là UTF-8": Trên thực tế, cơ hội mà một tệp chứa văn bản có ý nghĩa được mã hóa trong một số bộ ký tự khác sử dụng các byte được đặt bit cao sẽ giải mã thành công vì UTF-8 là rất nhỏ.

Các chiến lược UTF-8 (bằng ngôn ngữ ít ưu tiên nhất):

# 100% Unicode-standard-compliant UTF-8
def utf8_strict(text):
    try:
        text.decode('utf8')
        return True
    except UnicodeDecodeError:
        return False

# looking for almost all UTF-8 with some junk
def utf8_replace(text):
    utext = text.decode('utf8', 'replace')
    dodgy_count = utext.count(u'\uFFFD') 
    return dodgy_count, utext
    # further action depends on how large dodgy_count / float(len(utext)) is

# checking for UTF-8 structure but non-compliant
# e.g. encoded surrogates, not minimal length, more than 4 bytes:
# Can be done with a regex, if you need it

Khi bạn đã quyết định rằng đó không phải là ASCII hay UTF-8:

Bộ phát hiện bộ mã nguồn gốc Mozilla mà tôi biết không hỗ trợ MacRoman và trong mọi trường hợp không hoạt động tốt trên bộ mã 8-bit, đặc biệt là với tiếng Anh vì AFAICT chúng phụ thuộc vào việc kiểm tra xem liệu giải mã có hợp lý hay không. ngôn ngữ, bỏ qua các ký tự dấu câu và dựa trên nhiều lựa chọn tài liệu bằng ngôn ngữ đó.

Như những người khác đã nhận xét, bạn thực sự chỉ có các ký tự dấu câu được đặt bit cao để phân biệt giữa cp1252 và macroman. Tôi khuyên bạn nên đào tạo một mô hình kiểu Mozilla trên tài liệu của riêng bạn, không phải Shakespeare hay Hansard hoặc KJV Bible và tính đến tất cả 256 byte. Tôi cho rằng các tệp của bạn không có đánh dấu (HTML, XML, v.v.) trong chúng - điều đó sẽ làm sai lệch xác suất một điều gì đó gây sốc.

Bạn đã đề cập đến các tệp chủ yếu là UTF-8 nhưng không giải mã được. Bạn cũng nên rất nghi ngờ về:

(1) các tệp được cho là được mã hóa theo ISO-8859-1 nhưng chứa "ký tự điều khiển" trong phạm vi bao gồm từ 0x80 đến 0x9F ... điều này phổ biến đến mức tiêu chuẩn HTML5 dự thảo yêu cầu giải mã TẤT CẢ các luồng HTML được khai báo là ISO-8859 -1 sử dụng cp1252.

(2) các tệp giải mã OK dưới dạng UTF-8 nhưng Unicode kết quả chứa "ký tự điều khiển" trong phạm vi bao gồm cả U + 0080 đến U + 009F ... điều này có thể là do chuyển mã cp1252 / cp850 (đã thấy nó xảy ra!) / V.v. các tệp từ "ISO-8859-1" đến UTF-8.

Thông tin cơ bản: Tôi có một dự án ướt vào chiều Chủ nhật để tạo một trình phát hiện bộ ký tự dựa trên Python theo hướng tệp (thay vì hướng web) và hoạt động tốt với các bộ ký tự 8 bit bao gồm các bộ ký tự legacy ** nnhư cp850 và cp437. Bây giờ chưa đến giờ chính. Tôi quan tâm đến các tập tin đào tạo; Các tệp ISO-8859-1 / cp1252 / MacRoman của bạn có "không bị cản trở" như bạn mong đợi là giải pháp mã của bất kỳ ai không?

Như bạn đã khám phá ra, không có cách nào hoàn hảo để giải quyết vấn đề này, bởi vì nếu không có kiến ​​thức ngầm hiểu về cách mã hóa tệp sử dụng, thì tất cả các mã hóa 8 bit đều giống hệt nhau: Tập hợp các byte. Tất cả các byte đều hợp lệ cho tất cả các mã hóa 8 bit.

Điều tốt nhất bạn có thể hy vọng là một số loại thuật toán phân tích các byte và dựa trên xác suất của một byte nhất định được sử dụng trong một ngôn ngữ nhất định với một mã hóa nhất định sẽ đoán được mã hóa mà tệp sử dụng. Nhưng điều đó phải biết tệp sử dụng ngôn ngữ nào, và hoàn toàn trở nên vô dụng khi bạn có tệp có mã hóa hỗn hợp.

Mặt khác, nếu bạn biết rằng văn bản trong tệp được viết bằng tiếng Anh, thì bạn sẽ không nhận thấy bất kỳ sự khác biệt nào cho dù bạn quyết định sử dụng mã hóa nào cho tệp đó, vì sự khác biệt giữa tất cả các bảng mã được đề cập đều được bản địa hóa trong các phần của bảng mã chỉ định các ký tự thường không được sử dụng trong ngôn ngữ tiếng Anh. Bạn có thể gặp một số rắc rối khi văn bản sử dụng định dạng đặc biệt hoặc các phiên bản đặc biệt của dấu câu (ví dụ: CP1252 có một số phiên bản của ký tự trích dẫn), nhưng đối với ý chính của văn bản có lẽ sẽ không có vấn đề gì.

Nếu bạn có thể phát hiện mọi mã hóa NGOẠI TRỪ cho macroman, thì sẽ hợp lý hơn nếu giả định rằng những mã không thể giải mã được nằm trong macroman. Nói cách khác, chỉ cần tạo danh sách các tệp không thể xử lý và xử lý chúng như thể chúng là macroman.

Một cách khác để sắp xếp các tệp này là tạo một chương trình dựa trên máy chủ cho phép người dùng quyết định mã hóa nào không bị cắt xén. Tất nhiên, nó sẽ nằm trong công ty, nhưng với 100 nhân viên làm một vài việc mỗi ngày, bạn sẽ có hàng nghìn tệp được hoàn thành nhanh chóng.

Cuối cùng, sẽ không tốt hơn nếu chỉ chuyển đổi tất cả các tệp hiện có sang một định dạng duy nhất và yêu cầu các tệp mới phải ở định dạng đó.

Có ai khác gặp vấn đề này với hàng nghìn tệp văn bản kế thừa được mã hóa ngẫu nhiên không? Nếu vậy, bạn đã cố gắng giải quyết nó như thế nào, và bạn đã thành công như thế nào?

Tôi hiện đang viết một chương trình dịch các tệp sang XML. Nó phải tự động phát hiện loại của mỗi tệp, đây là một phần của bài toán xác định mã hóa của tệp văn bản. Để xác định mã hóa, tôi đang sử dụng phương pháp Bayes. Đó là, mã phân loại của tôi tính xác suất (khả năng xảy ra) mà một tệp văn bản có một mã hóa cụ thể cho tất cả các mã hóa mà nó hiểu được. Sau đó chương trình sẽ chọn bộ giải mã có khả năng xảy ra cao nhất. Cách tiếp cận Bayes hoạt động như vậy cho mỗi mã hóa.

1. Đặt tên ban đầu ( trước xác suất ) để tệp có trong mã hóa, dựa trên tần số của mỗi mã hóa.
2. Lần lượt kiểm tra từng byte trong tệp. Tra cứu giá trị byte để xác định mối tương quan giữa giá trị byte đó hiện có và tệp thực sự nằm trong bảng mã đó. Sử dụng mối tương quan đó để tính toán một xác suất mới ( sau ) mà tệp đó nằm trong mã hóa. Nếu bạn có nhiều byte hơn để kiểm tra, hãy sử dụng xác suất sau của byte đó làm xác suất trước khi bạn kiểm tra byte tiếp theo.
3. Khi bạn xem đến cuối tệp (tôi thực sự chỉ nhìn vào 1024 byte đầu tiên), khả năng bạn có là xác suất tệp đó nằm trong mã hóa.

Nó transpires rằng Bayes' Định lý trở nên rất dễ dàng để làm gì nếu thay vì tính toán xác suất, bạn tính toán nội dung thông tin , đó là logarit của tỷ lệ cược : info = log(p / (1.0 - p)).

Bạn sẽ phải tính toán xác suất ưu tiên không mong muốn và các mối tương quan, bằng cách kiểm tra tập hợp các tệp mà bạn đã phân loại theo cách thủ công.