9 điểm bởi GN⁺ 2024-10-14 | 8 bình luận | Chia sẻ qua WhatsApp

Định nghĩa về carriage return và line feed

  • Carriage return (CR): Di chuyển con trỏ về lề trái của cùng một dòng
  • Line feed (LF): Di chuyển con trỏ xuống một dòng và cuộn các dòng trước đó lên trên
  • Newline (NL): Di chuyển con trỏ xuống một dòng và về lề trái

Quan sát

  • CR và NL là các ký tự điều khiển hữu ích. NL là thao tác phổ biến nhất, bắt đầu một dòng văn bản mới từ lề trái
  • LF về cơ bản là vô dụng. Không ai muốn xuống dòng tiếp theo từ giữa dòng rồi tiếp tục viết ở cùng một cột
  • LF có nguồn gốc từ thời máy điện báo cơ học khoảng 70 năm trước

Bối cảnh lịch sử

  • Máy điện báo in khoảng 5 ký tự mỗi giây
  • Truyền thống CRLF bắt nguồn từ các giới hạn cơ học của máy điện báo trong thập niên 1950
  • Đến thời Multix và Unix, ngày càng có nhiều nhận thức rằng dùng CRLF làm NL là không hiệu quả

Tình hình hiện đại

  • Ngày nay CR được biểu diễn là U+000d, còn LF và NL là U+000a
  • Hầu hết các máy hiện đại chỉ dùng U+000a như NL
  • Một số giao thức vẫn yêu cầu CRLF, nhưng phần lớn phần mềm chấp nhận một NL đơn lẻ

Lời kêu gọi hành động

  • Đổi tên code point U+000a từ "line feed" thành "newline"
  • Ngừng truyền CR không cần thiết
  • Với các giao thức yêu cầu CRLF, hãy chỉ truyền NL
  • Sửa phần mềm tạo lỗi khi nhận NL mà không có CR

Tóm tắt và tác giả

  • Sự chấm dứt của CRLF lẽ ra đã cần từ rất lâu. Chúng ta nên cùng nhau loại bỏ di vật lỗi thời này
  • Tác giả: D. Richard Hipp, người sáng lập SQLite

# GN⁺ tóm tắt

  • Bài viết này giải thích bối cảnh lịch sử của CRLF và sự kém hiệu quả trong thời hiện đại, đồng thời kêu gọi loại bỏ nó
  • CRLF là một truyền thống bắt nguồn từ các giới hạn cơ học, nhưng ngày nay gây ra độ phức tạp không cần thiết
  • Chủ đề này có thể đặc biệt hữu ích với lập trình viên và nhà phát triển phần mềm, đồng thời quan trọng cho việc truyền dữ liệu hiệu quả
  • Ngay cả khi dùng các giao thức hoặc hệ thống khác có chức năng tương tự, cũng cần xem xét lại sự cần thiết của CRLF

8 bình luận

 
cosine20 2024-10-14

Thỉnh thoảng vẫn dùng line feed....

 
doolayer 2024-10-14

Đúng là khá dữ dội nhỉ, rùng mình thật

 
savvykang 2024-10-14

Theo cập nhật ngày 14 tháng 10, đề xuất thay đổi này đã được rút lại.

Đây không phải là chuyện chỉ thay đổi một hệ thống đơn lẻ, mà là phải dần dần thay đổi cả giao thức và mọi hệ thống bị ảnh hưởng, nên theo tôi có vẻ như tác giả đã không đủ thận trọng.

 
constexprif 2024-10-14

Có phải họ nghĩ rằng lợi ích thu được từ việc loại bỏ nó sẽ lớn hơn chi phí để loại bỏ không?

 
alstjr7375 2024-10-14

CR+LF có một lịch sử rất lâu đời...

Ồ.. ra là vì lý do này..

 
bakyeono 2024-10-14

CRLF không phải là một đặc tả được định nghĩa sai, mà là thứ phản ánh môi trường phần cứng của thời đó...
Có vẻ như người ta quên mất tính tương thích ngược và chỉ nghĩ đến thời điểm hiện tại.
Mỗi khi đặc tả phần cứng thay đổi thì chúng ta lại phải lật đổ toàn bộ giao thức sao?

 
halfenif 2024-10-14

Tôi không hẳn ủng hộ cũng không hẳn phản đối việc loại bỏ nó.

Nhưng tại sao tôi lại nhớ đến lỗi thiên niên kỷ nhỉ?

 
GN⁺ 2024-10-14
Ý kiến trên Hacker News
  • Việc cập nhật các giao thức hiện có sang NL có thể gây ra lỗi tiềm ẩn, và HTTP/1.1 đã được thay thế bằng HTTP/2
    • Có ý kiến cho rằng trong các giao thức mới, việc không yêu cầu CRLF là hợp lý, nhưng không cần cập nhật các giao thức hiện có
  • Việc không tuân thủ CRLF cũng giống như cố tình đưa lỗi vào
    • Máy chủ HTTP của SQLite đã được cập nhật để dùng \r\n thay vì \n, nhưng điều này làm hỏng khả năng tương thích với HTTP client của Zig
  • Có ý kiến cho rằng nên để con cháu sau này không còn phải bận tâm đến CRLF
    • Họ cho rằng nên dạy cách dùng tệp .gitattribute, và giáo dục mọi người ghét Byte Order Mark
  • Lựa chọn kết thúc dòng phi tiêu chuẩn của Unix là một sai lầm, và điều này đã gây ra các vấn đề tương thích suốt hàng chục năm
    • CRLF là hai phần khác nhau của API terminal, và nhiều chương trình phụ thuộc vào hoạt động đúng của CR và LF
  • CRLF là một trong những yếu tố ít quan trọng nhất của tiêu chuẩn
    • Việc phá vỡ tiêu chuẩn là một thử nghiệm mới, và cá nhân người viết thấy đây là một thái độ xa lạ
  • SMTP nêu rõ chuỗi kết thúc thông điệp là CR LF . CR LF, và cũng có những triển khai nhận diện LF . LF
    • Có thể các quy tắc SMTP ban đầu giờ đây không còn quan trọng nữa
  • CRLF có thể gây rủi ro cho nhiều thiết bị, và nên giảm bớt các ngoại lệ
  • Không có đề cập nào đến các vấn đề phát sinh khi trộn lẫn các kiểu kết thúc dòng
    • Không tồn tại ký tự nào gọi là NL, và phím "ENTER" trên mọi bàn phím đều gửi CR
    • Cách làm hiện tại đang hoạt động tốt