Hill Cipher Decoder 將大型 A-Z 文字完全在瀏覽器中處理，方式為將每個字母對應到 A=0 到 Z=25、形成兩個字母的欄向量、乘以 2×2 鍵矩陣，並將兩個乘積都取模 26，同時有明確記載的 100,000 字母輸入上限，以保持矩陣運算的回應速度。需要鍵矩陣的模反矩陣才能解密，因此工具在接受可逆矩陣之前會先檢查行列式，並拒絕行列式與 26 有共同因子的鍵。長篇文章會暴露每一個慣例選擇 — 字母編號、向量方向、區塊大小、填充規則 — 而在這條鏈上的任何位置不相符，就會從相同的可見數字產生不同的密文。瀏覽器在形成區塊之前會去除空格、數字和標點，僅在標準化後的明文字數為奇數時附加一個尾端 X，並且保留解密後尾端的 X，因為自動移除它可能會破壞一個真正的訊息字元。這些規則讓同一個計算工具能從四個字母的教學範例擴展到 100,000 字母的練習，而無須變更已記載的數學運算，這正是一個 Hill Cipher Decoder 頁面所打造的用途。
當你將 Hill cipher 擴展超過一個句子時會發生什麼變化
一個四個字母的 HELP 練習會隱藏問題，而 400 個字母的文章會立刻浮現問題。輸入較短時，錯誤的 A=1 對應看起來與正確的一模一樣，直到有人去數字母順序。向量方向顛倒會從相同的可見數字改變密文，而非保留大部分，因為使用預設鍵 3 3; 2 5 與明文 HELP 時，欄向量加密會得到 HIAT，而列向量加密會得到 DPLE，因此全部四個輸出位置都不同。填充的歧義只有在真實訊息合理地可能以填充字母結尾時才有意義；在 HELP 中不太可能，在散文中很常見，而且幾乎一定會讓只記錄密文的批改者感到困惑。已知明文攻擊（攻擊者從幾對相符的明文-密文對中還原出鍵）在數百個字元下變得幾乎免費，因為每個雙字母對會對四個鍵未知數貢獻兩個線性方程式。計算工具將鍵直接暴露在其輸入欄位中，因此若將此頁面視為黑盒來處理長篇私人訊息並不安全；將它視為教科書題目的已驗證數學參考，才是正確的用法。長篇文章也會讓瀏覽器的運算顯而易見：100,000 字母輸入上限存在的原因，是因為在已標準化字串上的矩陣乘法必須在消費型硬體上保持回應速度，而非因為數學本身在超過該點後會失效。
長篇文章的標準化規則
在任何區塊形成之前，解碼器會先去除空格、標點、數字以及任何 A-Z 之外的字元來標準化輸入，然後將剩餘內容強制轉為大寫。此步驟是不可逆的，這正是為何已記載的行為是：如果練習最後需要還原為完整單字，請在另一張紙上記錄原始的間距與格式。字母對應為 A=0、B=1，依此類推到 Z=25；鍵中的負值與大於 25 的項目會被標準化到相同的範圍。標準化後，存留的字元會被分組成雙字母區塊。如果原始明文的長度為奇數，加密步驟會插入恰好一個尾端 X，而要知道那個最後的 X 是後來加上的還是原本就在，唯一的方法是在加密前先記錄原始長度。因此明文長度可能為奇數，而密文則不行。解密後的密文依建構為偶數長度，因為每個區塊包含兩個值，所以計算工具不會在解密後自動修剪尾端的 X。矩陣慣例在頁面中固定為 C = K × P，其中 P 寫成欄向量，而已記載的預設鍵 3 3; 2 5 在該慣例下會將 HELP 變成 HIAT。
使用 Hill Cipher Decoder 解碼大型文字
- 確認練習採用 A=0 到 Z=25、雙字母欄向量以及 X 填充。如果你的資料來源使用 A=1、列向量、不同的區塊大小或不同的填充字母，即使矩陣數學完全相同，相同的可見數字也會產生不同的密文。請在現代瀏覽器中開啟 Hill Cipher Decoder，讓所有運算保持在本地端。
- 以 a b; c d 的形式輸入兩個矩陣列，列與列之間以分號隔開，使用整數。頁面會將負值與過大的項目標準化到 0..25，但若行列式與 26 有共同因子則會拒絕，因為在該情況下不存在唯一的模反矩陣。預設鍵 3 3; 2 5 已在記載中說明會在此慣例下將 HELP 加密為 HIAT，而那組公開的配對就是最後步驟中的驗證錨點。
- 選擇方向 — 加密或解密 — 並將 A-Z 訊息或密文貼入文字欄位。瀏覽器會移除空格、數字和標點，將存留字母分成雙字母對，將每對乘以鍵矩陣，並將兩個乘積都取模 26。解密時，只有在 gcd(det, 26) = 1 時才會計算鍵的模反矩陣。
- 執行轉換，並在依賴較長的輸出之前，先比對一個已知配對，例如 HELP 對 HIAT。如果該公開配對相符，請貼上完整長篇文章；如果不相符，幾乎一定是慣例不相符，矩陣數學本身是正確的。超過 100,000 標準化字母的文章會被拒絕，以保持頁面回應速度 — 請在句子邊界而非區塊中間切分輸入。
在提交前驗證長篇 Hill cipher 輸出
長篇輸入在提交前值得做一個簡短健全性檢查。最快的檢查是來自操作步驟的已知配對測試：使用預設鍵 3 3; 2 5 加密 HELP 並確認結果是 HIAT，然後解密 HIAT 並確認來回往返能還原為 HELP。如果可行，請對長篇文章中間的一段 50 字元片段執行相同方向，並確認解密後是可辨識的單字；中間若有單一不相符的區塊，通常代表在標準化過程中漏掉了某個輸入的數字或多餘標點，而不是矩陣運算錯誤。請在加密前先記錄原始明文長度，這樣解密後結尾的 X 才能被歸類為填充或真正的訊息字元 — 工具本身無法區分這兩者。請將標準化 A-Z 輸出與對方的參考結果比對，而非與原始格式化文字比對，因為計算工具刻意會去除所有呈現用字元且只輸出大寫。
限制、被拒絕的輸入以及慣例不相符
長篇文章自然會超出四個已記載的拒絕點，以及數個看似計算工具錯誤但其實不是的常見慣例不相符。介面會拒絕行列式與 26 有共同因子的鍵，因為在此情況下會有多組明文對映到同一密文，解密便無法唯一。它也會拒絕奇數個密文字母，因為每個區塊恰好包含兩個值。空的標準化輸入會直接被拒絕。超過 100,000 字母上限的訊息會被拒絕，以在消費型硬體上保持頁面回應速度，即便底層數學仍可計算。三種慣例不相符經常出現在學生作業中，值得依下列順序檢查：某些參考資料將字母向量放在列而非欄、有些以不同順序排列鍵值、有些從 A=1 而非 A=0 開始編號。頁面明確記載其自身慣例，因此可以快速定位不相符之處，而相同的可見數字在不同慣例下會產生不同的密文 — 這就是長篇答案無法對上教科書答案最常見的原因。如果你很長的輸入實際上是許多獨立短訊息的清單而非單一篇文章，計算工具會各自獨立處理；針對涵蓋該情境的工作流程，請參考 Hill Cipher Decoder Bulk: 一次處理多行 指南。
| 已記載的行為 | 本頁面上的值 |
|---|---|
| 字母對應 | A=0, B=1, ..., Z=25 |
| 向量方向 | 雙字母欄向量 |
| 鍵輸入格式 | a b; c d，使用整數 |
| 預設鍵 | 3 3; 2 5 (HELP → HIAT) |
| 填充規則 | 僅在奇數長度明文加上單一尾端 X |
| 負值或 >25 的鍵項目 | 標準化到 0..25 |
| 解密要求 | gcd(det, 26) = 1，否則拒絕 |
| 輸出字母 | 僅大寫 A-Z，無空格 |
| 輸入上限 | 100,000 個標準化字母 |
| 處理位置 | 本地瀏覽器，無上傳 |
當 Hill cipher 是錯誤的選擇時
長篇訊息值得使用比 1929 教學演算法更好的方法。此加密法將線性代數應用於雙字母區塊，歷史上固然重要，但在密碼學上已經過時：已知明文會在數秒內揭露線性關係，字母集與區塊大小都很小，而且本頁面會將鍵直接暴露在其輸入欄位中。生產環境的秘密 — 密碼、權杖、個人資料、檔案 — 無論密鑰看起來多長，都應使用經過審查的認證加密機制，例如 AES-GCM，而非 Hill cipher。此工具的存在目的是為了教科書練習、課堂控制使用情境，以及驗證已公開的慣例，而瀏覽器在本地端執行所有運算，因此非常適合這些任務。
若想深入了解，請參考 ROT13 Decoder Online Free, No Sign Up or Install。