在此任務中，「如何移除 go」是指從已解碼的文字中移除一個不需要的開頭 BOM：將文字貼到 BOM Remover，執行工具，確認狀態顯示已移除一個開頭的 U+FEFF，然後複製檢查過的結果。BOM Remover 只會檢查位置零：如果第一個 UTF-16 程式碼單元是 U+FEFF，它會恰好移除該單元；如果不是，輸出就會與輸入完全相同。它不會修剪字串、替換所有類似 BOM 的字元、正規化 Unicode、修復亂碼，或判定原始檔案編碼。稍後出現的 U+FEFF 字元——包括換行符後的一個、結尾的一個，或重複開頭序列中的第二個字元——都會保持不變。處理與複製作業都在目前的瀏覽器分頁中進行，文字不會上傳至 Lizely 或傳送至外部服務。因此，若解析器、確切的字串比較、shebang 或欄位名稱受到一個不需要的首字元影響，而貼上的值已完成解碼且已確認該開頭字元不需要，這項工具便適合用於這些情況。
BOM 在解碼後會變成什麼
U+FEFF 是與位元組順序標記相關聯的 Unicode 字元。在已解碼文字串流的開頭，它可能代表編碼簽章。UTF-8 位元組簽章是 EF BB BF，而 UTF-16 與 UTF-32 各自有其位元組簽章。位元組一旦解碼成瀏覽器文字區欄位，這些簽章就不再以位元組形式存在。因此，BOM Remover 可以看到開頭的 U+FEFF 字元，但無法判斷是哪一種編碼產生了該文字。
WHATWG 編碼標準會區分位元組解碼程序與最終產生的字元串流。這項區別是本任務的核心：BOM Remover 是在解碼完成後才開始運作，因此，當你信任的解碼器或編輯器顯示開頭有 U+FEFF，而解析器、比較、shebang 或欄位名稱無法接受它時，就應使用這項工具。它無法選擇正確的解碼器、轉換 UTF-16 位元組、驗證 UTF-8，或確立原始位元組順序。如果該首字元可能是後續工作流程所需的刻意簽章，請先保留它，直到確認預期行為為止。
三個步驟移除一個開頭 BOM
- 貼上已解碼的文字。 將文字放入輸入欄位中，如果存在看不見的開頭 U+FEFF，也要包括在內。不要貼上原始位元組並期待工具替你解碼。輸入內容必須維持在或低於 200,000 個 UTF-16 程式碼單元；剛好達到上限可以接受，但多一個程式碼單元便會在處理前遭拒。
- 執行移除工具並閱讀狀態。 摘要會說明是否已移除一個開頭 U+FEFF，或是否找不到開頭的 U+FEFF。它也會以 UTF-16 程式碼單元回報完整輸出長度，因此請依據狀態判斷，不要只看可見字元就認定是否成功。
- 在於本機複製前，檢查完整輸出。 檢查第一個字元、換行符、空白，以及任何刻意保留在後面的 U+FEFF 內容。複製完整結果，只有在確認不需要的首字元已消失且其餘文字正確後，才替換原文。
若輸入只包含一個 U+FEFF，會正確產生空白輸出，而且結果面板仍會顯示。空白輸入也是有效的未變更結果。這些情況應依摘要確認，而不是依據輸出欄位中是否還看得到可見字元來判斷。
複製前先閱讀狀態
狀態與輸出面板會顯示開頭 BOM 與文字中其他位置 BOM 之間的差異。行為完全取決於第一個程式碼單元，而不是全域搜尋。
| 起始文字 | BOM Remover 的處理方式 | 保留的內容 |
|---|---|---|
| 一個開頭 U+FEFF，後接內容 | 恰好移除第一個 U+FEFF | 該程式碼單元之後的所有文字 |
| 沒有開頭的 U+FEFF | 傳回完全相同的輸入 | 完整且未變更的文字 |
| 兩個連續的開頭 U+FEFF 字元 | 只移除第一個字元 | 第二個 U+FEFF 仍留在開頭 |
| U+FEFF 出現在內部、換行符後或結尾 | 找不到可移除的開頭 U+FEFF | 後續出現的位置保持不變 |
| 輸入只包含一個 U+FEFF | 產生有效的空白輸出 | 沒有任何字元保留 |
| 輸入為空白 | 回報沒有開頭的 U+FEFF | 有效的空白結果仍會顯示 |
兩個開頭 U+FEFF 字元需要格外小心。Unicode 將第一個描述為可能的簽章；當必須表示開頭的零寬不換行空格時，第二個則是初始內容字元。BOM Remover 會移除第一個，並讓第二個留在輸出開頭。再次執行工具會移除此時位於開頭的第二個字元，因此重複操作前請先檢查狀態。一次點擊絕不會移除超過一個程式碼單元。
Unicode 指引也說明，非初始位置的 U+FEFF 在歷史上具有零寬不換行空格的語意，並屬於內容的一部分，儘管新文字建議採用 U+2060 WORD JOINER。因此，移除所有出現位置會造成破壞，這也是本工具刻意只處理第一個位置的原因。
保留其餘文字
這項轉換是依位置處理，而不是一般性的清理程序。實作會檢查第一個 UTF-16 程式碼單元，並原樣傳回其餘字串。它不會呼叫修剪函式、replaceAll 或全域正規表示式。
- CRLF 與 LF 換行符、定位字元、NUL 字元及空白均會保留。
- Emoji、組合記號、代理項配對與非拉丁文字均會保留。
- 位於內部、換行符後、結尾及開頭第二個位置的 U+FEFF 字元均會保留。
所有剩餘文字都會透過確切的切片操作複製。瀏覽器在視覺上可能會正規化部分不可見字元在文字區欄位中的顯示方式，但工具產生的 JavaScript 字串仍是原字串，最多只移除第一個 U+FEFF 程式碼單元。因此，當恰好有一個不需要的首字元不同，而每個其他程式碼單元都必須保留時，這項工具便適合使用。
處理限制與剪貼簿狀態
輸入最多可包含 200,000 個 UTF-16 程式碼單元，空白字串也包含在內。剛好達到上限的輸入可以接受，下一個程式碼單元則會在處理前遭拒。輸出另有獨立的 200,000 個程式碼單元限制：剛好達到上限可以接受，但上限加一便會遭拒。不會有任何內容遭縮短、取樣、部分傳回，或因 HTML 的 maxlength 屬性而遭到無聲阻止。由於這項轉換會移除零個或一個程式碼單元，有效輸入在處理期間不可能擴展，但獨立的輸出檢查仍是明確的安全防護。
編輯或清除輸入時，前一次輸出、錯誤、摘要、移除旗標、複製訊息及待執行複製計時器都會立即清除。超過上限的錯誤不會讓較舊的成功結果繼續顯示。剪貼簿存取是非同步的，因此每次複製都會收到一個世代識別碼；編輯、清除、重試或卸載元件都會使該世代失效。延遲收到的剪貼簿權限回應無法還原過期的「已複製」狀態，而遭拒的請求仍會讓完整的唯讀輸出可供手動選取。
瞭解何時不應以移除 BOM 解決問題
BOM Remover 不是一般性的不可見字元清除器、Unicode 正規化工具、空白修剪器或編碼修復服務。也不應使用它來剝除串接文件中所有類似 BOM 的字元。其範圍不包含：
- 偵測已解碼文字原本使用的是 UTF-8、UTF-16 或 UTF-32。
- 轉換 UTF-16 位元組、驗證 UTF-8 位元組序列或修復亂碼。
- 移除任意的零寬字元，或變更空白與換行符。
如果由你控制檔案載入方式，請選擇具備適當 BOM 政策的解碼器。如果將文字貼到移除工具中，請先確認開頭的 U+FEFF 確實不需要。對指令碼解析器而言，MDN JavaScript 詞法文法參考資料提供了 BOM 與 hashbang 語法的相關背景。安全的決策範圍很窄：文字已完成解碼，恰好有一個不需要的開頭 U+FEFF，而且該首字元正在干擾解析器、比較、shebang、欄位名稱或類似的首字元檢查。
若要深入瞭解，請參閱 Clipboard Viewer Online Explained：在本機檢查文字。