細說"回車"和"換行"的故事
引言
最近在php還有c#以及memcache的shell當中經常看到\r\n的寫法,剛開始還沒註意,
不過後面感覺這樣寫有些不對頭,\r表示回車 \n表示換行,那這樣不是換行了兩次嗎?
為了解決疑惑,問了下度娘,總算對\r \n有了新的認識。
解釋
首先 \r 是回車, \n 是換行,這毋庸置疑,但是前者的作用只是將光標移到行首,後者是將光標移到下一行。
也就是說 你敲鍵盤的 回車鍵<Enter> 其實是回車和換行的組合鍵(\r\n)。不同的操作系統,其原理也不一樣
如果把一個文本的空格和回車等都反轉義,就是顯示出轉義符,那麽你會看到
windows每行結尾都有\r\n
Unix每行結尾只有\n
Mac每行結尾只有\r
這個三個操作系統是故意的吧,這麽不統一,這也是為啥 linux 文件拿到 windows 下會錯行的原因。
下面做個小實驗來看看這個該死的錯行現象
實驗
1.在 Linux 下vim a.txt 編輯一個文本
2.把這個文本弄到windows下面看看
可以發現錯行了!!!因為對於windows上面的換行條件還少了個字符\r
那麽windows下看起來正常的文件在Linux下面又會變成啥樣?
3.在Windows下編輯一個文本
通過ftp傳到Linux下後,打開
簡直慘不忍睹,H和o都合並再一起了,^M又是啥玩意,不著急後面會講到
可見得我們在平時使用電腦時,已經習慣了回車和換行一次搞定,敲一個回車鍵,即是回車,又是換行。
\n 軟回車
在Windows 中表示換行且回到下一行的最開始位置。
在Linux、unix 中只表示換行,但不會回到下一行的開始位置。
\r 軟空格
在Linux、unix 中表示返回到當行的最開始位置。
在Mac OS 中表示換行且返回到下一行的最開始位置。
下面是回車和換行的歷史,有興趣的人可以閱讀下
歷史
回車(carriage return)和換行(line feed)兩個概念的來歷和區別
計算機還沒出生之前,有一種玩意叫電傳打字機,每分鐘可以打10個字符。但是他有個問題,
就是打完一行換行的時候要用去0.2秒,正好是打兩個字符的時間。
而就在他使用這0.2秒進行換行的時候又有新的字符傳過來,那麽這個字符將會丟失。
於是,研制人員想了個辦法解決這個問題,就是在每行後面加兩個字符表示結束的字符。
一個叫做回車,它用來告訴打字機把打印頭定位於在左邊界,另個叫換行,它用來告訴打字機
把紙往上挪一下。這樣打字機在換行時使用的0.2秒時間丟棄的只是兩個不需要顯示出來的字符。
計算機誕生後,這兩個字符也搬了過來,那時候存儲器很貴,一些科學家覺得每次換行都要花費空間來放下這兩
個字符太浪費了,加一個就可以了,於是出現了分歧。Unix系統每行結尾只有\n,Windows系統每行結尾是\r
\n,Mac系統每行結尾是\r。一個直接的結果就是如我上面的實驗那樣,同一文本在不同系統下會出現不同的結
果,這當然不是我們想要的效果
Dos 和 Windows 采用回車+換行 CR/LF 表示下一行即 ^M$
Unix 和 Linux 采用換行 LF 表示下一行即 $
Mac 采用CR表示下一行 即^M
CR 用\r表示 十進制ASCII為13 十六進制0x0D
LF 用\n表示 ASCII為10 十六進制0X0D
看!有圖有真相,我可沒瞎說哈。
解決
需要註意的是,不同平臺之間用FTP協議傳輸文件時,在ASCII模式下傳輸可能會自動對換行進行轉換,從而導致字節數的變更
如果不想ftp對文件的修改,可以使用Bin模式進行文本傳輸。換行的問題以及來源,那麽如何解決不同平臺的文本錯行顯示呢?
所以下面的實驗為了不被ftp軟件毀滅證據,通通使用binary模式進行傳輸。
1.windows 文本到 linux 下的轉換方法.
(1)使用sed 命令進行替換
sed -e ‘s/^M//g‘ old.txt > new.txt
註意這個^M是先按Ctrl+V 然後按Ctrl+Shift+M 才能打出來的不是直接打^M
==
(2)vim編輯器的替換命令
:%s/^M//g
=>
同樣^M不是直接打出來的,會變成藍色,而不是白色
(3)使用命令行
tr -d "\r"<dosfile > unixfile
(4)使用dos2unix工具
dos2unix a.txt #直接轉換
dos2unix -n a.txt b.txt #保留源文件
(5)FTP傳輸工具
如果是以ASCII模式傳輸,那麽FTP會幫你轉換
如果是以Binary模式傳輸,那麽FTP保留原文件
總結
如果有些細節上的問題不重視,那麽可能就會帶來頭疼的問題,或者不必要的麻煩。
轉載請指明出處:http://www.cnblogs.com/demonxian3/p/6917133.html
細說"回車"和"換行"的故事