Văn bản & công cụ hàng ngày · Bộ công cụ văn bản
CR, LF và CRLF: kết thúc dòng đến từ đâu và tại sao ngắt văn bản được dán
· Lý lịch
line-endings text-cleanup data-exports
Giải thích nguồn gốc kiểu điện báo của việc xuống dòng và nạp dòng, tại sao các hệ điều hành lại chọn các quy ước khác nhau và cách các lựa chọn đó hiển thị dưới dạng các dòng trống gấp đôi và các ký tự đi lạc trong văn bản được dán.
Xuất với một dòng trống sau mỗi hàng - tại sao một tệp từ hệ thống khác lại dán số dòng nhiều gấp đôi
Bạn dán xuất ba hàng và thấy một dòng trống sau mỗi bản ghi. Bạn có thể dễ dàng đổ lỗi cho Windows CRLF ngay lập tức, nhưng vùng văn bản tuân thủ tiêu chuẩn thường hiển thị ngắt dòng ở dạng chuẩn hóa. Các hàng được nhân đôi thường xuyên hơn có nghĩa là chuyển đổi trước đó coi việc trả về đầu dòng và nguồn cấp dữ liệu dòng là hai dấu phân cách độc lập hoặc chèn thêm một dòng mới giữa các bản ghi.
Giữ bản gốc cho đến khi bạn biết giai đoạn nào đã thay đổi nó. So sánh nguồn trong trình chỉnh sửa có thể hiển thị các ký tự điều khiển, sau đó so sánh số dòng được dán. ToolAcre cố tình chấp nhận CRLF, LF và CR đơn độc làm một ranh giới, do đó, một tệp ba bản ghi chưa được xử lý sẽ tạo ra ba dòng thay vì sáu dòng chỉ vì nó đến từ Windows.
Một hàng trống thừa là một triệu chứng, không phải là bằng chứng cho thấy chỉ riêng CRLF đã gây ra nó
Tên mô tả các hoạt động vật lý trên thiết bị đầu cuối in. Việc quay trở lại đầu dòng đã di chuyển đầu dòng đến đầu dòng hiện tại, trong khi nguồn cấp dữ liệu dòng sẽ đưa giấy đến dòng tiếp theo. Chúng là các bộ điều khiển riêng biệt vì một trong hai chuyển động có thể được yêu cầu độc lập. ASCII đã giữ lại chúng dưới dạng ký tự điều khiển CR ở số thập phân 13 và LF ở số thập phân 10.
Các màn hình hiện đại không còn di chuyển giấy nữa nhưng các giá trị byte vẫn tồn tại trong các tệp, giao thức và giao diện lập trình. Lịch sử giải thích tại sao CR và LF không thể hoán đổi cho nhau các dấu chấm câu và tại sao CRLF là một chuỗi hai ký tự. Điều đó không có nghĩa là mọi ứng dụng hiện đại đều xử lý chúng một cách riêng biệt; các trình phân tích cú pháp thường nhận ra cặp này là một dòng logic kết thúc.
Ba quy ước — LF trên Unix và macOS hiện đại, CRLF trên Windows, CR trên Mac OS cổ điển và lý do mỗi quy ước có vẻ hợp lý
Các hệ thống tương tự Unix và Unix thường sử dụng LF để kết thúc dòng và macOS hiện đại tuân theo quy ước đó. Các tệp văn bản Windows thường sử dụng CRLF. Mac OS cổ điển chỉ sử dụng CR, nhưng Mac OS X đã sử dụng nền tảng Unix và LF. Những lựa chọn đó vẫn hiển thị khi các công cụ trao đổi văn bản thuần túy mà không đồng ý về việc chuẩn hóa.
Không có quy ước nào làm cho các từ trở nên khác biệt. Rắc rối xuất hiện ở một ranh giới mà người đọc chỉ mong đợi một cách thể hiện hoặc sự phân chia một cách ngây thơ trên mỗi ký tự điều khiển. Trình phân tích cú pháp dòng mạnh mẽ sẽ kiểm tra CRLF dưới dạng một cặp trước khi kiểm tra CR hoặc LF đơn độc. ToolAcre thực hiện chính xác điều đó với mẫu được sắp xếp ` | | `, sau đó nối đầu ra được chuyển đổi với LF.
Điều gì xảy ra trong hộp văn bản của trình duyệt — cách ngắt dòng thường được chuẩn hóa khi dán và nơi các ký tự đi lạc vẫn xuất hiện
HTML xác định cách xử lý đặc biệt đối với ngắt dòng trong điều khiển văn bản. Trong giá trị vùng văn bản, trình duyệt chuẩn hóa CRLF và CR đơn độc thành LF trong giá trị hiển thị, trong khi việc gửi biểu mẫu có thể áp dụng quy tắc dữ liệu biểu mẫu cho ngắt dòng. Do đó, một miếng dán trông có vẻ chính xác trong hộp vẫn có thể được sắp xếp theo thứ tự khác theo một lớp khác hoặc được sao chép vào phần mềm theo quy ước khác.
CR lạc vẫn có thể hiển thị khi văn bản bỏ qua vùng văn bản thông thường, khi các byte thoát như ký tự chữ `\r` được hiển thị hoặc khi trình phân tích cú pháp chỉ phân tách trên LF và để CR gắn liền với từng trường. Trình duyệt chỉ là một giai đoạn trong lộ trình, không phải là dịch vụ sửa chữa chung cho các tệp, trình tạo bảng nhớ tạm, API và trình sử dụng dòng lệnh.
Trình duyệt bình thường hóa ngắt dòng vùng văn bản, nhưng định dạng clipboard và định dạng xuôi dòng vẫn khác nhau
Các hàng trống và các dòng trả về cuối dòng yêu cầu các chẩn đoán khác nhau. Xóa dòng trống sẽ xóa các hàng có nội dung trống hoặc khoảng trắng sau khi ToolAcre đã nhận dạng được cả ba kiểu kết thúc dòng. Trim Lines loại bỏ khoảng trắng ở đầu và cuối mỗi hàng. Bởi vì bộ tách của ToolAcre sử dụng bộ tách CR thực sự nên việc cắt xén thường không cần thiết chỉ để xóa bộ tách đó.
Chỉ sử dụng tính năng cắt xén khi vẫn còn khoảng trắng, tab hoặc ký tự không được sử dụng và kiểm tra vết lõm có ý nghĩa trước khi thay đổi. Nếu văn bản chứa `^M` hiển thị, hãy xác định xem người xem đang hiển thị CR thực tế hay hai ký tự có thể in được đó. Việc thay thế chăn có thể làm hỏng nội dung dự kiến, trong khi việc kiểm tra số lượng trước và sau sẽ cho kết quả có thể xem xét được.
Xóa các dòng trống sửa các hàng trống; việc cắt xén thường không cần thiết sau khi ToolAcre tách CR một cách chính xác
Đối với một ví dụ có thể lặp lại, hãy bắt đầu bằng ba tên có biểu diễn trung gian bị hỏng chứa một hàng trống giữa mỗi tên: `Ada`, trống, `Grace`, trống, `Linus`. Bộ đếm Từ và Ký tự báo cáo năm dòng. Đây là đầu vào được nhân đôi một cách có chủ ý; riêng một chuỗi CRLF chính hãng sẽ được công nhận là một ranh giới và sẽ không tạo ra các hàng trống đó trong ToolAcre.
Chọn Xóa dòng trống và đầu ra sẽ trở thành ba dòng được nối với LF. Bộ đếm bây giờ sẽ báo cáo ba. Nếu các giá trị đã nhập cũng có phần đệm, hãy chạy Trim Lines riêng biệt và xem lại kết quả. Việc tách các hoạt động đó chứng tỏ lỗi nào được khắc phục trong mỗi hành động thay vì quy mọi hoạt động dọn dẹp là một chuyển đổi mơ hồ từ văn bản Windows.
Ví dụ đã hoạt động: làm sạch việc xuất gấp đôi có chủ ý và xác minh số dòng
Việc dọn dẹp cuối dòng không sửa chữa được phần gói cứng, trong đó một câu logic bị cố tình phá vỡ ở độ rộng cột. Việc xóa mọi dòng mới khỏi tài liệu đó cũng sẽ nối các đoạn văn thực và danh sách các mục. Quyết định xem ranh giới có đại diện cho một bản ghi, một đoạn văn hay gói trực quan hay không trước khi áp dụng thao tác đường trên toàn bộ khối.
Nó cũng không chẩn đoán mã hóa ký tự. Dấu thứ tự UTF-8 byte, hình kim cương thay thế, lỗi mojibake và giải mã liên quan đến cách byte trở thành ký tự chứ không phải liệu CR hay LF có phân tách các ký tự đó thành hàng hay không. Bảo toàn tệp gốc và xác định mã hóa của nó bằng công cụ nhận biết tệp thích hợp trước khi coi các ký hiệu hiển thị kỳ lạ là kết thúc dòng.
Điều rút ra - kết thúc dòng là lịch sử mà bạn có thể thấy; các công cụ dòng và bộ đếm của Bộ công cụ văn bản cho phép bạn khắc phục các triệu chứng trong vài giây
CR, LF và CRLF là các biện pháp kiểm soát trước đây có hậu quả là khả năng tương thích hiện tại. Mô hình tinh thần an toàn nhất là một ranh giới đường logic với một số biểu diễn vật lý. Đếm các bản ghi, kiểm tra quy ước nguồn và xác định giai đoạn đưa ra các hàng trống hoặc các ký tự điều khiển được giữ lại trước khi xóa bất kỳ thứ gì.
Đối với tài liệu đã dán, hãy mở Bộ công cụ văn bản tại `/tools/text/`, ghi lại số dòng ban đầu, chỉ áp dụng Xóa dòng trống khi các hàng trống thực sự không mong muốn và chỉ sử dụng Cắt dòng cho khoảng trắng xung quanh. Kiểm tra lại số lượng và hồ sơ mẫu sau đó. Quá trình kiểm tra ngắn đó biến vấn đề định dạng vô hình thành chuyển đổi văn bản có thể đảo ngược, được kiểm soát.