XOR 加密線上工具是一種以瀏覽器為基礎的對稱位元組轉換,它會將每個 UTF-8 明文位元組與重複 UTF-8 金鑰中對應的位元組,透過互斥或 (exclusive-or) 運算子結合,然後將產生的密文以十六進位或 Base64 格式呈現,以便檢視與傳輸。由於 XOR 是自身的反運算,當兩端的位元組慣例一致時,將同一把金鑰套用於密文,即可精準還原原始明文。一個線上 XOR 加密工具的決定性特質有四:它處理的是原始 UTF-8 位元組,而非 JavaScript UTF-16 單位;當訊息長度超過金鑰時,它會從頭重複金鑰;它接受明文或密文作為文字輸入,並以兩種顯示格式輸出相同的密文位元組;它絕不會將輸入、金鑰或輸出上傳到遠端伺服器。這四條規則讓兩個人只需要約定一把金鑰字串與一種表示法,即可交換可還原的訊息。XOR Encryption Online 這個頁面正是使用 TextEncoder 進行位元組轉換,並採用 JavaScript 語言規範中定義的位元 XOR 運算子,在您的瀏覽器中精準實作此合約。
XOR 線上加密在位元組層級如何運作
在底層,任何遵循現代慣例的線上 XOR 加密頁面都會依序執行三個步驟。首先,明文字串會透過 TextEncoder 介面編碼為一串 UTF-8 位元組。一個 ASCII 字元會變成單一位元組,但表情符號、帶有變音符的拉丁字母,或非拉丁字母,可能會變成每個可見字元佔用兩個、三個或四個位元組。接著,金鑰字串也以相同的 TextEncoder 呼叫進行編碼,產生相同型態的金鑰位元組序列。然後,位置 i 的明文位元組會與位置 i mod keyLength 的金鑰位元組,透過 位元 XOR 運算子結合;當 i 達到金鑰長度時,金鑰索引會重置為零,並開始新一輪循環。這個運算的輸出就是密文位元組流。十六進位與 Base64 只是表示同樣位元組的兩種方式,切換顯示格式永遠不會改變底層的 XOR 結果。由於 XOR 是自身的反運算,使用同一把金鑰對密文執行相同的運算,即可還原明文位元組,最後再透過 UTF-8 解碼將其轉回字串。
這個固定流程最重要的意義在於可重現性。兩位使用者若約定明文與金鑰皆使用 UTF-8 編碼、採位元組層級的 XOR 搭配金鑰重複,並選定輸出格式,他們將會看到相同的密文位元組與相同的還原結果。任何偏離慣例的人——把金鑰視為十六進位、以 UTF-16 編碼單位運作、略過非 ASCII 位元組——即使可見字元相同,產生的位元組流也會不同。在 XOR 線上加密中,合規性就是一切,而工具頁面上的約定刻意寫得明確,以讓兩個瀏覽器預設就能達成共識。
使用 XOR 線上加密來加密訊息
- 開啟 XOR Encryption Online,確認模式已設定為加密。
- 在訊息欄位中輸入或貼上您的明文。此工具會將空白字元視為有意義的字符,並將結果編碼為 UTF-8 位元組,因此前導空格會成為真實的密文位元組。
- 將重複金鑰原樣輸入到金鑰欄位中。金鑰會被讀取為 UTF-8 文字,而非十六進位,因此 "key" 這個字會變成三個位元組 6B 65 79。
- 執行本地轉換。瀏覽器會將每個明文位元組與對應的金鑰位元組進行 XOR,然後在同一個面板中,將產生的密文以小寫十六進位與標準填充式 Base64 兩種方式顯示。
- 複製接收方預期的表示法,並清楚告知對方您選用的是哪一種格式,讓他們能在自己那一端選擇相符的選項。
加密模式刻意設計成確定性的:相同的明文搭配相同的金鑰,必定產生相同的密文,這正是無需額外詮釋資料就能還原的原因。為了在分頁中保持轉換的回應速度,超過 100,000 位元組的輸入會被拒絕;空白的明文或空白的金鑰也會直接被拒絕,讓結果永遠不會模稜兩可。
選擇接收方接收密文的方式
| 格式 | 呈現方式 | 典型長度 | 最佳用途 |
|---|---|---|---|
| 小寫十六進位 | 每個位元組以兩個十六進位數字表示,例如 1f 4a 9c … | 字元數約為位元組數的兩倍 | 除錯、封包檢查、低階通訊協定 |
| 標準填充式 Base64 | 由 A–Z、a–z、0–9、+、/ 組成,並以 = 填充 | 約為位元組數的 1.33 倍 | 貼到聊天訊息、電子郵件內文、JSON 酬載中 |
兩列中的位元組完全相同——只有書寫系統不同。當接收端系統預期位元組配對、當您想以肉眼檢查個別位元組,或當您正在除錯此轉換時,請選擇十六進位。當訊息必須穿越會去除或摺疊空白的純文字欄位時,請選擇 Base64。請明確告知接收方您使用的是哪一種表示法;將 Base64 字串貼進十六進位解析器會因為多出的字元而失敗,將十六進位貼進 Base64 解析器則會因為長度與字集不符而失敗。此工具會在加密面板上同時顯示兩種形式,讓您無需重新計算,即可複製最方便的那一種。
解密收到的 XOR 訊息
- 將工具切換到解密模式,並選擇與傳送端相符的格式——十六進位或 Base64。
- 將密文貼到輸入欄位。兩種格式都會忽略空白字元,因此換行的十六進位或斷行的 Base64 都可直接接受,無需清理。
- 輸入完全相同的金鑰文字,包括每一個空格、大寫字母與標點符號。只要有一個字元組不符,從該金鑰位置之後還原出來的每個位元組都會改變。
- 執行解密操作。此工具會嚴格解析所選的表示法,將產生的位元組與 UTF-8 金鑰進行 XOR,然後對還原後的位元組序列執行嚴格的 UTF-8 解碼。
- 透過獨立管道確認結果文字——例如請傳送者驗證一個已知片語——因為成功的 UTF-8 解碼本身並不足以證明金鑰正確。
十六進位模式會拒絕任何含有奇數個十六進位數字或非十六進位字元的輸入;Base64 模式會拒絕使用錯誤字集或填充不正確的輸入。這兩個嚴格的解析器會將傳輸過程中的損壞轉為明確的錯誤,而不是悄悄產生錯誤的資料——這正是以明確格式慣例來進行 XOR 線上加密,相比於鬆散的複製貼上工作流程,所帶來的實際優勢。使用錯誤的金鑰通常會產生無效的 UTF-8,進而顯示可見的錯誤,而不是悄悄出現替換字元;不過,有些隨機的位元組序列仍然恰好會形成有效的字元,特別是在簡短的 ASCII 訊息中——這正是為什麼步驟五是個實實在在的步驟,而非只是走個形式。
破壞 XOR 線上加密的慣例陷阱
大多數「怎麼沒用」的回報都源自慣例不符,而不是程式錯誤。四個陷阱就幾乎涵蓋了所有失敗的情況。
金鑰被視為文字或十六進位。本頁面將金鑰欄位讀取為 UTF-8 文字。因此,可見字串 "6B6579" 會變成六個 UTF-8 文字位元組,而不是三個十六進位位元組 (6B、65、79)。若某個工具將金鑰讀取為十六進位,則會將這些字元配對為三個位元組,產生不同的密文。當您與命令列工具或程式設計函式庫比對結果時,請檢查參考實作是將金鑰視為字元字串,還是十六進位位元組;唯有位元組數相符,輸出才會一致。
明文中的空白字元。原始訊息中的每個空格與換行都會變成 UTF-8 位元組,並正常進行 XOR。在不留意的情況下修剪空白,會悄悄改變密文,因此請務必貼上完整的訊息與金鑰,不要做任何編輯性的清理。編碼後密文內部的空白會被忽略以方便換行,但明文本身會逐字處理。
Unicode 多位元組字元。單一表情符號可能會佔用四個金鑰位置。當您在同一訊息中混合使用多種文字時,兩個可見字元可能各自使用不同數量的金鑰位元組,這使得字元的可見「位置」相較於位元組位置而言變得毫無意義。這是刻意的設計——XOR 線上加密是在位元組層級運作,而非在字素叢集或 JavaScript UTF-16 編碼單位上運作——但這也說明了為什麼短而簡單的金鑰在處理 Unicode 文字時,感覺上比處理純 ASCII 時更脆弱。
空白輸入。空白的明文或空白的金鑰會直接被拒絕,因為轉換作業無事可做,且結果會模稜兩可。如果您的訊息看起來沒有產出任何結果,請檢查是否有不可見字元,而不是重試一次。
XOR 線上加密的適用時機與停止時機
XOR 線上加密適用於可逆的混淆任務,目的是讓內容變得無法輕易讀懂,而不是防範有心人士。常見用途包括搶旗賽 (CTF) 謎題、講解對稱加密的結構、檢驗兩個系統是否以相同方式編碼相同的位元組,以及在金鑰透過獨立管道傳送的前提下交換無害的訊息。此工具完全在瀏覽器中執行,絕不會上傳訊息、金鑰或輸出,並且每次都會重現相同的密文,使其適合作為確定性的暫存區。
一旦機密性或完整性變得重要,它就不再是合適的工具。重複金鑰的 XOR 會暴露規律;已知明文會洩漏金鑰位元組;短金鑰容易被還原;而且密文沒有校驗碼、驗證標籤、鹽值、隨機數或金鑰管理機制——因此攻擊者可以翻轉位元,而錯誤的金鑰只會產生錯誤的文字。如需深入了解這些特性為何重要,請參閱重複金鑰的現實檢驗指南。對於密碼、付款明細、個人紀錄,或任何必須偵測竄改的資料,請改用具備驗證功能的審查過的加密法,例如JSON 封包形式的 AES-256-GCM,它會一併處理驗證、金鑰處理與封裝作業。
當您的目的是學習、教學,或是在已共享金鑰的兩人之間交換可逆的謎題時,請使用 XOR 線上加密。一旦當目的是保護任何他人可能會想要讀取或竄改的資料時,請改用具備驗證功能的真正加密法。