XOR 加密線上工具是一種瀏覽器工具，它使用位元互斥或運算子，將每個明文字元組與重複 UTF-8 金鑰的對應位元組結合，並以十六進位和 Base64 兩種形式顯示結果位元組，因此無論收件者預期使用哪種傳輸方式，相同的密文都可以順利傳遞。XOR 加密線上工具頁面正是以您的瀏覽器實作了這個結構，無需帳號、無需上傳、也無需伺服器端金鑰處理：頁面會讀取明文與金鑰，透過 TextEncoder API 將兩者編碼為 UTF-8，並使用索引 mod 金鑰長度 作為重複規則在本地套用 XOR。解密模式以嚴格的十六進位或 Base64 解析並進行嚴格的 UTF-8 驗證，反向執行運算，這表示許多錯誤的金鑰嘗試會以明顯的錯誤呈現，而不是靜默出現替代字元。雙方必須就三件事達成共識：包括大小寫與空格在內的金鑰文字、金鑰重複規則，以及所使用的輸出表示法。本指南其餘部分將逐步說明具體步驟、十六進位與 Base64 的權衡、UTF-8 慣例，以及您在傳送可逆 XOR 訊息之前應注意的安全性限制。
此工具如何從您的明文與金鑰產生結果
當您想傳送一則收件者可以使用共用金鑰還原的訊息時，XOR 加密法是最簡單的結構之一，它對稱、可逆，且簡短到可手動實作。XOR 加密線上工具正是將這個結構套用至您瀏覽器中的 UTF-8 位元組，並將相同的密文以十六進位和 Base64 兩種方式呈現，讓您能選擇最適合傳輸方式的格式。頁面會讀取明文與金鑰，使用 TextEncoder 與位元 XOR 運算子執行 XOR，並在本地呈現結果。整個過程沒有上傳步驟、沒有伺服器端金鑰、沒有帳號，事後也不需要清理任何遙測資料。
您需要提供給工具的：一段明文字串與一個金鑰字串。您會得到的：一模一樣的位元組序列，以兩種方式呈現。收件者需要的：以兩種支援形式之一呈現的密文，以及完全相同的金鑰文字。其他所有事項，包括位元組編碼、金鑰重複與表示法切換，都遵循同一條固定規則，因此兩個瀏覽器執行同一頁面會產生相同的輸出。為了讓轉換、呈現與複製保持流暢，頁面將明文與金鑰的長度上限皆設為 100,000 個 UTF-8 位元組；不接受更長的訊息。
逐步加密與解密訊息
完整流程只需在同個工具中執行幾個動作。為了讓雙方保持同步，請透過另一個管道分享金鑰，並在複製任何內容前先選定一種輸出表示法。
- 開啟 XOR 加密線上工具並選擇加密模式。
- 如您希望傳送的方式輸入明文，接著輸入金鑰文字。金鑰欄位會被視為 UTF-8 字元而非十六進位，因此單字 key 會變成位元組 6B 65 79。
- 執行轉換。頁面會使用 位元 XOR 運算子，將每個明文位元組與 keyBytes[index 模 keyLength] 進行 XOR，並將相同位元組以小寫十六進位與標準 Base64 顯示。
- 複製您打算傳送的十六進位或 Base64 格式，並告知收件者您使用的是哪一種。切換表示法並不會改變底層位元組。
- 若要還原文字，請切換至解密模式，選擇對應的表示法，貼上密文，並輸入完全相同的金鑰（含大小寫與空格）。
- 若十六進位解析失敗，請檢查是否有偶數個十六進位數字且沒有夾雜多餘字元。若 Base64 解析失敗，請確認字母表、填補字元，以及您的傳輸過程是否加入了空白字元。
十六進位 vs Base64：選擇輸出表示法
兩種表示法承載相同的位元組；差別只在於這些位元組的書寫方式。請選擇最符合收件者能讀取之傳輸方式的格式。
| 面向 | 十六進位 | Base64 |
|---|---|---|
| 長度 | 每個位元組兩個字元，因此大約是位元組數的兩倍 | 每三個位元組約四個字元，通常較短 |
| 字元集 | 0-9 與 a-f（或 A-F）；僅限安全 ASCII | A-Z、a-z、0-9、+、/ 加上 = 填補 |
| 可檢查性 | 易於逐位元組讀取並對齊原始位元組傾印 | 較為精簡，但較難以肉眼比對位元組串流 |
| 空白處理 | 為方便起見會予以忽略，因此換行包裝可保留下來 | 同樣會忽略，但多數傳輸層會保留下來 |
| 最佳適用情境 | 除錯輸出、搶旗賽（CTF）解題紀錄、通訊協定欄位 | 網址、JSON 字串、電子郵件本文、易於貼上的欄位 |
由於兩種形式承載相同的密文，收件者可以將十六進位結果複製到另一個工具（例如 Base64 轉十六進位轉換器）進行轉換，而無需重新執行加密。
金鑰處理：UTF-8 文字，而非十六進位字串
金鑰欄位會被視為純 UTF-8 文字。三個字母的單字 key 會依序變成三個位元組：6B、65、79。如果您改為將字面字元 6、B、6、5、7、9 輸入金鑰欄位，工具會使用六個位元組：36 42 36 35 37 39。這個區別是同一金鑰在不同工具中產生不同密文的最常見原因。
將金鑰解讀為十六進位位元組的工具遵循的是不同的慣例。它們會將字串 6B6579 轉換為三個位元組 6B、65、79。若要在本頁面中與此類工具對齊，您必須輸入實際的字元 k、e、y，而非其碼點表示的數字。大小寫很重要：大寫的單字 Key 是位元組 4B 65 79，會產生與小寫 key 不同的密文。金鑰內的空格具有意義；編碼後密文中的空白會為方便起見而忽略，但金鑰位元組本身並不會被修剪或正規化。
空白的明文與空白的金鑰都會被拒絕。如果您需要更長的金鑰，每多一個字元就會在循環中多增加一個位元組，而更長的金鑰需要更多暴力破解的工作量，儘管它們本身並不會將 XOR 變成安全的加密方式。
Unicode、多位元組字母，以及位元組花費在哪裡
本實作是對 UTF-8 位元組進行 XOR，而非 JavaScript UTF-16 碼元，也非使用者所感知到的字素群聚。一旦您的訊息包含變音符號、非拉丁字母，或表情符號，差異便會顯現出來。像 é 這樣的字元在 UTF-8 中佔兩個位元組，而一個典型的表情符號則佔四個。這些位元組各會消耗重複金鑰循環中的一個位置，因此金鑰索引的推進速度比可見字元數還快。
如果您要將密文與命令列程式、腳本語言函式庫或另一個網頁工具進行比對，請務必確認雙方在三件事上達成共識：明文的位元組編碼（此處為 UTF-8）、金鑰的位元組編碼（此處為 UTF-8），以及金鑰重複規則（此處為索引模 keyLength）。三者一致時，密文就會一致。若不一致，即使金鑰開頭僅有一個位元組的差異，也會連帶影響後續所有位元組。
安全現實：重複金鑰 XOR 能做與不能做的事
重複金鑰 XOR 是一種可逆的混淆，而非現代加密法。它沒有校驗和、沒有驗證標記、沒有鹽、沒有 nonce、沒有密碼延伸機制，也沒有金鑰管理系統。頁面本身會以淺白文字標示這一點，並建議對任何敏感內容使用經過審查的驗證加密系統。對於實際工作負載，請考慮使用以驗證模式封裝的經過審查的加密法，例如 AES-256-GCM；AES 加密線上工具會產生可攜帶的驗證封包，同時保護機密性與完整性。
即使面對被動觀察者，重複金鑰 XOR 仍有眾所周知的弱點。金鑰會重複，因此明文中的模式會以週期性模式洩漏到密文中。已知明文攻擊可直接還原金鑰位元組。金鑰越短越脆弱，因為週期較短。此外它缺乏完整性：能夠翻動密文中位元的攻擊者，將會改變另一端的對應明文位元組，而收件者無法察覺。若要深入了解這些限制，請參閱 XOR 加密安全嗎？重複金鑰的現實檢驗。請將此工具用於無害的謎題、互通性檢查、搶旗賽（CTF）練習與學習用途。請勿將其用於密碼、個人紀錄、付款明細、私鑰，或任何涉及機密性或完整性的資訊。
疑難排解結果不一致的問題
遵循相同慣例的兩位使用者必定會得到相同的位元組。當結果不同時，請依序檢查下列項目。首先，逐一字元確認金鑰文字，包括大小寫與任何不可見的空白，因為單一個不同的位元組就會使後續所有位元組跟著偏移。其次，確認傳輸過程並未修剪、換行或改寫密文，且雙方選定的十六進位與 Base64 表示法一致。第三，確認雙方都使用 UTF-8 處理明文與金鑰；若其中一方將金鑰視為十六進位位元組，位元組將會分歧。
即使金鑰錯誤，解密仍可能產生可讀文字，特別是在簡短的 ASCII 訊息中，因為隨機的位元組序列有時會碰巧形成有效的 UTF-8。因此，成功的 UTF-8 解碼並不能證明金鑰正確。若要驗證，請尋找重複的結構、與獨立的雜湊值進行比對，或先傳送一小段已知明文並確認位元組相符。若解密擲出嚴重的 UTF-8 錯誤，請將其視為金鑰錯誤的證據，而非頁面的 bug。
延伸閱讀：將檔案編碼變更為 UTF-8 並下載。