一、回車與換行的來歷
關於“回車”（carriage return）和“換行”（line feed）這兩個概念的來歷和區別。
在計算機還沒有出現之前，有一種叫做電傳打字機（Teletype Model 33）的玩意，每秒鍾可以打10個字符。但是它有一個問題，就是打完一行換行的時候，要用去0.2秒，正好可以打兩個字符。要是在這0.2秒里面，又有新的字符傳過來，那么這個字符將丟失。
於是，研制人員想了個辦法解決這個問題，就是在每行后面加兩個表示結束的字符。一個叫做“回車”，告訴打字機把打印頭定位在左邊界；另一個叫做“換行”，告訴打字機把紙向下移一行。
這就是“換行”和“回車”的來歷，從它們的英語名字上也可以看出一二。
后來，計算機發明了，這兩個概念也就被般到了計算機上。那時，存儲器很貴，一些科學家認為在每行結尾加兩個字符太浪費了，加一個就可以。於是，就出現了分歧。
Unix系統里，每行結尾只有“<換行>”（LF），即“\n”，對應十六進制數是0x0A；Windows系統里面，每行結尾是“ <回車><換行>”，即“\r\n”；Mac系統里，每行結尾是“<回車>”（CR），對應十六進制數是0x0D。一個直接后果是，Unix/Mac系統下的文件在Windows里打開的話，所有文字會變成一行；而Windows里的文件在Unix/Mac下打開的話，在每行的結尾可能會多出一個^M符號。
windows創建的文件是 \n\r結束的， 而linux，mac這種unix類系統是\n結束的。
所以unix的文本到windows會出現換行丟失（ultraedit這種軟件可以正確識別）； 而反過來就會出現^M的符號了
Windows等操作系統用的文本換行符和UNIX/Linux操作系統用的不同，Windows系統下輸入的換行符在UNIX/Linux下不會顯示為“換行”，而是顯示為 ^M 這個符號（這是Linux等系統下規定的特殊標記，占一個字符大小，不是 ^ 和 M 的組合，打印不出來的）。Linux下很多文本編輯器（命令行）會在顯示這個標記之后，補上一個自己的換行符，以避免內容混亂（只是用於顯示，補充的換行符不會寫入文件，有專門的命令將Windows換行符替換為Linux換行符）。 UNIX/Linux系統下的換行符在Windows系統的文本編輯器中會被忽略，整個文本會亂成一團。
所以在linux保存的文件在windows上用記事本看的話會出現黑點，我們可以在LINUX下用命令把linux的文件格式轉換成win格式的。
二、C語言中的處理
畢竟是源自Unix系統，C語言中使用\n表示換行，而在實際的文件中換行符號需要同操作系統一致，所以當我們在C中使用fopen打開一個文本文件時流實現了實際換行符與C中\n之間的轉換。在windows中當我們用fopen打開文本文件，然后從中讀到\r\n時流會轉換為\n，而當我們往文件中寫入\n時流會轉換為\r\n。以二進制模式打開流不會做任何處理。
當我們使用標准輸入輸出函數時有這種情況嗎？
C的控制台程序在加載進內存成為進程運行前C運行時庫自動打開三個設備並關聯到三個流：標准輸入流stdin，標准輸出流stdout，標准出錯流stderr。
通常在通用計算機中，沒有重定向前這三個流對應的設備是：鍵盤，顯示器，顯示器。這三個都是字符設備，所以是以文本文件的模式打開的，在windows下當我們在鍵盤上敲入回車鍵時產生字符\r\n，但是在OS內核把鍵盤驅動中讀到的字符發送給流的緩沖區時流會將之轉換為\n，當我們向控制台輸出\n時流將之轉換為\r\n再傳遞至內核，當我們繞過標准輸入輸出直接調用windows中coredll.lib進行控制台輸入輸出時就必須面對這一現實，程序員負責實現這一轉換。
文本文件的行結束符一律變成一個符號LF,也就是換行符,也就是new line符, 也就是'\n'。“回車和換行符轉換成一個換行符”-- 對PC機而言,文本文件行結束符,CRLF讀入后,丟掉CR,留 LF。例如fgets() 讀入一行,行尾只有LF,沒有CR.
三、編碼建議
以下是Quantum Leaps公司給出的編碼規范中關於EOL的一段，摘錄如下，
All source code should consistently use only one end-of-line convention. For improved portability,
this Standard recommends consistent use of the Unix™ end-of-line convention, with only one LF
character (0x0A) terminating each line. The DOS/Windows end-of-line convention with CR, LF
character pair (0x0D, 0x0A) terminating each line is not recommended because it causes compilation
problems on Unix™-like systems, such as Linux™. (Specifically, the C preprocessor doesn’t correctly
parse the multi-line macros.) On the other hand, most DOS/Windows compilers seem to tolerate the
Unix™ EOL convention without problems.