Can you summarize the following document?
        
  字元U+FEFF如果出現在位元組流的開頭,則用來標識該位元組流的位元組序,是高位在前還是低位在前。如果它出現在位元組流的中間,則表達零寬度非換行空格的意義,使用者看起來就是一個空格。從Unicode3.2開始,codice_1只能出現在位元組流的開頭,只能用於標識位元組序,就如它的名稱——位元組順序標記——所表示的一樣;除此以外的用法已被捨棄。取而代之的是,使用codice_3來表達零寬度無斷空白。

  在UTF-16中,位元組順序記號被放置為檔案或字串流的第一個字元,以標示在此檔案或字串流中,以所有十六位元為單位的字碼的尾序(位元組順序)。  而統一碼中,值為codice_9的碼位被保證將不會被指定成一個統一碼字元。這意味著codice_5、codice_4將只能被解釋成小尾序中的codice_1(因為不可能是大尾序中的codice_9)。

  在UTF-8中,雖然在 Unicode 標準上允許位元組順序記號的存在,但實際上並不一定需要。UTF-8編碼過的位元組順序記號則被用來標示它是UTF-8的檔案。它只用來標示一個UTF-8的檔案,而不用來說明位元組順序。許多視窗程式(包含記事本)會需要新增位元組順序記號到UTF-8檔案,否則將無法正確解析編碼,而出現亂碼。然而,在類Unix系統(大量使用文字檔案,用於檔案格式,用於行程間通訊)中,這種做法則不被建議採用。因為它會妨礙到如解譯器指令碼開頭的Shebang等的一些重要的碼的正確處理。它亦會影響到無法識別它的程式語言。如gcc會報告原始碼檔開頭有無法識別的字元。而在PHP中,如果沒有啟用輸出緩衝(output buffering),它會使得頁面內容開始被送往瀏覽器(即:使用者標頭檔已被送出),這使PHP指令碼無法指定使用者標頭檔(HTTP Header)。位元組順序記號在UTF-8中被表示為序列codice_14,對大部分未準備好處理UTF-8的文字編輯器及網頁瀏覽器而言,在ISO-8859-1的環境中則會顯示codice_15。  雖然位元組順序記號亦可以用於UTF-32,但這個編碼很少用於傳輸,其規則如同UTF-16。對於已於IANA註冊的字符集UTF-16BE、UTF-16LE、UTF-32BE和UTF-32LE等來說,不可使用位元組順序記號。文件開頭的U+FEFF會被解釋成一個(已捨棄的)""零寬度無斷空白"",因為這些字符集的名字已決定了其位元組順序。對於已註冊字符集UTF-16和UTF-32來說,一個開頭的U+FEFF則用來表示位元組順序。
位元組順序記號(英語:byte-order mark,BOM)是位於碼點codice_1的統一碼字元的名稱。當以UTF-16或UTF-32來將UCS/統一碼字元所組成的字串編碼時,這個字元被用來標示其位元組序。它常被用來當做標示檔案是以UTF-8、UTF-16或UTF-32編碼的記號。