重複金鑰 XOR 是對稱運算，所有線上的基本 XOR 密碼都採用它:同一個函式既負責加密也負責解密，您提供一把金鑰，訊息便依據該金鑰一次一個位元組地循環。XOR Encryption Online 在瀏覽器中以 UTF-8 位元組執行此運算，並以兩種可互換的表示方式回傳結果——小寫十六進位與標準填補 Base64——讓您能依接收端系統的格式貼上。資料不會離開您的裝置:頁面不會上傳明文、金鑰或密文，且空白輸入或空白金鑰會直接被拒絕。這項慣例刻意嚴格:明文與金鑰皆以 UTF-8 編碼，每一個明文位元組皆與相同偏移量 (取模金鑰長度) 的金鑰位元組結合，解密時則在致命性 UTF-8 解碼前對解析後的位元組套用完全相同的運算。由於 XOR 是自反運算，在十六進位與 Base64 之間切換輸出只會改變位元組的表示方式，並不會改變底層的密文。
XOR Encryption Online 如何轉換您的文字
XOR 密碼是逐位元組套用的位元互斥或運算:位元不同時結果為 1，相同時為 0。使用重複金鑰時，明文第 i 個位置會與金鑰第 i mod keyLength 個位置進行 XOR。以同一把金鑰套用相同規則兩次即可還原原始位元組——這就是為什麼 XOR Encryption Online 在兩個方向上都使用相同的形式。此頁面完全在您的瀏覽器中運作，使用 TextEncoder 將您的文字轉為 UTF-8 位元組，接著對每個位元組執行 位元 XOR 運算，最後再進行序列化。
| 表示方式 | 您看到的內容 | 適用情境 |
|---|---|---|
| Hex | 每個位元組以兩個小寫、連續的十六進位數字表示 | 檢查個別位元組、與已知向量比對，或對應會輸出十六進位的工具 |
| Base64 | 使用標準字母集並加上正確的填補字元 | 透過表單欄位、電子郵件、即時通訊，或任何會破壞空白的管道貼上 |
頁面在加密成功後會同時顯示兩種形式，讓您能複製符合接收端需求的任一種。兩者之間切換並不會改變底層的 XOR 密文——只會改變位元組到文字的編碼方式。
三個步驟完成加密或解密
- 選擇 encrypt，輸入或貼上明文，並輸入精確的重複金鑰。金鑰會被視為 UTF-8 文字處理，而非十六進位。
- 複製主要的十六進位或 Base64 結果，並告知接收端您使用的是哪一種表示方式。兩種形式皆可解碼回同一段位元組序列。
- 若要還原文字，接收端需選擇 decrypt，從輸出下拉選單中挑選對應的格式，貼上密文，並輸入完全相同的金鑰——包含大小寫、空格及每一個 Unicode 字元。
若金鑰、密文或位元組編碼有任何差異，還原後的文字將無法與原始內容相符。這正是嚴格慣例的目的:當您與命令列程式、程式庫或其他線上工具比對結果時，能消除歧異。
Hex 與 Base64:選擇正確的輸出
Hex 為每個位元組寫出兩個十六進位數字，是最容易肉眼檢視的形式。Base64 則以較短、便於傳輸的字串表示相同的位元組，即使在會去除空白或換行的欄位中複製貼上也能完整保存。XOR Encryption Online 介面同時呈現兩者，因為位元組序列完全相同，選擇僅取決於下一個系統的期望。
| 屬性 | Hex | Base64 |
|---|---|---|
| N 個位元組的長度 | 2N 個字元 | 約 4N/3 個字元加上填補 |
| 允許的字元 | 0–9 與 a–f (忽略空白) | A–Z、a–z、0–9、+、/ 以及 = 填補字元 |
| 空白容忍度 | 會被忽略，有助於換行 | 不屬於字母集，在嚴格解析下將會失敗 |
| 典型用途 | 手動檢查、比對測試向量 | 貼到即時通訊、電子郵件、JSON 承載中 |
解密模式會以嚴格方式解析所選的表示方式。Hex 必須包含完整的位元組配對，且僅能有十六進位數字——空白為求方便會被忽略，但出現非十六進位字元則會引發錯誤。Base64 必須使用標準字母集並加上正確的填補。解析後的位元組會與 UTF-8 金鑰進行 XOR，接著以致命性 UTF-8 驗證進行解碼，這能將許多錯誤的金鑰以可見的錯誤顯示出來，而不是產生一串替換字元。
為何同一把金鑰在其他工具中看起來不同
許多 XOR 工具提供「hex 金鑰」模式，將您的輸入視為原始位元組。XOR Encryption Online 並非如此:金鑰欄位會被視為文字處理。鍵詞 key 會成為 UTF-8 位元組 6B 65 79——共三個位元組。若您在金鑰欄位中輸入 6B6579，頁面會將該字串中的六個可見字元當作金鑰，而非其所代表的三個位元組。此差異是不同工具或命令列程式結果不一致最常見的原因。
Unicode 文字所佔的位元組數可能多於一個可見字元。單一表情符號或非拉丁文文字字元可能會佔用數個金鑰位置，因此金鑰的循環是以位元組為界，而不是以字元為界。實作上是對位元組進行 XOR，而不是 JavaScript UTF-16 碼元，也不是使用者所感知的字元簇——這項固定的定義能讓結果在符合標準的瀏覽器中保持可重現。
手動演算單一位元組
若要了解此運算如何處理單一位元組，可以考慮字母 A 以金鑰字母 k 加密。A 的 UTF-8 位元組為 0x41 (二進位 01000001)。k 的 UTF-8 位元組為 0x6B (二進位 01101011)。逐位元進行 XOR:
- 位元 7:0 XOR 0 = 0
- 位元 6:1 XOR 1 = 0
- 位元 5:0 XOR 1 = 1
- 位元 4:0 XOR 0 = 0
- 位元 3:0 XOR 1 = 1
- 位元 2:0 XOR 0 = 0
- 位元 1:1 XOR 1 = 0
- 位元 0:1 XOR 1 = 0
結果為 00101010，十六進位即 0x2A——星號字元。再以 k 對 0x2A 執行相同的 XOR，即可還原為 0x41，即 A。這就是整個演算法的一句話總結:同一把金鑰會自我反轉，這就是此密碼對稱的原因。
限制、錯誤及頁面將拒絕的內容
輸入與金鑰資料上限為 100,000 位元組，以維持轉換、呈現與複製的流暢度。明文中的空白具有意義——每個空格、定位字元與換行皆會成為密文中的位元組。編碼密文中的空白僅在換行時會被忽略;除此之外不會進行任何清理或猜測。空白輸入或空白金鑰會立即回傳錯誤。
錯誤的金鑰通常會產生無效的 UTF-8，頁面會將其回報為可見的解碼錯誤，而不是靜默地替換為替換字元。這是刻意的設計:讓您知道金鑰錯誤或密文已損毀。權衡之下，某些錯誤的位元組序列恰好會形成有效字元，尤其是簡短的 ASCII 訊息。因此，即使成功解碼 UTF-8 也無法證明金鑰正確。請透過獨立的管道確認有意義的明文。
此頁面沒有校驗碼、驗證標籤、鹽、nonce、密碼強化或金鑰管理系統。Hex 輸出為小寫且連續，Base64 輸出使用標準填補，而解析後的位元組會在致命性 UTF-8 解碼前與 UTF-8 金鑰進行 XOR。
重複金鑰 XOR 的適用與不適用情境
重複金鑰 XOR 適用於可逆的混淆、教學、互通性檢查，以及目標在於展示概念而非保護秘密的搶旗活動。它同時也能作為健全性檢查:若兩個系統對相同輸入無法產生相同的 XOR 輸出，代表某處的慣例不同。
它不適用於任何需要機密性或完整性的情境。金鑰重複會暴露模式。已知明文可直接還原金鑰位元組。短金鑰尤其脆弱，攻擊者可以在不被偵測的情況下翻轉密文中的位元以翻轉明文中的位元。請勿將本頁用於密碼、個人記錄、付款明細、私鑰，或任何不容許金鑰錯誤的資訊。若需真正的安全性，請選擇能妥善處理金鑰並抵禦竄改的 認證加密 系統——請參閱 XOR 加密安全嗎?重複金鑰的現實檢驗 以取得完整分析。
若要在已共享祕密金鑰的兩人之間進行日常文字調換，請執行 XOR Encryption Online，約定金鑰文字與輸出表示方式，加密一次後分享密文，再於另一端解密一次。若結果失敗，請比對金鑰中的精確字元，並確認傳輸過程沒有修剪或重寫密文。本頁將警告視為工具的一部分:熟悉的加密標籤絕不應暗示重複金鑰 XOR 無法提供的防護。
若您正在權衡選項，什麼是密碼?搭配 A1Z26 的白話指南 對此有詳細說明。