XOR 密碼計算工具會對 UTF-8 明文的每一個位元組與重複密鑰的對應位元組執行位元互斥或（XOR）運算，將每個輸入轉換為可還原的密文，並能以十六進位或 Base64 形式顯示。由於 XOR 是自身的反函數，再次使用同一把密鑰即可還原原始位元組——前提是雙方對位元組編碼、重複規則以及所使用的表示方式達成共識。XOR Encryption Online 工具會在您的瀏覽器中執行完全相同的轉換：明文與密鑰皆以 UTF-8 編碼，每個明文位元組會與 keyBytes[index modulo keyLength] 進行 XOR，結果會以小寫十六進位與標準帶填充 Base64 序列化。內容不會上傳，密鑰會視為純文字而非原始十六進位位元組，輸入上限為 100,000 位元組，以保持轉換與複製操作的反應速度。本頁面適用於教學用密碼學、CTF 解題挑戰，以及兩個腳本之間的互通性檢查——而非用於保護密碼、付款資訊、私鑰或任何其他敏感資料。
重複密鑰 XOR 密碼的運作方式
XOR 是一種位元運算，當兩個輸入位元不同時回傳 1，相同時回傳 0。套用至整個位元組時，明文的每個位元會與密鑰的對應位元進行比較，產生一個新位元組，該位元組與任一輸入都沒有明顯的相似性。當同一把密鑰再次對密文執行 XOR 時，原始位元組會原封不動地還原——正是這種可逆性使 XOR 成為可行的對稱轉換。在重複密鑰的建構中，當訊息長度超過密鑰時，密鑰會循環重複，因此明文的位置 i 會與密鑰的位置 (i modulo keyLength) 結合。
具體而言，以位元組 0x41 0x42 0x43 編碼的明文 "ABC" 與單一位元組 0x4B 編碼的密鑰 "K" 為例，轉換過程如下：0x41 XOR 0x4B 等於 0x0A，0x42 XOR 0x4B 等於 0x09，0x43 XOR 0x4B 等於 0x08。這三個位元組即為計算工具所輸出的結果。在十六進位中，它們顯示為字串 "0a0908"，每個位元組佔兩個字元；在標準帶填充 Base64 中，則顯示為四個字元的字串 "CgkI"。將 "CgkI" 以相同的密鑰 "K" 重新輸入解密模式會還原為 "ABC"。兩個方向使用相同的位元組運算，正是使該密碼可逆、且輸出可在遵循相同慣例的人員、腳本與命令列工具之間交換的原因。
由於 XOR 是針對個別位元而非區塊或替換表進行運算，輸出長度永遠與輸入相同。明文中的空白字元會被保留，因此具有意義；編碼後密文中的空白字元則會被剖析器忽略，這使得長串的十六進位字串易於跨多行換行而不會破壞解密。XOR 運算本身的說明請參考 MDN 的 Bitwise XOR reference，而位元組層級的編碼步驟則使用瀏覽器內建的 TextEncoder API，可在所有符合標準的瀏覽器中維持一致的行為。
使用 XOR 密碼計算工具加密文字
加密流程完全在您的瀏覽器中執行，並同時以兩種表示方式產生相同的密文。若要獲得乾淨且可重現的結果，請依照下列步驟進行：
- 開啟 XOR Encryption Online 頁面，並確認模式設定為加密而非解密。
- 在訊息欄位中輸入或貼上您要轉換的明文；訊息中的空白字元會被精確保留。
- 在密鑰欄位中輸入重複密鑰，必須完全依照您希望收件者輸入的方式——包括所有大小寫與所有空格——因為密鑰會視為 UTF-8 文字處理。
- 執行本機轉換；頁面會以小寫十六進位與標準帶填充 Base64 兩種形式同時顯示結果位元組。
- 複製收件者所預期的表示方式，並告知對方您發送的是哪一種形式，以便其在介面上選擇對應的選項。
這兩種輸出並非不同的密文。十六進位與 Base64 只是表示相同位元組的不同方式：十六進位每個位元組使用兩個十六進位數字，方便檢查與需要原始位元組輸入的工具；Base64 則約縮短三分之一，且能安全地通過文字欄位、JSON 酬載以及會去除或重寫不可列印字元的 URL。在計算工具上切換表示方式並不會改變 XOR 輸出本身——僅會改變可列印的形式。
將密文解密回明文
解密沿用相同的 XOR 規則，這正是該密碼自反的原因。若要從十六進位或 Base64 訊息還原原始文字，請依照下列步驟進行：
- 將頁面切換至解密模式。
- 選擇與所接收內容相符的表示方式——十六進位或 Base64——以便剖析器使用正確的字母集與填充規則。
- 將密文貼入輸入欄位。密文中的空白字元與換行會被忽略，因此換行的內容也能正常解碼。
- 輸入相同的密鑰，包括大小寫與所有空格，然後執行轉換。
- 讀取還原後的明文。頁面會對結果執行嚴格的 UTF-8 驗證，因此不正確的密鑰通常會產生明確的錯誤，而非靜默出現替代字元。
若解密失敗，請逐字元比對密鑰與所發送的內容，並確認傳輸過程未修剪或重新編碼密文。成功的 UTF-8 解碼並不代表密鑰正確——某些錯誤的位元組序列仍可能形成有效字元，特別是在較短的 ASCII 訊息中，許多錯誤的密鑰恰好會落入可列印範圍。請透過獨立的管道（例如電話、獨立的聊天視窗或您信任的檢查碼）確認有意義的明文。
十六進位 vs Base64：選擇正確的輸出
十六進位與 Base64 是同一組密文位元組的可互換表示方式。選擇通常取決於長度、傳輸方式以及接收端系統的預期。下表概述在兩個人或兩個腳本之間交換 XOR 密文時的實際差異。
| 屬性 | 十六進位 | Base64 |
|---|---|---|
| 每個位元組的編碼 | 2 個字元 | 約 1.33 個字元 |
| 字元集 | 0–9, a–f | A–Z, a–z, 0–9, +, / |
| 填充 | 無 | 非對齊輸入時使用 = |
| 100 位元組的典型大小 | 200 個字元 | 約 136 個字元 |
| 適用場景 | 檢查、位元組層級工具、除錯紀錄 | 文字欄位、JSON 酬載、URL、複製貼上 |
| 空白字元處理 | 剖析器忽略 | 剖析器忽略 |
雙向的嚴格剖析是協定的一部分。十六進位必須包含完整的位元組對且僅限十六進位數字，但空白字元會因換行而被忽略。Base64 必須使用標準字母集並具備正確的填充。剖析後的位元組會與 UTF-8 密鑰進行 XOR，然後以嚴格的 UTF-8 驗證解碼，因此格式錯誤的輸入會引發明確的錯誤，而非產生靜默毀損的明文。若下游工具預期 Base64 但您只有十六進位字串，請先將十六進位解碼為位元組；若預期十六進位但您有 Base64，則請將那些位元組重新編碼為十六進位。相同的密文可在兩種表示方式之間轉換，而 XOR 輸出本身不會有任何改變。
會影響結果的密鑰處理規則
密鑰欄位是純文字欄位，而非十六進位欄位。輸入六個可見字元 "6B6579" 會佔用六個密鑰位置——即 UTF-8 位元組 0x36 0x42 0x36 0x35 0x37 0x39，每個字元對應一個位元組——其結果將與將這些字元解讀為原始十六進位的工具不符。若要使用字面位元組 0x6B 0x65 0x79 作為密鑰，請改為輸入三個字元 "key"。在與命令列程式或程式庫比較結果時，此區別至關重要：將密鑰視為原始十六進位位元組、以 UTF-16 程式碼單位運作，或在使用者感知字元群集層級運作的工具，遵循的是不同的慣例，將無法與本頁面達成一致。
明文與密鑰皆會在 XOR 執行前以 UTF-8 編碼，因此端到端支援 Unicode 文字。佔用多個 UTF-8 位元組的可見字元——例如表情符號、帶變音符的拉丁字母或 CJK 字形——會在單一字元中消耗多個密鑰位置。本實作是針對位元組進行 XOR，而非 JavaScript UTF-16 程式碼單位，也非使用者感知字元群集。這一固定的定義正是讓混合語言結果在符合標準的瀏覽器之間可重現的原因。
空白的明文或空白的密鑰會直接遭到拒絕。輸入與密鑰資料上限為 100,000 位元組，以維持轉換、渲染與複製的反應速度，因此非常大的訊息較適合使用串流管道而非單一瀏覽器表單。明文中的空白字元會被保留，而編碼後密文中的空白字元會被剖析器去除，讓您能夠將長串的十六進位或 Base64 字串換行而不會破壞解密。
限制、弱點以及本計算工具無法做到的事
重複密鑰 XOR 是可逆的混淆機制，而非現代加密技術。本工具未提供認證標籤、檢查碼、鹽值、隨機數、密碼延伸或金鑰管理系統。短小或可預測的密鑰會透過頻率分析與已知明文攻擊暴露訊息；重複性會洩露較長密鑰所能隱藏的模式；任何能修改密文的攻擊者皆可在不被察覺的情況下變更加密後的輸出，因為該轉換沒有完整性檢查。請將本計算工具視為教學輔助、CTF 助手與互通性檢查工具——僅此而已。關於重複密鑰 XOR 作為安全原語為何失敗的更完整說明，請參閱 repeating-key reality check；對於任何敏感資料，請使用經審核的認證加密機制，例如搭配能妥善處理金鑰之受信應用程式的 AES-GCM。
若您想與朋友交換無害的謎題，請先約定完全一致的密鑰文字（包括大小寫與空格），加密訊息後發送其中一種表示方式，並請收件者選擇對應的選項、貼上密文、輸入相同的密鑰。若還原的文字無法閱讀，密鑰字元或傳輸編碼是最可能的原因——請先重新檢查兩者，再假設密碼本身有誤。XOR Encryption Online 計算工具專為教育、互通性與奪旗賽中的可逆混淆而設計；此定位為描述性質，而非安全性聲明。