"uptime.py" [noeol] 69L, 2311C
"system/uptime.py" 69L, 2312C
'noeol' 就是 'no end-of-line', 即“沒有行末結束符”
使用cat -A 命令可以看到兩個文件的不同之處在於最后一行是否有換行符
cat -A uptime.py
if __name__ == '__main__':$
uptime = uptime()$
print(uptime)$
root@UA4300D-spa:~/hanhuakai/pro_07/git_0709/ssapi#
cat -A system/uptime.py
if __name__ == '__main__':$
uptime = uptime()$
print(uptime)root@UA4300D-spa:~/hanhuakai/pro_07/git_0709/ssapi#
由於linux下vi無法直接寫入中文注釋，所以只能在windows下將寫好注釋的代碼傳到linux服務器上，但是問題也就出現了，我在 windows下用的是Notepad++這款編輯器（感覺還挺不錯，有語法高亮識別）編輯源代碼的，加過注釋后上傳到linux上無論什么語言環境 （LANG）都是亂碼，然后看了一下Notepad++的設置，發現默認為ANSI格式，於是就轉換為UTF-8格式編碼（因為linux里有這個格式的 嘛），然后再上傳到linux服務器上，linux也設為UTF-8語言環境，可以看到中文注釋了！但是發現每個文件第一行都會有 “<feff>”這個字符串。google了下發現問題的所在了。
原來這是個被稱作BOM(Byte Order Mark)的不可見字符，是Unicode用來標識內部編碼的排列方式的，在UTF-16、UTF-32編碼里它是必需的，而在UTF-8里是可選的。因 此，才會出現有的編輯器在文件頭部添加添加BOM、而有的語法解析器又不作處理的的混亂情況。所謂 BOM，全稱是Byte Order Mark，它是一個Unicode字符，通常出現在文本的開頭，用來標識字節序 （Big/Little Endian），除此以外還可以標識編碼（UTF-8/16/32），如果出現在文本中間，則解釋為zero width no-break space。
這個BOM可以在編輯文本時設置的，但是，只能在第一次編輯時才能設置它為bomb還是nobomb，編輯完並保存后就無法再更改編碼格式了。有關bomb命令：
#設置UTF-8編碼
:set fileencoding=utf-8
#添加BOM
:set bomb
#刪除BOM
:set nobomb
#查詢BOM
:set bomb?
如下例子：
用vi編輯一個測試文本test.txt
- test bomb or nobomb
- ~
- ~
- ~
- ~
- ~
- ~
- ~
- ~
- ~
查詢BOM結果：（set bomb ?）
- ~
- ~
- ~
- ~
- ~
- nobomb
更改BOM結果：（set bomb）
- ~
- ~
- ~
- ~
- ~
- ~
- bomb
保存后再次打開就會發現如下圖所示：
而且我們對於上傳過來的源代碼沒法做修改，網上有人說可以刪除BOM（grep -I -r -l $'\xEF\xBB\xBF' * | xargs sed -i 's/^\xEF\xBB\xBF//;'），我試過了不行，不知哪位大牛指點下？檢查文件中是否含BOM的命令為：
- grep -I -r -l $'\xEF\xBB\xBF' *
這個命令是有效的。
既然沒法靠在linux下有什么命令刪除BOM，那咱們只能從源頭處理了，編碼更改為無BOM的UTF-8編碼格式。Notepad++有轉換此格式的選項：
轉換過后保存下然后再傳到linux服務器上，問題就解決了！！
另：這個問題在sun環境和Hp環境下沒有此問題，我不清楚如果忽略這個問題在編譯時或程序運行時是否會產生異常，網上有人反映是有的，所以還是建議麻煩些也不要忽略此問題，誰曉得它會惹出什么麻煩呢
-- 轉自 http://blog.csdn.net/lyn_bigdream/article/details/8746241