資管反應，一個頭盔看不到，此頭盔的資源配置在檔案的第一項，並且使用工具加密後再解密，對比原始檔案，發現第一項的配置不見了。

     使用記事本或者UE檢視第一項，未見有什麼異常。從能正常加密的第二項拷貝資料，修改id放在第一項，問題依舊。

     拷貝的方法也不行，說明應該不是格式問題或者大小寫問題。

     出錯的總是在第一項，推測可能檔案頭有點問題。用gvim或者vc開啟原始檔案，發現檔案首部有類似亂碼的東西。

     修改後儲存，發現可以正確加解密了。

     檔案頭類似亂碼一樣的東西，其實是BOM——“Byte Order Mark，它是一個Unicode字元，通常出現在文字的開頭，用來標識位元組序（Big/Little Endian），除此以外還可以標識編碼（UTF-8/16/32）”。

     用記事本“另存為”檢視發現，出錯的檔案是UTF8編碼的。而windows記事本在儲存UTF8編碼的檔案時，會自動新增BOM，推測是資管某次編輯將此檔案改為UTF8編碼的，於是多出BOM造成工具無法正常解析檔案進行加密。

    單個檔案要去除BOM，可以直接使用可以檢視到BOM的編輯器(gvim/vc6等)修改檔案首部的內容即可。或使用Sublime Text 2等編輯器的儲存為不帶BOM的格式。

    但要注意到是，gvim也並非總是能看到：

     資管在修改配置檔案，尤其是部分讀取方式較為嚴格的檔案時，要特別注意檔案頭的問題。對現有的配置檔案，用File BOM Detector進行檢查。

參考連結