So sánh văn bản — Diff Checker

Công cụ so sánh văn bản là gì?

Diff Checker (hay còn gọi là công cụ so sánh văn bản) là phần mềm phân tích hai đoạn văn bản và tìm ra sự khác biệt giữa chúng ở mức dòng. Kết quả hiển thị các dòng thêm vào (+), dòng bị xóa (−) và dòng không thay đổi, giúp bạn nhanh chóng nhận diện những gì đã thay đổi mà không cần đọc lại toàn bộ văn bản.

Công cụ này đặc biệt hữu ích trong phát triển phần mềm khi lập trình viên cần so sánh hai phiên bản của cùng một file code. Tuy nhiên, ứng dụng rộng hơn nhiều: so sánh hợp đồng pháp lý, kiểm tra thay đổi trong tài liệu kỹ thuật, debug file cấu hình hoặc phát hiện các thay đổi ngoài ý muốn trước khi triển khai.

Thuật toán so sánh hoạt động như thế nào

ZestLab Diff Checker sử dụng thuật toán LCS (Longest Common Subsequence) — thuật toán tìm chuỗi con chung dài nhất giữa hai văn bản. Đây là nền tảng của hầu hết các công cụ diff hiện đại, bao gồm cả Git.

Thuật toán hoạt động theo hai giai đoạn:

• Giai đoạn 1 — Xây dựng bảng LCS: Chia cả hai văn bản thành mảng các dòng. Dùng quy hoạch động (DP) xây dựng bảng dp[i][j] — độ dài của chuỗi con chung giữa i dòng đầu của văn bản gốc và j dòng đầu của văn bản mới. Độ phức tạp: O(m × n).
• Giai đoạn 2 — Truy vết ngược: Từ dp[m][n], truy vết ngược để xác định từng dòng là "giữ nguyên", "thêm vào" hay "bị xóa".

So với thuật toán Myers diff (được Git dùng), LCS đơn giản hơn nhưng đủ hiệu quả cho các văn bản ngắn đến trung bình. Với file rất lớn (>10.000 dòng), Myers diff nhanh hơn nhờ tối ưu độ phức tạp xuống O(n × d) với d là số lượng khác biệt.

So sánh song song vs hợp nhất (Unified Diff)

Có hai cách hiển thị kết quả diff phổ biến:

ZestLab Diff Checker hiển thị unified diff với số dòng từ cả hai phía — cách tiếp cận cân bằng giữa hai phong cách. Bạn vừa thấy được số dòng gốc và số dòng mới, vừa không cần scroll ngang nhiều.

So sánh diff cho review code

Trong quy trình review code, diff là thông tin quan trọng nhất. Thay vì đọc toàn bộ file, reviewer chỉ cần nhìn vào diff để hiểu thay đổi. Một số nguyên tắc để diff dễ review hơn:

• Commit nhỏ, một mục đích: Mỗi commit chỉ làm một việc — refactor HOẶC thêm feature HOẶC fix bug. Không trộn lẫn.
• Tránh reformatting cùng lúc: Thay đổi format code (thụt lề, trailing comma) tạo ra diff khổng lồ che khuất thay đổi thực. Tách thành commit riêng.
• Đặt tên biến có nghĩa trước khi review: Rename biến cũng tạo diff lớn — làm điều này trước, không để cùng lúc với logic changes.
• Thêm context: PR description nên giải thích "tại sao" thay đổi, không chỉ "là gì". Diff cho biết "là gì", con người cần biết "tại sao".

Lỗi thường gặp khi dùng diff

1. Nhầm lẫn encoding

Cùng một ký tự nhưng file A lưu UTF-8, file B lưu UTF-16 → diff sẽ báo mọi dòng đều khác nhau dù nội dung giống hệt. Giải pháp: luôn chuyển sang UTF-8 trước khi diff.

2. Khoảng trắng vô hình (trailing whitespace)

Dòng có "hello " (thêm space) trông giống "hello" trong editor nhưng diff sẽ đánh dấu khác nhau. Bật "Ignore whitespace" nếu bạn chỉ quan tâm đến nội dung thực sự thay đổi.

3. Line ending khác nhau (CRLF vs LF)

Windows dùng \r\n, Linux/macOS dùng \n. Khi file mở trên hệ điều hành khác nhau và lưu lại, line ending thay đổi → diff toàn bộ file. Cấu hình .gitattributes để chuẩn hóa line ending trong dự án.

4. So sánh file nhị phân bằng text diff

Text diff không có ý nghĩa với file nhị phân (PDF, ảnh, Word). Kết quả sẽ là noise không đọc được. Với binary file, dùng checksum (MD5/SHA256) để kiểm tra nhanh xem có thay đổi không.