Công cụ dành cho nhà phát triển · So sánh văn bản
Mỗi dòng thay đổi? Kết thúc dòng, dấu cách ở cuối và BOM trong một sự khác biệt
· Cách thức hoạt động
text-diff line-endings gỡ lỗi
Chẩn đoán ba nguyên nhân vô hình của sự so sánh, trong đó báo cáo rằng mỗi dòng đều khác nhau và chỉ ra cách nhận biết bạn có nguyên nhân nào trước khi đổ lỗi cho tác giả.
Cùng một tệp, được lưu hai lần, dường như được viết lại - thiết lập trường hợp chung của một tệp được chỉnh sửa trên hai hệ điều hành
Hai lần lưu có thể trông giống như một bản ghi lại khi người chỉnh sửa thay đổi các ký tự ẩn, nhưng hành vi của ToolAcre phụ thuộc vào ký tự nào đã thay đổi. Nó bình thường hóa các kết thúc dòng trước khi khớp, trong khi khoảng trắng ở cạnh dòng và U+FEFF ở đầu vẫn là nội dung dòng thông thường trừ khi tùy chọn khác thay đổi khóa.
Xây dựng một thiết bị chẩn đoán thay vì đoán từ màu sắc. So sánh một cặp chỉ khác nhau ở phần cuối, một cặp khác khác nhau ở dấu cách ở cuối và cặp thứ ba có BOM ở đầu. Các cặp được kiểm soát tiết lộ ranh giới của công cụ một cách đáng tin cậy hơn so với một tệp thực chứa nhiều thay đổi vô hình cùng một lúc.
CRLF so với LF: ký tự ở cuối mỗi dòng - giải thích lý do tại sao Windows kết thúc dòng bằng hai ký tự, Unix bằng một ký tự và cách một khác biệt nhìn thấy dấu đầu dòng bổ sung
`splitLines` thay thế CRLF và CR đơn độc bằng LF, sau đó tách ra. Các thử nghiệm xác định rằng cả ba quy ước đều tạo ra các mảng giống nhau. Do đó, sự khác biệt chỉ CRLF sẽ không hiển thị ngay cả khi tắt Bỏ qua khoảng trắng; tuyên bố của phác thảo rằng mỗi dòng sẽ khác nhau mâu thuẫn với việc triển khai này.
Dòng mới cuối cùng cũng không tạo thêm hàng. Sau khi tách, một mục trống ở đầu cuối sẽ bị xóa. Các dòng trống thực sự ở giữa vẫn là các đơn vị so sánh, do đó hành vi phân biệt quy ước kết thúc tệp với sự phân tách theo chiều dọc có chủ ý bên trong tài liệu.
ToolAcre chuẩn hóa CRLF, CR và LF trước khi so sánh, do đó những thay đổi chỉ ở phần cuối sẽ biến mất
Các khoảng trống ở cuối vẫn còn ở dòng ban đầu. Với sự so sánh thông thường, `name=value` và `name=value ` có các khóa khác nhau. Bỏ qua khoảng trắng cắt cả hai đầu và thu gọn các chạy bên trong, do đó tùy chọn đó có thể làm cho cặp khớp nhau trong khi vẫn giữ văn bản gốc bên trái trong hàng bằng nhau được hiển thị.
Thư viện cũng triển khai tùy chọn `ignoreTrailingWhitespace` hẹp hơn nhưng giao diện người dùng hiện tại không hiển thị tùy chọn đó. Bài viết không được mô tả hộp kiểm mà người dùng không thể chọn. Bảng điều khiển được vận chuyển cung cấp tính năng Bỏ qua trường hợp, Bỏ qua tất cả các khác biệt về khoảng trắng và Thu gọn các lần chạy dài không thay đổi.
Dấu thứ tự byte ở đầu tệp - mô tả ký tự U+FEFF mà một số biên tập viên thêm vào trước tệp UTF-8 và tại sao nó chỉ làm cho dòng đầu tiên khác nhau
Dấu thứ tự byte UTF-8 được giải mã thành văn bản JavaScript là U+FEFF ở đầu dòng đầu tiên. `splitLines` không có thao tác xóa BOM rõ ràng nào. Với cách so khớp thông thường, ký tự đó chỉ có thể tạo ra sự khác biệt ở dòng đầu tiên trong khi các dòng sau vẫn bằng nhau.
Các hoạt động khoảng trắng JavaScript có thể coi U+FEFF là khoảng trắng khi Bỏ qua lệnh gọi khoảng trắng `trim`, nhưng bài viết này không khái quát hóa điều đó thành hành vi giải mã tệp. Trình soạn thảo nhận được chuỗi; nó không đọc byte tệp hoặc mã hóa báo cáo. Kiểm tra ký tự thực tế khi xuất xứ cấp byte có vấn đề.
Ví dụ hoạt động: phân biệt ba nguyên nhân — đưa ra đường dẫn quyết định: điểm khác biệt chỉ ở dòng đầu tiên dẫn đến BOM, mọi dòng đều trỏ đến phần cuối, các dòng rải rác trỏ đến dấu cách ở cuối
Bắt đầu với `alpha beta` and `alpha beta`: the result is identical. Next compare `alpha beta` with `alpha beta`: chế độ thông thường báo cáo các hàng thay thế, trong khi chế độ khoảng trắng khớp với chúng. Cuối cùng, thêm tiền tố alpha của một bên vào U+FEFF và quan sát hiệu ứng dòng đầu tiên.
Trình tự đó phân tách các nguyên nhân bằng cách sử dụng các hoạt động đã được kho lưu trữ chứng minh. Nếu mỗi dòng vẫn khác nhau sau khi kết thúc quá trình chuẩn hóa, hãy điều tra nội dung, dấu thụt lề hoặc ký tự ở cuối thay vì chỉ đổ lỗi cho CRLF. Nếu chỉ có dòng một khác nhau, hãy kiểm tra các điểm mã hàng đầu của nó trước khi viết lại toàn bộ tệp.
Sử dụng tùy chọn khoảng trắng làm chẩn đoán - cho thấy cách bật khoảng trắng bỏ qua trong So sánh văn bản của ToolAcre có thể hấp thụ tiếng ồn ở cuối dòng và dấu cách ở cuối để các chỉnh sửa thực sự nổi bật
Bỏ qua khoảng trắng rất hữu ích cho tiếng ồn ở cuối dấu cách vì nó cắt bớt và thu gọn các phím dòng. Nó không chịu trách nhiệm ẩn CRLF so với LF; điều đó đã xảy ra trong quá trình chia tách. Việc tách biệt các giai đoạn đó sẽ ngăn ngừa kết luận sai lệch về lựa chọn nào đã sửa chữa được sự so sánh.
Chạy cả hai chế độ xem vì việc cắt xén có thể ẩn phần thụt lề có ý nghĩa và việc thu gọn có thể thay đổi các giá trị có độ rộng cố định hoặc chuỗi ký tự bằng chữ. Một kết quả được chuẩn hóa yên tĩnh cho biết các phím khớp với phép chuyển đổi đó. Nó không chứng nhận rằng các tệp gốc giống hệt byte hoặc có thể hoán đổi cho nhau về mặt ngữ nghĩa.
Chế độ khoảng trắng chẩn đoán dấu cách ở cuối, trong khi phần cuối dòng đã được chuẩn hóa
Text diff không chuyển đổi tệp, định cấu hình Git, thay đổi cài đặt trình chỉnh sửa hoặc hiển thị byte thập lục phân. Nó chấp nhận các chuỗi đã dán và báo cáo các hoạt động của dòng. Lời khuyên về `.gitattributes`, `core.autocrlf` hoặc sửa chữa mã hóa thuộc về các công cụ có hành vi có thể được xác minh riêng.
Công cụ này cũng không thể phân biệt cách một ký tự vô hình nhập vào văn bản. Bộ định dạng, khay nhớ tạm, bộ giải mã hoặc chỉnh sửa thủ công có thể tạo ra cùng một chuỗi. Sử dụng so sánh để xác định vị trí hàng, sau đó kiểm tra quy trình nguồn trước khi chỉ định nguyên nhân.
Bài học rút ra: kiểm tra phần ẩn trước khi đổ lỗi cho tác giả — tóm tắt đường dẫn chẩn đoán và ghi chú quá trình so sánh chạy trong trình duyệt của bạn, để các tệp nhạy cảm vẫn ở trên máy của bạn
Kiểm tra các phần vô hình theo thứ tự cố định: phần cuối, dấu cuối hoặc khoảng trắng bên trong, sau đó là các ký tự đặc biệt ở đầu. Các thử nghiệm của ToolAcre đưa ra kết quả chắc chắn cho danh mục đầu tiên và các tùy chọn của nó giúp tách biệt danh mục thứ hai. Người thứ ba có thể cần một người kiểm tra nhân vật bên ngoài tuyến đường này.
Sự phân chia dòng phía trình duyệt làm cho sự khác biệt về kết thúc giữa các nền tảng biến mất theo thiết kế. Điều đó thật tiện lợi nhưng cũng có nghĩa là công cụ này không thể chứng minh hai tệp nguồn sử dụng cùng một byte dòng mới vật lý. Chọn một tiện ích nhận biết byte khi yêu cầu phải bảo quản một dây hoặc kho lưu trữ chính xác.