由於linux下vi無法直接寫入中文注釋，所以只能在windows下將寫好注釋的**傳到linux伺服器上，但是問題也就出現了，我在windows下用的是notepad++這款編輯器（感覺還挺不錯，有語法高亮識別）編輯源**的，加過注釋後上傳到linux上無論什麼語言環境（lang）都是亂碼，然後看了一下notepad++的設定，發現預設為ansi格式，於是就轉換為utf-8格式編碼（因為linux裡有這個格式的嘛），然後再上傳到linux伺服器上，linux也設為utf-8語言環境，可以看到中文注釋了！但是發現每個檔案第一行都會有「」這個字串。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
[plain]view plain
copy
test bomb or nobomb
~ ~
~ ~
~ ~
~ ~
~ 查詢bom結果：（set bomb ?）
[plain]view plain
copy
~ ~
~ ~
~ nobomb
更改bom結果：（set bomb）
[plain]view plain
copy
~ ~
~ ~
~ ~
bomb
儲存後再次開啟就會發現如下圖所示：
而且我們對於上傳過來的源**沒法做修改，網上有人說可以刪除bom（grep -i -r -l $'\xef\xbb\xbf' * | xargs sed -i 's/^\xef\xbb\xbf//;'），我試過了不行，不知哪位大牛指點下？檢查檔案中是否含bom的命令為：
[plain]view plain
copy
grep -i -r -l $'\xef\xbb\xbf' *
這個命令是有效的。
既然沒法靠在linux下有什麼命令刪除bom，那咱們只能從源頭處理了，編碼更改為無bom的utf-8編碼格式。notepad++有轉換此格式的選項：
轉換過後儲存下然後再傳到linux伺服器上，問題就解決了！！
另：這個問題在sun環境和hp環境下沒有此問題，我不清楚如果忽略這個問題在編譯時或程式執行時是否會產生異常，網上有人反映是有的，所以還是建議麻煩些也不要忽略此問題，誰曉得它會惹出什麼麻煩呢
Linux檔案中開始處的feff，行末的 M
windows中的換行符為 m,若直接把windows中的檔案複製到linux中，則在linux中的檔案開始處有乙個 feff 代表著檔案的開始，包含三個位元組 0xef,0xbb,0xbf 每一行的末尾會有乙個 m 在linux中 m的轉義字元為 r，所以去除 m可以使用python中的strip...
Linux下檔案的許可權
linux下檔案的許可權 1.什麼是linux下的檔案，檔案許可權有哪些。檔案 計算機中的資源在作業系統中的體現。在windows下檔案有型別，用副檔名來區別。在linux下沒有檔案型別，沒有副檔名。在linux下a.txt可能是可執行程式，a.exe可能是文字。linux下，檔案的命名規則 最長不...
Linux下檔案的複製
純乾貨，純 的。copy file.c include include include include include include define buffer size 1024 每次讀寫快取大小，影響執行效率 define src file name src file 源檔名 define d...