Sự khác biệt giữa các loại ngắt dòng CR LF, LF và CR?

759

Tôi muốn biết sự khác biệt (với các ví dụ nếu có thể) giữa các loại ngắt dòng CR LF (Windows), LF (Unix) và CR (Macintosh).

line-breaks

— ảm đạm
nguồn

9

Rất giống nhau, nhưng không phải là một bản sao chính xác . \nthường được đại diện bởi một nguồn cấp dữ liệu, nhưng nó không nhất thiết là một nguồn cấp dữ liệu.

— Adrian McCarthy

92

CR và LF là các ký tự điều khiển ASCII và Unicode trong khi \rvà \nlà các khái niệm trừu tượng được sử dụng trong các ngôn ngữ lập trình nhất định. Kết thúc câu hỏi này che đậy sự khác biệt cơ bản giữa các câu hỏi và duy trì thông tin sai lệch.

— Adrian McCarthy

5

@AdrianMcCarthy Đó là một vấn đề với cách các phiếu bầu đóng vai trò là câu trả lời theo cách; một câu trả lời cho rằng hai cái này giống nhau có thể bị đánh giá thấp và sau đó chuyển sang màu rất, rất sai, nhưng chỉ mất 4 phiếu đồng ý (có thể so sánh với upvote) để có một kết quả rất sai, không có cách nào để chống lại phiếu bầu cho đến sau điều đó đã xảy ra.

— Jon Hanna

Công thức này của câu hỏi được thừa nhận là tốt hơn, nhưng nó vẫn dành cho tất cả các mục đích thực tế cho cùng một câu hỏi.

— Jukka K. Korpela

6

@ JukkaK.Korpela: Không, nó thực sự không. \nkhông có nghĩa là điều tương tự trong tất cả các ngôn ngữ lập trình.

— Adrian McCarthy

349

Nó thực sự chỉ là về các byte được lưu trữ trong một tập tin. CRlà một mã byte cho việc trả lại xe ngựa (từ thời của máy đánh chữ) vàLF tương tự, cho nguồn cấp dữ liệu dòng. Nó chỉ đề cập đến các byte được đặt làm điểm đánh dấu cuối dòng.

Cách nhiều thông tin hơn, như mọi khi, trên wikipedia .

— Peter
nguồn

53

Tôi nghĩ cũng hữu ích khi đề cập đến đó CRlà nhân vật thoát hiểm \rvà LFlà nhân vật thoát hiểm \n. Ngoài ra, Wikipedia: Dòng mới .

— Robert Vunabandi

1

Trong các từ đơn giản CR and LFchỉ là kết thúc của dòng và dòng mới theo liên kết này , điều này có đúng không?

— shaijut

@shaijut CR là viết tắt của Vận chuyển trở lại. Đó là những gì trả lại xe ngựa trên máy chữ. Vì vậy, chủ yếu là chính xác.

— AliFurkan

763

CR và LF là các ký tự điều khiển, được mã hóa tương ứng 0x0D(13 thập phân) và 0x0A(10 thập phân).

Chúng được sử dụng để đánh dấu ngắt dòng trong tệp văn bản. Như bạn đã chỉ ra, Windows sử dụng hai ký tự chuỗi CR LF; Unix chỉ sử dụng LF và MacOS cũ (tiền OSX MacIntosh) đã sử dụng CR.

Một viễn cảnh lịch sử khải huyền:

Như được chỉ định bởi Peter , CR = Trả lại vận chuyển và LF = Nguồn cấp dữ liệu , hai biểu thức có nguồn gốc từ các máy đánh chữ / TTY cũ. LF di chuyển tờ giấy lên (nhưng giữ nguyên vị trí nằm ngang) và CR mang lại "cỗ xe" để ký tự tiếp theo được gõ sẽ ở vị trí ngoài cùng bên trái trên tờ giấy (nhưng trên cùng một dòng). CR + LF đã làm cả hai, tức là chuẩn bị gõ một dòng mới. Khi thời gian trôi qua, ngữ nghĩa vật lý của các mã không được áp dụng và vì không gian bộ nhớ và đĩa mềm ở mức cao, một số nhà thiết kế hệ điều hành đã quyết định chỉ sử dụng một trong các ký tự, họ chỉ không giao tiếp tốt với nhau; -)

Hầu hết các trình soạn thảo văn bản hiện đại và các ứng dụng hướng văn bản đều cung cấp các tùy chọn / cài đặt, v.v. cho phép tự động phát hiện quy ước cuối dòng của tệp và hiển thị tương ứng.

— mjv
nguồn

11

Vì vậy, thực sự Windows là hệ điều hành duy nhất sử dụng đúng các ký tự này, Car car Return, theo sau là Line Feed.

— Rolf

4

Sau đó, có chính xác không khi nói rằng một tệp văn bản được tạo trên Windows là tương thích nhất trong ba nghĩa là có khả năng hiển thị nhất trên cả ba tập hợp hệ điều hành?

— Prometheus

3

@Hashim nó có thể hiển thị đúng nhưng cố gắng chạy tập lệnh shell văn bản với trả về vận chuyển thường sẽ gây ra lỗi

— Omer

Trong các từ đơn giản CR and LFchỉ là kết thúc của dòng và dòng mới theo liên kết này , điều này có đúng không?

— shaijut

Tôi đã thấy rằng một số tệp kiểu Windows ( CR+LF) có thể hiển thị với hai dòng mới trên các hệ thống khác. Có lẽ trình soạn thảo hiển thị văn bản hỗ trợ cả Vận chuyển trở lại và Nguồn cấp dữ liệu dưới dạng các dấu phân cách dòng mới và do đó có thể tạo ra 2 dòng trong đó 1 dự định. Vì vậy, trong khi CR+LFcó thể tương thích nhất , tôi không nghĩ nó không có vấn đề gì.

— Magnus Bull

459

Đây là một bản tóm tắt tốt mà tôi tìm thấy:

Ký tự Vận chuyển trở lại (CR) ( 0x0D, \r) di chuyển con trỏ đến đầu dòng mà không tiến tới dòng tiếp theo. Ký tự này được sử dụng làm ký tự dòng mới trong hệ điều hành Commodore và Macintosh sớm (OS-9 trở về trước).

Ký tự Line Feed (LF) ( 0x0A, \n) di chuyển con trỏ xuống dòng tiếp theo mà không quay lại đầu dòng. Ký tự này được sử dụng làm ký tự dòng mới trong các hệ thống dựa trên UNIX (Linux, Mac OSX, v.v.)

Chuỗi kết thúc (EOL) ( 0x0D 0x0A, \r\n) thực sự là hai ký tự ASCII, là sự kết hợp của các ký tự CR và LF. Nó di chuyển con trỏ xuống dòng tiếp theo và đến đầu dòng đó. Ký tự này được sử dụng làm ký tự dòng mới trong hầu hết các hệ điều hành không phải Unix khác bao gồm Microsoft Windows, Symbian OS và các hệ điều hành khác.

Nguồn

— Taylor Leese
nguồn

1

"Tab dọc" -character di chuyển con trỏ xuống và giữ vị trí trong dòng, không phải ký tự LF. Các LF là EOL.

— 12431234123412341234123

2

@TaylorLeese Có / r / n và / n / r giống nhau không?

— Vicrobot

175

Vì không có câu trả lời chỉ ra điều này, nên tóm tắt ngắn gọn:

Vận chuyển trở lại (MAC trước OSX)

CR
\ r
Mã ASCII 13

Nguồn cấp dữ liệu (Linux, MAC OSX)

LF
\ n
Mã ASCII 10

Vận chuyển trở lại và nguồn cấp dữ liệu (Windows)

CRLF
\ r \ n
Mã ASCII 13 và mã ASCII 10

Nếu bạn thấy mã ASCII ở định dạng lạ, chúng chỉ là số 13 và 10 trong một cơ số / cơ sở khác nhau, thường là cơ sở 8 (bát phân) hoặc cơ sở 16 (thập lục phân).

http://www.bluesock.org/~willg/dev/ascii.html

— ahnbizcad
nguồn

46

Jeff Atwood có một bài đăng trên blog gần đây về điều này: The Great Newline Schism

Đây là bản chất từ Wikipedia :

Trình tự CR + LF được sử dụng phổ biến trên nhiều hệ thống máy tính đời đầu đã sử dụng máy teletype, điển hình là ASR33, như một thiết bị điều khiển, bởi vì trình tự này được yêu cầu để định vị các máy in đó khi bắt đầu một dòng mới. Trên các hệ thống này, văn bản thường được soạn thảo thường xuyên để tương thích với các máy in này, vì khái niệm trình điều khiển thiết bị ẩn các chi tiết phần cứng như vậy từ ứng dụng chưa được phát triển tốt; các ứng dụng phải nói chuyện trực tiếp với máy teletype và tuân theo các quy ước của nó.Sự tách biệt của hai chức năng che giấu thực tế là đầu in không thể quay lại từ bên phải sang đầu dòng tiếp theo trong thời gian một ký tự. Đó là lý do tại sao chuỗi luôn được gửi với CR đầu tiên. Trong thực tế, thường phải gửi thêm các ký tự (CR hoặc NUL không liên quan, bị bỏ qua) để cho thời gian đầu in di chuyển sang lề trái. Ngay cả sau khi teletypes được thay thế bởi các thiết bị đầu cuối máy tính có tốc độ truyền cao hơn, nhiều hệ điều hành vẫn hỗ trợ gửi tự động các ký tự điền này, để tương thích với các thiết bị đầu cuối rẻ hơn yêu cầu nhiều lần ký tự để cuộn màn hình.

— Manu
nguồn

5

+1 Chính nhờ sự hiểu biết đơn giản này mà tôi luôn nhớ theo thứ tự kết hợp đến. Ngay cả ngày nay chúng ta vẫn có thể thấy logic cơ học này trong bất kỳ máy in phun mực nào (tôi thích hiểu vì tôi ghét phải học). Các thủ thuật bộ nhớ khác của tôi là: "mac? Quay trở lại người gửi" và "NewLineFeed" (để nhớ rằng NL === LF và để nhớ \ n, vì CR đã có chữ R viết tắt)

— GitaarLAB

3

"Tôi nghi ngờ ... hai mã kiểm soát là cần thiết cho thời gian". Đó không phải là những gì nó nói. Nó nói rằng các CR và NUL bổ sung đang ở đây để dành thời gian cho nó quay trở lại, chứ không phải CR LF ban đầu.

— Julien Rousseau

11

@Adrian Bạn sẽ có kinh nghiệm cá nhân? 1) Trong những ngày teletype cũ của tôi, máy in chúng tôi sử dụng yêu cầu<CR><CR><LF> - vì vậy tất nhiên tôi đã thử nghiệm chỉ với một <CR>. Tôi gửi <CR><LF>Asau khi một đường dài, và bạn có thể nghe thấy những Ađược in trước khi vận chuyển trở lại đầy đủ.

— John Burger

11

@Adrian 2) Đừng quên, đây là thời đại cơ điện, nơi mỗi nhân vật thực hiện chính xác một chức năng. Chúng tôi thường nhấn mạnh một từ bằng cách in dòng, sau đó gửi <CR><CR>và nhập đúng số lượng khoảng trắng, sau đó in lại cùng một từ: một hình thức nguyên thủy của sự tô đậm.

— John Burger

3

@Adrian 3) Và cuối cùng, điều này đã sử dụng Baudot (hoặc mã Murray), không phải ASCII. Năm bit dữ liệu, giữa một bit start và một bit rưỡi dừng. Làm thế nào bạn có thể có một nửa? Bằng cách đợi một nửa thời gian trước khi bắt đầu gửi ký tự tiếp theo, để cho thời gian đầu in trở về trung tâm.

— John Burger

16

Mã CR - ASCII 13

Mã số - ASCII 10.

Về mặt lý thuyết CR trả con trỏ về vị trí đầu tiên (bên trái). LF cung cấp một dòng di chuyển con trỏ xuống một dòng. Đây là cách ngày xưa bạn điều khiển máy in và màn hình chế độ văn bản. Các ký tự này thường được sử dụng để đánh dấu kết thúc dòng trong tệp văn bản. Hệ điều hành khác nhau sử dụng các quy ước khác nhau. Như bạn đã chỉ ra, Windows sử dụng kết hợp CR / LF trong khi máy Mac trước OSX chỉ sử dụng CR, v.v.

— DmitryK
nguồn

7

Các hệ thống dựa trên ASCII hoặc một bộ ký tự tương thích sử dụng riêng lẻ (Nguồn cấp dữ liệu, 0x0A, 10 theo số thập phân) hoặc CR (Trả về vận chuyển, 0x0D, 13 theo số thập phân) hoặc CR theo sau là LF (CR + LF, 0x0D 0x0A); Các ký tự này dựa trên các lệnh của máy in: Nguồn cấp dữ liệu chỉ ra rằng một dòng giấy sẽ được nạp ra khỏi máy in và việc trả lại vận chuyển chỉ ra rằng việc vận chuyển máy in sẽ trở về đầu dòng hiện tại.

Dưới đây là chi tiết .

— pierrotlefou
nguồn

5

Trạng thái đáng buồn của "bộ tách bản ghi" hoặc "bộ kết thúc dòng" là một di sản của thời kỳ đen tối của điện toán.

Bây giờ, chúng tôi chấp nhận rằng bất cứ điều gì chúng tôi muốn đại diện là theo cách nào đó dữ liệu có cấu trúc và tuân thủ các khái niệm trừu tượng khác nhau xác định các dòng, tệp, giao thức, tin nhắn, đánh dấu, bất cứ điều gì.

Nhưng đã có lúc điều này không chính xác. Các ứng dụng tích hợp các ký tự điều khiển và xử lý dành riêng cho thiết bị. Các hệ thống chết não đòi hỏi cả CR và LF đơn giản là không có sự trừu tượng hóa cho các bộ tách bản ghi hoặc bộ kết thúc dòng. CR là cần thiết để có được màn hình teletype hoặc video quay trở lại cột một và LF (ngày nay, NL, cùng mã) là cần thiết để đưa nó tiến lên dòng tiếp theo. Tôi đoán ý tưởng làm một cái gì đó ngoài việc đổ dữ liệu thô vào thiết bị là quá phức tạp.

Unix và Mac thực sự đã chỉ định một sự trừu tượng hóa cho đầu dòng, hãy tưởng tượng điều đó. Đáng buồn thay, họ chỉ định những người khác nhau. (Unix, ahem, xuất hiện đầu tiên.) Và một cách tự nhiên, họ đã sử dụng mã kiểm soát đã "gần gũi" với SOP

Vì hầu hết tất cả các phần mềm điều hành của chúng tôi ngày nay là hậu duệ của Unix, Mac hoặc MS điều hành SW, chúng tôi bị mắc kẹt với sự nhầm lẫn kết thúc dòng.

— DigitalRoss
nguồn

1

NL có nguồn gốc từ EBCDIC NL = x'15 'sẽ so sánh hợp lý với CRLF x'odoa ascii ... điều này trở nên rõ ràng khi chuyển dữ liệu vật lý từ máy tính lớn sang tầm trung. Thông thường (vì chỉ những người phức tạp sử dụng ebcdic) NL đã được đánh đồng với CR hoặc LF hoặc CRLF

— yêu
nguồn