Công cụ dành cho nhà phát triển · So sánh văn bản
Tại sao Windows và Unix không đồng ý về kết thúc dòng: Câu chuyện CR, LF và CRLF
· Lý lịch
text-diff line-endings software-history
Theo dõi các kết thúc dòng từ máy đánh chữ và máy điện báo cho đến các hệ điều hành hiện đại và giải thích lý do tại sao hai quy ước vẫn cùng tồn tại trong mọi dự án đa nền tảng.
Một nhân vật vô hình, xung đột kéo dài hàng thập kỷ — mở đầu với sự khó chịu dai dẳng trên nhiều nền tảng
Phần cuối dòng không thể nhìn thấy được trong các trình soạn thảo thông thường nhưng có thể quan trọng đối với các tệp và giao thức. Tuy nhiên, trong ToolAcre, CR, LF và CRLF được chuẩn hóa trước khi so sánh dòng. Một cặp chỉ khác nhau ở các dấu phân cách đó sẽ tạo ra cùng một mảng dòng và cho kết quả giống hệt nhau.
Hành vi đó giải quyết câu hỏi thực tế cho tuyến đường này trong khi hạn chế những gì nó có thể chẩn đoán. Việc so sánh không thể chứng minh được byte dòng mới nào chứa trong tệp gốc sau khi văn bản đến tay người chỉnh sửa. Cần có một công cụ nhận biết byte để bảo quản hoặc kiểm tra giao thức.
Vận chuyển trở lại và nạp dòng trên máy đánh chữ - giải thích hai hành động vật lý mà các nhân vật được mô tả ban đầu
Các thuật ngữ trả về đầu dòng và nguồn cấp dữ liệu dòng có ý nghĩa vật lý và lịch sử, nhưng kho lưu trữ không chứa nguồn máy đánh chữ. Việc lặp lại một câu chuyện có nguồn gốc máy móc từ trí nhớ sẽ vi phạm hợp đồng bằng chứng ngay cả khi câu chuyện nghe có vẻ quen thuộc.
Do đó bài viết này coi CR là ` ` code unit and LF as ` ` chỉ khi quá trình triển khai sử dụng chúng. Phần giải thích về lịch sử nên được bổ sung sau từ các tiêu chuẩn cơ bản hoặc từ các kho lưu trữ thay vì mượn từ một dàn ý rõ ràng không phải là nguồn.
Ý nghĩa của máy đánh chữ là những khẳng định mang tính lịch sử cần có nguồn bên ngoài
Tương tự như vậy, các tệp nguồn không ghi lại các quy ước về điện báo hoặc các quyết định ban đầu của hệ điều hành. Chúng chỉ tiết lộ lựa chọn tương thích trong JavaScript hiện tại: thay thế mọi CRLF hoặc CR đơn độc bằng LF trước khi tách.
Phép chuyển đổi đó chấp nhận văn bản được dán được tạo theo một số quy ước mà không điền vào đầu ra những thay đổi chỉ ở phần cuối. Đó là một quyết định triển khai hiển thị trong một biểu thức chính quy và được ghim bằng các thử nghiệm cho cả ba biểu mẫu.
Teletype và dòng hệ điều hành là bằng chứng bên ngoài kho lưu trữ
Người ta thường liên kết Unix với LF, Windows với CRLF và các hệ thống cũ hơn với CR đơn độc, nhưng kho lưu trữ hiện tại không thể đóng vai trò là bằng chứng lịch sử về những áp dụng đó. Xác nhận an toàn đang hoạt động: cả ba đầu vào đều trở thành LF bên trong `splitLines`.
Terminal LF không tạo ra hàng trống cuối cùng, trong khi các dòng trống ở giữa vẫn được giữ nguyên. Sự khác biệt này có nghĩa là nội dung logic được giữ lại ngay cả khi những khác biệt về dấu phân cách vật lý bị xóa. Việc so sánh được định hướng theo dòng, không bảo toàn byte.
Mã chứng minh ba quy ước được chuẩn hóa; nó không chứng minh tại sao các hệ thống lại áp dụng chúng
Một số giao thức mạng và tin nhắn chỉ định các đầu cuối dòng chính xác, nhưng các yêu cầu của chúng phải xuất phát từ thông số kỹ thuật của chúng. Việc chuẩn hóa của ToolAcre khiến nó không phù hợp để chứng minh sự phù hợp với định dạng dây như vậy vì bằng chứng phân tách ban đầu bị cố ý loại bỏ.
Sử dụng trình xem hex hoặc trình xác thực giao thức trước khi phân tích cú pháp khi trình tự CRLF chính xác có ý nghĩa quan trọng. Một kết quả khác biệt Văn bản rõ ràng có thể xác nhận các dòng logic khớp và đồng thời che giấu lỗi ở cấp độ truyền tải. Cả hai quan sát đều có thể đúng vì các công cụ này trả lời các câu hỏi khác nhau.
Các yêu cầu về giao thức cần có thông số kỹ thuật riêng và được bỏ qua ở đây
So sánh `alpha beta`, `alpha beta` and `alpha beta` theo cặp. Mỗi dòng tạo ra hai dòng, alpha và beta và không có thêm hoặc bớt. Bỏ qua khoảng trắng không gây ra sự bình đẳng này; bình thường hóa đã xảy ra trong quá trình chia tách.
Thêm dấu cách vào một hàng beta và chế độ thông thường giờ đây sẽ báo cáo sự khác biệt. Bật Bỏ qua khoảng trắng và nó có thể biến mất. Trình tự này tách việc xử lý dòng mới khỏi việc xử lý khoảng trắng khóa dòng và ngăn chặn việc ghi sai tùy chọn.
Ví dụ đã hoạt động: cả ba dạng kết thúc đều so sánh bằng nhau trước các tùy chọn khoảng trắng
Tuyến đường này không định cấu hình trình chỉnh sửa, viết lại tệp, đặt thuộc tính Git hoặc chuyển đổi hàng loạt phần cuối. Nó cũng không hiển thị dấu phân cách ban đầu trong các hàng kết quả. Các chuỗi đã dán đi vào một đường dẫn so sánh chứ không phải tiện ích di chuyển dòng mới.
Các tiêu chuẩn về quan hệ nhân quả và giao thức lịch sử bị bỏ qua các nguồn đang chờ xử lý. Sự hạn chế đó để lại một bài viết nhỏ hơn nhưng chính xác: ba quy ước làm gì trong quá trình triển khai này, những dòng trống nào vẫn còn và tại sao sự bình đẳng ở đây không thiết lập nhận dạng byte.
Bài học rút ra: biết văn bản của bạn tuân theo quy ước nào — tóm tắt lịch sử và cách so sánh văn bản của ToolAcre giúp xác nhận liệu sự khác biệt chỉ là kết thúc dòng
Biết bằng chứng nào còn sót lại sau công cụ này. Sau khi chuẩn hóa, ToolAcre có thể so sánh nội dung dòng logic trên các dấu phân cách chung. Nó không thể cho bạn biết nguồn nào được sử dụng theo quy ước nào hoặc liệu người tiêu dùng xuôi dòng có yêu cầu một chuỗi byte chính xác hay không.
Sử dụng sự khác biệt của trình duyệt để con người xem xét và kiểm tra cấp độ byte để thực thi kho lưu trữ hoặc giao thức. Một công cụ đáng tin cậy khi các phép biến đổi của nó rõ ràng; người đánh giá vẫn chịu trách nhiệm chọn một tài sản bảo tồn tài sản mà họ cần xác minh.