So sánh Hex File

Giới thiệu So sánh Hex File

So sánh Hex File là công cụ diff cấp byte cho file nhị phân. Nó đọc tối đa 64 KB đầu mỗi file và hiển thị song song theo định dạng hex-dump kinh điển mà `od -x` của Unix khởi xướng và HxD phổ biến: cột offset bên trái dạng hex, 16 byte mỗi dòng dưới dạng cặp hai ký tự hex, và bên phải là cột ASCII nơi các byte in được (0x20–0x7E) hiện ra dưới dạng ký tự, phần còn lại hiển thị bằng dấu chấm. Các dòng khác nhau giữa hai file được tô sáng; khi bật "Chỉ hiển thị dòng khác nhau", các dòng giống nhau bị thu gọn — quét 64 KB rút lại còn một nhúm byte đáng quan tâm. Ứng dụng chuyên nghiệp phổ biến: xác minh bản vá nhị phân được áp dụng sạch (so sánh trước/sau, đếm chênh lệch, đối chiếu offset với manifest patch), kỹ thuật ngược firmware (diff hai phiên bản để phát hiện thay đổi ở bootloader hoặc bảng chuỗi), pháp y file (so sánh bản nghi ngờ hỏng với bản tốt để tìm biên hỏng), và xác thực file tải về có checksum lệch khi bạn muốn xem *byte nào* lệch chứ không chỉ biết là lệch. Việc so sánh chạy hoàn toàn trong trình duyệt qua API FileReader và walker DataView trên typed array — file của bạn không rời thiết bị, kể cả analytics.

So sánh được bao nhiêu và vì sao giới hạn 64 KB?

Tối đa 64 KB (65 536 byte) từ đầu mỗi file. Giới hạn này là lựa chọn UX chứ không phải hạn chế kỹ thuật: vẽ hơn ~4 000 dòng hex trong bảng DOM bắt đầu chậm trên điện thoại, và phần lớn pháp y nhị phân thực tế xảy ra ở những KB đầu — header, magic number, signature, blob chứng chỉ, metadata ELF/PE/Mach-O và entry point của patch đều nằm gần đầu file. Cho diff sâu ở cuối file (log rolling, payload mã hóa nối thêm), hãy dùng công cụ máy tính như HxD, 010 Editor, GHex (Linux), hoặc `cmp -l file_a file_b` trên Unix — chạy stream cả file và báo cáo mọi byte lệch ở dạng octal.

So sánh thế nào với `diff`, `cmp`, `git diff` và `vbindiff`?

`diff` định hướng theo dòng và mặc định UTF-8 hoặc ASCII; chạy với nhị phân cho kết quả vô nghĩa. `cmp -l a b` theo byte nhưng cho danh sách phẳng (offset, byte_a, byte_b ở octal), không có ngữ cảnh — chính xác mà khó đọc. `git diff --binary` chỉ encode delta patch, không hiển thị dễ nhìn. `vbindiff` (Visual Binary Diff) là tương đương gần nhất và là nguồn cảm hứng cho công cụ này: hex view hai khung cuộn đồng bộ, cột ASCII và các dòng lệch tô sáng. Khác biệt là vbindiff chạy trên terminal; công cụ này chạy trên trình duyệt, hỗ trợ kéo thả, không cần cài đặt. Với file siêu lớn hoặc kiểm tra CI bằng script, hãy ưu tiên `cmp -l` đường ống vào `wc -l` để đếm chênh lệch nhanh, hoặc `radiff2 -x` (trình diff hex của radare2) cho đầu ra có cấu trúc.

Vì sao có byte hiện thành dấu chấm dù trông như chữ cái?

Cột ASCII tuân thủ vùng in được nghiêm ngặt 0x20–0x7E (space đến tilde), quy ước từ `od -c` POSIX gốc và `hexdump` BSD. Mọi byte ngoài vùng đó được thay bằng một dấu chấm để giữ mỗi dòng đúng 16 ký tự cho căn cột. Nghĩa là: tab (0x09), newline (0x0A), null (0x00), tất cả byte 0x80–0xFF (ASCII mở rộng và byte tiếp nối UTF-8) và DEL (0x7F) đều hiện là dấu chấm. Nếu bạn cần thấy chữ UTF-8 nhúng trong file (tên file trong ZIP, chuỗi trong binary Mach-O, JSON trong blob được wrap), copy offset rồi mở file bằng trình xem nhận diện UTF-8 như 010 Editor, hoặc dùng `strings file | grep` để trích chuỗi nhanh.

Những magic number quan trọng nhất cần biết là gì?

Vài byte đầu của hầu hết định dạng file khai báo nó là gì — biết các magic này biến hex-diff thành hoạt động ý thức định dạng. Magic số quan trọng (byte từ 0x00): PNG 89 50 4E 47 0D 0A 1A 0A, JPEG FF D8 FF (rồi E0/E1/E2/E3/DB cho JFIF/EXIF/...), GIF 47 49 46 38 ("GIF8"), PDF 25 50 44 46 ("%PDF"), ZIP/JAR/DOCX/XLSX 50 4B 03 04 ("PK\03\04"), RAR4 52 61 72 21 1A 07 00, RAR5 52 61 72 21 1A 07 01 00, 7Z 37 7A BC AF 27 1C, GZIP 1F 8B, BZIP2 42 5A 68 ("BZh"), ELF (executable Linux) 7F 45 4C 46 ("\x7FELF"), Windows PE/EXE 4D 5A ("MZ") với con trỏ PE header ở offset 0x3C, Mach-O (macOS) FE ED FA CE/CF hoặc CE/CF FA ED FE, WAV 52 49 46 46 ("RIFF") rồi "WAVE", MP4 bắt đầu bằng byte kích thước rồi 66 74 79 70 ("ftyp") ở offset 4, SQLite 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00. Nếu hex của bạn bắt đầu khác đi thì file đã bị mã hóa, nén hoặc hỏng.

Làm sao nhận ra patch nhị phân (cập nhật DLL/EXE, delta firmware) trên diff hex?

Patch nhị phân thường gom thay đổi vào vài vùng nhỏ chứ không trải đều. Bật "Chỉ khác biệt" rồi nhìn khoảng cách offset của các dòng lệch: bản vá phần mềm (bảo mật, fix bug) thường đụng một đến ba dải ngắn 4–64 byte trong section .text hoặc .rdata (PE Windows) hoặc segment .text và .rodata (ELF), tương ứng với patch chỉ thị cụ thể hoặc cập nhật hằng số. Bản cập nhật firmware bao trùm vùng rộng hơn, thường gồm checksum hoặc signature ở cuối. Bump version chuỗi xuất hiện như thay đổi ASCII liền kề (ví dụ '1.0.4' thành '1.0.5' ở offset ổn định). Nếu diff đều — mọi dòng đều khác — thì hai file không liên quan hoặc một bên được mã hóa với khóa khác. Nếu diff trùng ở đầu rồi đột ngột khác đều từ một offset, bạn đã bắt được ranh giới tải về hỏng hoặc bị cắt cụt.

Big-endian và little-endian khác nhau thế nào trong hex dump?

Endianness là thứ tự lưu các giá trị đa byte (số nguyên 16, 32, 64 bit). Little-endian (Intel x86, AMD64, ARM mặc định) lưu byte ít quan trọng nhất trước: giá trị 32 bit 0x12345678 xuất hiện trong dump là 78 56 34 12. Big-endian (thứ tự mạng theo RFC 1700, PowerPC cổ điển, SPARC, m68k, hầu hết header file như PNG và JPEG, header IP/TCP trên dây) lưu byte quan trọng nhất trước: cùng giá trị xuất hiện là 12 34 56 78. Khi so sánh hai binary build cho kiến trúc khác nhau, cái trông như diff khổng lồ có thể chỉ là đổi endianness. Cách kiểm nhanh: hầu hết header file (PNG, ZIP, ELF, PDF) nhúng kích thước hoặc signature ở endianness đã biết, nên nếu hex bắt đầu bằng magic number đúng thứ tự thì bạn đang đọc đúng cách.

Vì sao file trùng nhau khi lẽ ra phải khác (hoặc ngược lại)?

Ba bẫy thường gặp. Thứ nhất, BOM hoặc dấu xuống dòng — file lưu CRLF (Windows) so với LF (Unix) khác nhau ở mọi byte xuống dòng; công cụ sẽ báo trung thực rất nhiều diff nhỏ ở nơi nội dung logic giống nhau. Thứ hai, timestamp nhúng — nhiều định dạng (ZIP, DOCX, PDF, executable có debug info, PNG có chunk creation time) nhúng ngày tạo/sửa trong nhị phân, nên hai file biên dịch từ cùng mã nguồn chỉ cách vài phút sẽ khác ở các offset đó. Thứ ba, tính không xác định của nén — gzip, ZIP, PDF có thể cho byte khác nhau cho cùng input tùy mức nén, trạng thái dictionary, hoặc phiên bản thư viện; để so sánh nội dung logic, hãy giải nén cả hai trước. Loại bớt diff vụn vặt bằng `dos2unix file`, `strip-nondeterminism --type=zip` cho timestamp, và giải nén trước khi so sánh.

File của tôi có bị tải lên server hay lưu lại không?

Không. Diff chạy hoàn toàn trong trình duyệt. Mỗi file được đọc qua FileReader.readAsArrayBuffer vào một Uint8Array, duyệt từng byte trong vòng lặp gọn trên main thread (nhường lại qua microtask mỗi 4 KB để UI vẫn mượt), và các dòng hex kết quả được render dạng DOM thuần. Không có nội dung, tên file, offset hay thống kê diff nào được gửi đến server, ghi log analytics, hoặc lưu localStorage. Mở tab Network của DevTools trước khi bấm So Sánh — bạn sẽ thấy không có request mới nào trong lúc so sánh và không có request nào mang nội dung file trong lúc render. Đóng tab là xóa sạch mọi buffer.