EditPlus 對於分行符號的處理

EditPlus 有個檔案格式，用於區分三種分行符號之一。

一、/r/n 與 /n 混合（即 PC 與 Unix 換行混合）
1，如果文本中 /r/n 的數量大於 /n 的數量，那麼就以 PC 的 /r/n 方式來顯示，這時 /n 並不能顯示成為一個新行，而是成為一個不可顯字元；
2，如果文本中 /r/n 的數量小於 /n 的數量，那麼就以 Unix 的 /n 方式來顯示，這時 /r/n 中的 /r 成為一個不可顯字元，而 /r 後面的 /n 進行換行；
3，如果文本中 /r/n 的數量與 /n 的數相相同，那麼就優先採用 /r/n 方式來顯示，這時單獨的 /n 成為一個不可顯字元。

二、/n 與 /r 混合（即 Unix 與 Mac 換行混合）
1，如果文本中 /n 的數量大於 /r 的數量，那麼就以 Unix 的 /n 方式進行換行，這時 /r 成為一個不可顯字元；
2，如果文本中 /n 的數量小於 /r 的數量，那麼就以 Mac 的 /r 方式進行換行，這時 /n 成為一個不可顯字元；
3，如果文本中 /n 與 /n 的數量一樣多，就優先以 Unix 的 /n 方式進行換，同時 /r 成為一個不可顯字元。

三、/r/n 與 /r 混合（即 PC 與 Mac 換行混合）
1，如果文本中 /r/n 的數量大於 /r 的數量，那麼就以 PC 的 /r/n 方式進行換行，這時 /r 成為一個不可顯字元；
2，如果文本中 /r/n 的數量小於 /r 的數量，那麼就以 Mac 的 /r 方式進行換行，/r/n 其中的 /r 成為分行符號，後面的 /n 成為一個不可顯字元；
3，如果文本中 /r/n 與 /r 的數量一樣多，就優先以 PC 的 /r/n 方式進行換，單獨的 /r 成為一個不可顯字元。

四、/r/n、/n 與 /r 混合（即 PC、Unix、Mac 換行混合）
1，這三種換行哪種換行多就採用哪種方式；
2，如果三種換行數量或兩種換行數量相同時，以 /r/n、/n、/r 的優先順序確定換行模行。

實驗工具
文本顯示：EditPlus 3.00(254)beta
二進位修改：PSPad 4.5.3(2298)

 

http://topic.csdn.net/u/20090608/22/B4CBF61A-3B75-4350-BE68-A65DB006F361.html

17樓

 

0樓

上一次的“麻雀雖小、五髒俱全”挺受歡迎，今天再寫一個，不過這次講的是一個小問題的調試過程。

今天一個同事向我反映，說她的一段JAVA代碼，如果輸出的檔案尾碼是.idx，
則寫入的分行符號會丟掉，從Editplus中看到所有內容都出現在一行。

我感到很奇怪，檔案名稱和尾碼會影響流的內容？這明顯不可能，難道真的碰到靈異事件？
於是按照如下過程調試並解決問題：

1、寫獨立測試代碼
首先要驗證這個問題不是JAVA自身的問題，當即寫了測試代碼：

Java code

import java.io.BufferedWriter;import java.io.File;import java.io.FileWriter; public class TestIdx {    public static void main(String[] args) throws Exception{       File f=new File("d://test.idx");       BufferedWriter w=new BufferedWriter(new FileWriter(f));       w.write("abc");       w.write("/n");       w.write("123");       w.flush();       w.close();    }}

運行後，用UltraEdit開啟結果檔案，沒問題。
同事說，她直接用的FileWriter，於是稍作修改，再測，沒問題。
同事又說，她的檔案用追加模式開啟，再改，再測，還是沒有問題。

2、重現問題
感到有些不可思議，於是到同事機器上查看。
發現確實有此現象。

3、代碼走讀
查看代碼，沒發現特別之處。

4、做本機覆寫，嘗試定位問題
通過修改輸出檔案名、檔案尾碼，通過多次嘗試，發現問題不是出在.idx尾碼上，
因為任意新建立的檔案均無此問題，但如果繼續向她機器上已經存在的log.idx上追加就不行。

5、清理環境後嘗試重現問題
既然問題與特定檔案相關，則刪除該奇怪檔案（刪前先做備份，待問題解決後追究根源），
重新運行程式產生新的同名檔案，問題沒有再重現。
那麼，問題的根本原因肯定在此檔案內。

6、追根溯源
我要求同事將log.idx檔案發給我，我用UltraEdit開啟，發現換行正確，
而同事機器上用Editplus開啟同一個檔案則換行不正確。
於是又找到一個用Editplus的同事，開啟該檔案，換行也不正確。
因此，可以說明，檔案本身沒有大問題，問題在於文字編輯器對文本中的換行的處理方式不一致。

進一步用Ultraedit的二進位模式研究該文字檔，
發現該文字檔存在兩種換行格式：某些行之間是windows的“/r/n”，而某些行之間是unix的“/n”。
初步斷定這是造成差異的原因，Editplus對存在兩種斷行符號制式的檔案，可能只識別一種。

7、驗證猜測
在Ultraedit中建立空白文字檔，輸入：
123
456
789
在UE中切換到二進位模式，顯示為：
00000000h: 31 32 33 0D 0A 34 35 36 0D 0A 37 38 39          ; 123..456..789
用Editplus開啟，正常顯示為三行

在UE二進位模式下，刪除第二個0D，變成：
00000000h: 31 32 33 0D 0A 34 35 36 0A 37 38 39          ; 123..456.789
用Editplus開啟，後面的斷行符號不識別，顯示為兩行：
123
456789
再刪除第一個0D，變成：
00000000h: 31 32 33 0A 34 35 36 0A 37 38 39          ; 123.456.789
用Editplus開啟，正常顯示為三行
123
456
789

再恢複第二個0D，變成：
00000000h: 31 32 33 0A 34 35 36 0D 0A 37 38 39          ; 123.456..789
用Editplus開啟，前面的斷行符號不識別，顯示為兩行：
123456
789

8、結論
Editplus在判斷文字檔換行方面，
當文字檔中僅存在一種換行格式的時候（無論/r/n還是/n），Editplus都能正確識別
當文字檔中存在兩種換行格式的時候，以/r/n優先，單純的/n被忽略。

9、造成此現象的過程
該同事第一版代碼向檔案中追加的分行符號為“/r/n“，後來改成”/n“，但沒有刪除原來的檔案，
而檔案寫入方式為追加，導致檔案中出現兩種換行格式。

可能有些人在第六步完成後就停住，而我喜歡的是後面三步。