Cách máy tính nhận diện loại file: Giải thích về Magic Bytes
Tại sao phần mở rộng file chỉ là một nửa câu chuyện
Hầu hết mọi người cho rằng máy tính biết một file là JPEG vì nó có đuôi .jpg. Đây là một suy đoán hợp lý, nhưng nó lại sai trong khoảng một nửa số trường hợp. Phần mở rộng file chỉ là một quy ước đặt tên. Chúng là một gợi ý cho hệ điều hành, chứ không phải là sự đảm bảo về những gì bên trong. Đổi tên một file PNG thành .txt, và Windows sẽ vui vẻ cố mở nó bằng Notepad, hiển thị cho bạn một màn hình toàn ký tự vô nghĩa. Hãy thử mở một tài liệu Word mà bạn đã đổi tên thành .pdf, và Adobe Acrobat sẽ thẳng thừng từ chối. Điều này cực kỳ quan trọng đối với việc chuyển đổi file. Khi bạn tải một file lên một dịch vụ như CocoConvert, hệ thống không thể chỉ tin vào phần mở rộng. Ai đó có thể đổi tên một file thực thi độc hại (.exe) thành .jpg để lọt qua một trình xử lý file đơn giản. Hoặc, phổ biến hơn, một người dùng có thể vô tình lưu một file với phần mở rộng sai. Tất cả chúng ta đều đã từng thấy các file download bị lỗi làm mất hoàn toàn siêu dữ liệu phần mở rộng. Giải pháp, đã được thống nhất từ nhiều thập kỷ trước, là bỏ qua tên file và đọc nội dung nhị phân thực sự của file. Cụ thể, một chương trình sẽ đọc vài byte đầu tiên và so sánh chúng với một cơ sở dữ liệu các chữ ký đã biết. Những chữ ký này được gọi là magic bytes, hay chính thức hơn là chữ ký file. Chúng là sự thật không thể chối cãi về nội dung của một file, bất kể tên của nó là gì.
Magic Bytes thực chất là gì
Mọi định dạng file tiêu chuẩn đều dành riêng vài byte đầu tiên của nó cho một mã định danh duy nhất. Các byte này, được viết dưới dạng thập lục phân (hexadecimal), được tích hợp sẵn vào trong đặc tả của định dạng—chúng không được hệ điều hành thêm vào sau này. Bạn có thể tự mình xem những byte này bằng một trình chỉnh sửa hex. Hãy xem một vài loại file phổ biến: - **Ảnh JPEG** luôn bắt đầu bằng FF D8 FF. Hai byte đầu tiên (FF D8) đánh dấu sự bắt đầu của luồng dữ liệu, và byte thứ ba (FF) bắt đầu đoạn đánh dấu đầu tiên. - **Ảnh PNG** bắt đầu bằng một chữ ký 8 byte: 89 50 4E 47 0D 0A 1A 0A. Lưu ý phần 50 4E 47 là mã ASCII của 'PNG'. - **File PDF** bắt đầu bằng 25 50 44 46, là mã ASCII của '%PDF'. Bạn có thể mở bất kỳ file PDF nào trong một trình soạn thảo văn bản thuần túy và thấy điều này ngay ở trên cùng. - **File nén ZIP** bắt đầu bằng 50 4B 03 04. Đây là 'PK' trong mã ASCII, viết tắt cho Phil Katz, người tạo ra định dạng này. Bởi vì các file DOCX, XLSX, PPTX và JAR đều dựa trên ZIP, chúng đều có chung chữ ký này. - **File âm thanh MP3** thường bắt đầu bằng FF FB hoặc FF F3, là từ đồng bộ hóa MPEG (MPEG sync word). - **File EXE** trên Windows bắt đầu bằng 4D 5A—'MZ' trong mã ASCII, viết tắt cho Mark Zbikowski, một trong những kiến trúc sư ban đầu của MS-DOS. Tên gọi 'magic bytes' xuất phát từ tiện ích `file` của Unix, vốn đã sử dụng một cơ sở dữ liệu gọi là `/etc/magic` (hoặc `/usr/share/misc/magic` trên các hệ thống hiện đại) từ những năm 1970. Khi bạn chạy `file photo.jpg` trong terminal, tiện ích này sẽ đọc các byte mở đầu, tham chiếu cơ sở dữ liệu của nó và cho bạn biết loại file thực sự, hoàn toàn bỏ qua phần mở rộng .jpg.
Phần mềm nhận dạng đọc chữ ký file như thế nào
Về nguyên tắc, việc đọc magic bytes rất đơn giản. Nhưng trên thực tế, các trường hợp ngoại lệ sẽ làm bạn đau đầu. Quá trình cơ bản bao gồm việc mở file dưới dạng một luồng nhị phân thô, đọc một bộ đệm nhỏ—thường là 512 byte đầu tiên—và so sánh bộ đệm đó với một danh sách các chữ ký đã biết. Tuy nhiên, một số định dạng yêu cầu đọc sâu hơn nhiều. Việc so sánh không phải lúc nào cũng là một phép so khớp tiền tố đơn giản. Một số định dạng đặt chữ ký của chúng ở một độ lệch (offset) cố định. Ví dụ, định dạng ảnh đĩa ISO có chữ ký 'CD001' bắt đầu ở byte thứ 32,769. Các file ZIP có thể có thư mục trung tâm ở cuối file, buộc một số trình nhận dạng phải quét từ cuối thay vì từ đầu. Các thư viện hiện đại như Apache Tika (Java), python-magic (Python) và libmagic (C) xử lý sự phức tạp này. Chỉ riêng Apache Tika đã biết hơn 1.300 loại file, nhận dạng các kiểu MIME, bảng mã ký tự, và cả siêu dữ liệu nhúng. Tại CocoConvert, chúng tôi sử dụng nhận dạng chữ ký phía máy chủ như lớp phòng thủ đầu tiên. Nếu kiểu MIME mà trình duyệt của bạn khai báo không khớp với những gì chữ ký nhị phân cho biết, file đó sẽ bị gắn cờ để xem xét kỹ hơn trước khi bất kỳ quá trình chuyển đổi nào bắt đầu. Các định dạng chứa (container formats) làm mọi thứ trở nên phức tạp hơn. Một file DOCX và một file JAR đều bắt đầu bằng 50 4B 03 04 vì chúng đều là file nén ZIP. Để phân biệt chúng, phần mềm phải xem xét sâu hơn bên trong file nén để tìm các file cụ thể, như [Content_Types].xml đối với DOCX hoặc META-INF/MANIFEST.MF đối với JAR. Việc nhận dạng hai lượt này là tiêu chuẩn cho bất kỳ quy trình xử lý file nghiêm túc nào.
Khi nào Magic Bytes thất bại (Và chúng có thất bại thật)
Magic bytes rất đáng tin cậy, nhưng chúng không phải là không bao giờ sai. Một vài kịch bản trong thế giới thực có thể làm cho việc nhận dạng dựa trên chữ ký bị vấp và cho bạn câu trả lời sai hoặc không rõ ràng. **File bị cắt cụt** là một vấn đề đau đầu thường trực. Nếu một quá trình download bị gián đoạn, bạn có thể có một file với phần đầu (header) JPEG hợp lệ nhưng không có dữ liệu hình ảnh thực tế. Việc kiểm tra chữ ký thành công, nhưng quá trình chuyển đổi lại thất bại sau đó khi bộ giải mã mong đợi một hình ảnh hoàn chỉnh và chỉ tìm thấy một mảnh vỡ. **File được tạo ra có chủ đích** có thể khai thác thực tế là magic bytes chỉ bao gồm phần đầu. Một file có thể có phần đầu PNG hợp lệ theo sau là một payload độc hại. Đây là một vector tấn công đã biết được gọi là file đa ngữ (polyglot file)—một file nhị phân duy nhất đồng thời hợp lệ dưới dạng hai loại file khác nhau. Các nhà nghiên cứu đã tạo ra các file polyglot JPEG/JavaScript mà một trình duyệt sẽ thực thi như một script trong khi một trình xem ảnh hiển thị nó như một bức ảnh. Chỉ riêng việc nhận dạng chữ ký sẽ không phát hiện được những trường hợp này. **Xung đột phiên bản định dạng** tạo ra một lớp mơ hồ khác. Trước năm 2007, các file Microsoft Office (DOC, XLS, PPT) sử dụng Định dạng File Nhị phân Hợp chất (Compound Document Binary Format), bắt đầu bằng D0 CF 11 E0 A1 B1 1A E1. Cả ba định dạng đều có chung một chữ ký giống hệt nhau. Bạn không thể phân biệt một file .doc với .xls hay .ppt bằng magic bytes; bạn phải phân tích cấu trúc bên trong. **Các định dạng văn bản thuần túy** như CSV, JSON, XML, HTML và Markdown hoàn toàn không có magic bytes. Chúng chỉ là các chuỗi ký tự. Việc nhận dạng ở đây dựa vào phân tích theo kinh nghiệm (heuristic analysis): tìm kiếm các mẫu như dấu ngoặc nhọn (HTML/XML) hoặc dấu ngoặc móc (JSON). Những phương pháp này có thể sai. Bất cứ ai đã từng vật lộn với một file 'CSV' dùng dấu chấm phẩy thay vì dấu phẩy đều biết rõ nỗi đau này. Nếu CocoConvert không thể tự tin xác định một loại file, nó sẽ báo cho bạn biết. Chúng tôi nghĩ rằng việc trả về một lỗi rõ ràng sẽ hữu ích hơn nhiều so với việc đoán mò và tạo ra một file bị hỏng.
Hệ quả thực tế đối với việc chuyển đổi file
Vậy điều này giúp bạn như thế nào? Nó hoàn toàn thay đổi cách bạn xử lý sự cố khi chuyển đổi thất bại. Khi một dịch vụ báo cáo 'định dạng file không được hỗ trợ hoặc không nhận dạng được', vấn đề gần như không bao giờ nằm ở phần mở rộng tên file. Vấn đề nằm ở nội dung. Đây là những thủ phạm phổ biến nhất và cách xử lý chúng: **File có định dạng khác với bạn nghĩ.** Điều này xảy ra rất nhiều với các file xuất từ các công cụ thiết kế. Figma, chẳng hạn, có thể xuất một file được dán nhãn .jpg nhưng thực chất lại là PNG. Cách tốt nhất của bạn là mở file trong một trình chỉnh sửa hex (như HxD trên Windows hoặc Hex Fiend trên macOS) và kiểm tra vài byte đầu tiên. Nếu bạn thấy 89 50 4E 47, đó là một file PNG, bất kể tên là gì. Hãy đổi tên nó và thử lại. **File được bảo vệ bằng mật khẩu hoặc khóa DRM.** Các tài liệu Office được mã hóa vẫn bắt đầu bằng D0 CF 11 E0, vì vậy việc kiểm tra chữ ký vẫn thành công. Nhưng nội dung bên trong là bản mã. CocoConvert không thể giải mã các file được bảo vệ bằng mật khẩu. Đừng nhầm lẫn đây là một hạn chế của dịch vụ; đó là một tính năng bảo mật cơ bản của chính việc mã hóa. **File là một định dạng chứa nhưng có nội dung sai.** Một file được tạo ra bằng cách đổi tên một file .zip thông thường thành .docx sẽ có chữ ký đúng (50 4B), nhưng nó sẽ thất bại khi chuyển đổi vì thiếu cấu trúc XML xử lý văn bản của Word bên trong. Trình chuyển đổi mở file nén, không tìm thấy gì để làm việc, và bỏ cuộc. **Không khớp codec trong file video.** Một container MKV (bắt đầu bằng 1A 45 DF A3) có thể chứa video được mã hóa bằng H.264, H.265, AV1, VP9, hoặc hàng tá codec khác. Magic bytes xác nhận container MKV, chứ không phải codec của luồng video. Nếu CocoConvert hỗ trợ MKV nhưng file của bạn sử dụng một codec ít phổ biến như RealVideo 4, việc nhận dạng ban đầu sẽ thành công nhưng bước chuyển mã (transcoding) sẽ thất bại.
Cách kiểm tra loại file thực sự mà không cần phần mềm chuyên dụng
Bạn không cần cài đặt phần mềm chuyên dụng để xác minh danh tính thực sự của một file. Những phương pháp này hoạt động trên mọi hệ điều hành lớn bằng các công cụ bạn đã có sẵn. **Trên Windows:** Mở PowerShell và chạy `Format-Hex -Path 'C:\path\to\yourfile.ext' | Select-Object -First 3`. Lệnh này in ra 48 byte đầu tiên dưới dạng thập lục phân. So sánh hàng byte đầu tiên với các chữ ký được liệt kê ở đầu bài viết này. **Trên macOS và Linux:** Mở Terminal và chạy `xxd yourfile | head -3`. Lệnh này hiển thị độ lệch byte, giá trị hex, và biểu diễn ASCII. Tốt hơn nữa, chỉ cần chạy `file yourfile`. Tiện ích `file` được tích hợp sẵn và cho bạn một câu trả lời rõ ràng, dễ đọc ngay lập tức. **Trong trình duyệt, không cần công cụ nào:** Nếu bạn đang ở trên một máy tính bị khóa quyền mà không thể chạy lệnh, hãy truy cập trang nhận dạng của CocoConvert tại cocoConvert.com/detect. Tải file lên, và dịch vụ của chúng tôi sẽ báo cáo kiểu MIME được phát hiện, các byte chữ ký mà nó khớp, và mức độ tin cậy. **Bằng Python (dành cho lập trình viên):** Sau khi `pip install python-magic`, bạn có thể chạy `import magic; print(magic.from_file('yourfile', mime=True))`. Lệnh này trả về một kiểu MIME tiêu chuẩn như `image/jpeg`. Tuy nhiên, lời khuyên của tôi cho code Python trong môi trường production là nên dùng thư viện `filetype`. Nó không có các phụ thuộc hệ thống, giúp việc triển khai trên Windows dễ dàng hơn nhiều mà không cần vật lộn với các file DLL của libmagic. Biết được kiểu MIME thực sự trước khi bạn tải lên sẽ tiết kiệm rất nhiều thời gian. Nếu loại file được phát hiện không có trong danh sách định dạng đầu vào được hỗ trợ của dịch vụ, bạn sẽ biết ngay rằng việc chuyển đổi sẽ thất bại.
Giới hạn mà bất kỳ dịch vụ chuyển đổi nào có thể hứa hẹn
Nhận dạng magic byte là một bài toán đã có lời giải cho khoảng 200 định dạng file chiếm 99% các trường hợp sử dụng hàng ngày. Nhưng đối với phần đuôi dài của các định dạng chuyên dụng, độc quyền hoặc cũ, không có dịch vụ nào—kể cả CocoConvert—có thể hứa hẹn hỗ trợ hoàn toàn. Các định dạng như Autodesk DWG cho bản vẽ CAD, các biến thể hình ảnh y tế độc quyền từ các thương hiệu máy quét cụ thể, hoặc các định dạng âm thanh chuyên biệt từ những bộ tổng hợp âm thanh cổ thường có tài liệu mở kém hoặc không có. Ngay cả khi đã biết magic bytes, cấu trúc bên trong có thể là một hộp đen. Một trình chuyển đổi có thể tạo ra đầu ra bị thiếu dữ liệu, sai màu, hoặc mất các lớp siêu dữ liệu. Tại thời điểm viết bài này, CocoConvert hỗ trợ khoảng 300 định dạng đầu vào. Mặc dù nghe có vẻ nhiều, sổ đăng ký PRONOM của Thư viện Quốc hội Hoa Kỳ ghi nhận hơn 2.000 định dạng file riêng biệt. Khoảng cách đó đại diện cho các định dạng quá ít phổ biến để đầu tư công sức kỹ thuật, bị ràng buộc pháp lý bởi bằng sáng chế, hoặc có tài liệu quá sơ sài đến nỗi bất kỳ nỗ lực chuyển đổi nào cũng sẽ là một canh bạc. Khuyến nghị của tôi là: nếu bạn làm việc trong các ngành như hình ảnh y tế, dữ liệu không gian địa lý, hoặc video chuyên nghiệp, bạn phải xác minh việc hỗ trợ định dạng trước khi cam kết với một quy trình chuyển đổi. Hãy kiểm tra trang hỗ trợ định dạng của CocoConvert. Trang này liệt kê mọi đầu vào và đầu ra được hỗ trợ, cùng với các ghi chú về những hạn chế đã biết. Tốt hơn là kiểm tra trước còn hơn là tải lên một file gốc phát sóng 4GB chỉ để phát hiện ra biến thể MXF cụ thể của nó không được hỗ trợ. Magic bytes cho máy tính biết một file *là gì*. Chúng không cho biết liệu việc chuyển đổi file đó có tạo ra thứ gì đó *hữu ích* hay không. Câu hỏi thứ hai, quan trọng hơn đó, phụ thuộc vào tài liệu tốt, giấy phép rõ ràng, và công sức kỹ thuật chuyên dụng mà không có lượng phân tích byte thông minh nào có thể thay thế được.