重複金鑰 XOR 如何產生密文
XOR Encryption Online 會在 UTF-8 明文與重複金鑰之間進行逐位元組的互斥或 (XOR) 運算，然後將產生的位元組分別序列化為小寫十六進位與標準帶填補的 Base64，方便接收端依其系統支援的表示方式擇一使用。瀏覽器會以 TextEncoder (UTF-8) 轉換明文與金鑰，逐位元組走訪明文，並將每個明文位元組與金鑰中相同索引位置的位元組結合。當明文長度超過金鑰時，金鑰索引會繞回位置零並重複循環，這也是這種加密方式稱為「重複金鑰 XOR」的原因，也說明了在符合標準的瀏覽器上，相同的金鑰搭配相同的明文必然會產生相同的密文。十六進位每個位元組以兩個字元表示，讓輸出結果在肉眼檢查長度與樣式時更為直觀。Base64 則將同樣的位元組壓縮為大約每三個位元組四個字元，因此能順利穿越 JSON、查詢字串，以及會去除或跳脫特殊字元的聊天室介面。在工具上切換輸出格式並不會改變底層的 XOR 轉換，僅改變可顯示的表示方式。加密會同時顯示兩種形式，讓傳送端可選擇接收端期望的表示方式；解密則接受對應的形式，嚴格解析位元組後套用相同的重複金鑰 XOR，並執行嚴格的 UTF-8 解碼，因此錯誤的金鑰通常會以明確的錯誤訊息呈現，而不是悄悄出現取代字元。
整個轉換過程完全在瀏覽器中執行，這代表明文、金鑰與密文都不會離開您的裝置。沒有 API 呼叫、不需要註冊，也沒有遠端處理步驟。兩位想要交換訊息的使用者只需約定完全一致的金鑰文字，以及要在傳輸通道中使用的表示方式，接著雙方各自在本機執行相同的慣例即可。
以具體的範例來說明，取關鍵字 key，其 UTF-8 位元組為 6B 65 79，並將其套用至單位元組明文 A（UTF-8 位元組 41）。XOR 運算結果為 41 XOR 6B = 2A，因此密文開頭的位元組為 2A，以十六進位字串表示為 2a，或以 Base64 字串表示為 Kg==。MDN 參考文件中關於位元層級 XOR 運算子的章節記錄了底層運算，而 MDN 的 TextEncoder 頁面則說明了在 XOR 執行前產生位元組序列的 UTF-8 編碼步驟。
| 屬性 | 小寫十六進位 | 標準帶填補的 Base64 |
|---|---|---|
| 可見的位元組邊界 | 是，每個位元組兩個字元 | 否，四個字元大約編碼三個位元組 |
| 相同訊息下的長度 | 每個位元組約兩個字元（較長） | 每個位元組約一又三分之一個字元（較短） |
| 最常出現的地方 | 除錯紀錄、十六進位傾印、原始位元組的複製貼上 | JSON 值、HTTP 標頭、電子郵件與聊天訊息的承載內容 |
| 密文內部的空白字元 | 忽略 | 忽略 |
| 填補規則 | 無 | 不完整的群組必須以結尾 = 字元填補 |
| 何者算作格式錯誤 | 字元數為奇數或出現非十六進位數字 | 出現標準字母表以外的字元，或填補錯誤 |
在 XOR Encryption Online 中以相同的明文與金鑰執行一次並確認結果，再行傳送。另一份關於挑選輸出格式的指南，會透過具體範例逐步說明相同的取捨。
加密訊息
加密會接收 UTF-8 明文與重複金鑰，並同時以十六進位與 Base64 產生密文位元組。當您是傳送端時，請使用此流程。
- 在 XOR Encryption Online 上選擇加密模式。
- 在訊息欄位中輸入或貼上明文。頁面會將其編碼為 UTF-8，且整個轉換完全在瀏覽器中執行，因此文字不會離開您的裝置。
- 在金鑰欄位中輸入金鑰。請將金鑰視為文字：您輸入的字面字元就是會被 XOR 的 UTF-8 位元組，因此 key 代表位元組 6B 65 79，而不是將位元組 6B 65 79 解讀為十六進位字面意義。
- 從兩個輸出欄位讀取密文。十六進位與 Base64 字串編碼的是相同的位元組，因此請複製接收端系統所期望的任一種表示方式，並告知對方您使用的是哪一種。
- 透過您平時慣用的任何管道傳送密文，並以離線方式另外交付金鑰。當您告知接收端時，必須逐字元精確重複金鑰，包括大小寫與任何空格。
解密訊息
解密會還原 XOR 結果，並驗證回復的位元組是否構成有效的 UTF-8。當您是接收端時，請使用此流程。
- 將工具切換至解密模式。
- 選擇與您收到的密文相符的表示方式，十六進位或 Base64。若選錯，解析步驟會在 XOR 執行前先拒絕輸入。
- 將密文貼入對應的欄位。密文內部的空白字元會被忽略，因此經換行包裝的十六進位與換行的 Base64 皆可使用，但嚴格的解析器不會自動補上遺漏的 = 填補，也不會修正奇數個十六進位數字的情況。
- 逐字元輸入完全相同的金鑰文字，包括大小寫與任何空格。金鑰會以產生密文時相同的重複循環方式在明文上循環。
- 讀取回復的明文。若結果顯示為錯誤而非文字，則金鑰或表示方式幾乎必然與傳送端的設定不符，請在將輸出視為損壞前重新檢查兩者。
決定解密是否能成功的關鍵規則
大多數「接收端收到亂碼」的問題，都可追溯至一小套慣例，而這些慣例在工具中都是固定的。
金鑰是文字，不是十六進位。金鑰欄位會被解讀為 UTF-8 字元，接著將這些字元轉換為位元組進行 XOR。單字 key 會變成三個位元組 6B 65 79。若您改輸入 6B6579，工具會使用六個位元組（即數字六、B、六、五、七、九）進行處理，結果將無法與任何將金鑰解讀為原始十六進位的工具相符。以 UTF-16 程式碼單元運作，或將金鑰視為十六進位字串的工具，也會得出不同的結果。慣例的一致性比金鑰長度更為重要。
進行 XOR 的是位元組而非字元。明文與金鑰皆為 UTF-8，因此非 ASCII 文字與表情符號各自會佔用數個位元組。每個表情符號會以其 UTF-8 位元組長度推進金鑰索引，這代表金鑰中的多位元組字元每顯示一個字元就會消耗多個位置。XOR 在位元組層級運作，永遠不是在字形 (grapheme) 層級，因此結果在符合標準的瀏覽器之間是可重現的，但接收端必須以相同的 UTF-8 位元組慣例解碼輸出，才能還原原本的字形。
空白在明文與金鑰中是有意義的，在密文中則會被忽略。金鑰結尾的空格會使後續的位元組產生變化，因為它會位移循環；但十六進位或 Base64 密文內部因換行而出現的換行或空格，會因換行包裝而被忽略。空白永遠不會自動被去除，而空白的明文或空白的金鑰會直接被拒絕。
結果有嚴格的容量上限。明文與金鑰合計上限為 100,000 位元組，以維持轉換、渲染與複製操作的流暢。超過此上限的訊息需要分割、分塊編碼，或改用其他工具處理。轉換本身並不取決於大小，但頁面為維持瀏覽器的流暢度而強制實施此限制。
UTF-8 解碼成功並不代表金鑰正確。解密步驟會執行嚴格的 UTF-8 驗證，因此許多錯誤的金鑰會產生錯誤訊息，而非一串取代字元。但某些錯誤的位元組序列恰好會構成有效的 UTF-8 字元，特別是在短小的 ASCII 訊息中，因此乾淨的解碼雖是必要條件，但並非充分條件。請透過獨立管道確認有意義的明文後，再予以信任。
何時不該使用此工具
XOR Encryption Online 是可還原的混淆方式，而非經身分驗證的加密。重複金鑰會暴露統計規律，已知的明文片段會洩漏產生該密文所需的金鑰位元組，較短的金鑰會同時放大這兩項弱點，且攻擊者可在不被偵測的情況下翻轉密文中的位元，因為此方法沒有總和檢查、沒有身分驗證標籤、沒有 nonce、沒有 salt，也沒有金鑰延伸 (key-stretching) 程序。此工具同樣沒有金鑰管理系統，因此訊息的安全性完全取決於金鑰字串本身的保密程度。
因此，請勿將本頁用於密碼、付款明細、私鑰、個人紀錄，或任何涉及機密性或完整性需求的資訊。請選擇經審查的、具身分驗證的加密方式，例如在經過審核的應用程式中使用 AES-GCM，或使用會代您處理金鑰與 nonce 的公開程式庫。此警告屬於工具產品行為的一部分，而非泛用免責聲明：加密的標籤不應暗示重複金鑰 XOR 轉換無法提供的保護。
請將其結果視為適合用於解題、課堂練習、搶旗賽 (CTF) 挑戰，以及已約定位元組慣例的系統之間的互通性檢查。如需深入了解安全性取捨，請參閱重複金鑰的現實檢驗指南，其中會以具體範例逐一拆解各項弱點，並說明單一重複金鑰所帶來的便利性為何同時也是其主要攻擊面。