Rail Fence 密碼會將每個字元沿著一條 Z 字形圖樣移動到新位置,該圖樣會穿越 2 到 100 列,然後從上到下讀取每一列,產生一個包含原始字元(順序已打亂)的排列字串。「Rail Fence 密碼解碼器 API 替代方案」,簡單來說就是一個在您自己瀏覽器中執行相同 Z 字形轉換的工具,而不是將明文傳送到遠端端點;當您需要保留空格、標點符號、換行字元以及輔助 Unicode 碼位於其原始位置時,這一點至關重要。經典的三欄範例是將 WEAREDISCOVEREDFLEEATONCE 轉換為 WECRLTEERDSOEEFEAOCAIVDEN,而來回轉換回原始片語只能確認約定相符,絕不代表該訊息具有機密性。本機處理也能省去請求與回應的負擔、API 金鑰、速率限制,以及伺服器端解碼器留下的稽核紀錄,這就是為什麼單頁瀏覽器工具會成為解題、課堂作業,以及您不希望被記錄在第三方日誌中的一次性轉換的務實選擇。
停止呼叫 API 時會有什麼改變
大多數代管的 Rail Fence 解碼器端點會接收包含模式、欄數與輸入文字的 JSON 酬載,然後透過 HTTPS 回傳密文或明文。當訊息是簡短的 ASCII、網路穩定且營運商的日誌政策可被接受時,這樣的來回傳輸運作良好,但一旦輸入內容包含表情符號、含腔調字母、換行字元或帶引號的空白字元時,這種方式就力有未逮。REST 端點經常會在解析前將請求主體標準化為 UTF-8,這對大多數輸入無害,但對於計算碼位位置而非位元組數的換位密碼來說卻是災難性的。有些代管工具還會去除開頭與結尾的空白,或合併內部的連續空白,而每一項這種隱形的標準化都會在毫無可見警告的情況下,位移 Z 字形後續的位置。
本機的 Rail Fence 密碼解碼器 跳過了整個流程:每一步都在頁面內執行,每個字元都以 Unicode 碼位逐一迭代,Z 字形圖樣會依據該精確序列計算,輸出結果則保留您貼上的所有內容。沒有字元被刪除、沒有隱含的填補,也不存在隱藏的約定變更,因為沒有第二台機器介入。同樣的邏輯也適用於本機執行的 ASCII 碼轉換器 API 替代方案:將位元組保留在您自己的機器上、讓來源保持可見,如此一來您就可以透過閱讀實作內容來稽核轉換,而不是去信任一個不透明的伺服器回應。
如何在 Rail Fence Cipher Decoder 中於本機進行加密或解密
- 從模式選擇器中選擇加密或解密,然後輸入介於 2 到 100 之間的整數欄數。三是課堂上的典型數值,而較高的欄數會產生較長的週期,其週期長度為兩倍欄數減一。
- 將確切的文字貼入輸入欄位,保留每個空格、標點符號與換行字元於原處,讓它們都參與 Z 字形。若悄悄將它們移除,後續每個位置都會跟著位移。
- 執行轉換,並從輸出區塊複製結果。頁面會在結果中保留可見的格式,因此空白與換行字元會原封不動地透過複製動作保留下來。
- 若要還原,請切換至解密模式,並對未經修改的密文使用相同的欄數。請將一次成功的來回轉換視為約定相符的確認,而不是安全性的證據。
導致錯誤答案的約定差異
Rail Fence 有多種變體,而這正是不同網站的解碼器輸出彼此不一致的最大原因。有些實作會在第一次向下移動前加上初始位移,有些則會反轉方向使第一次向上移動,還有些會從最底欄而非最頂欄開始。有些會在排列前去除空格,這會悄悄改變任何包含空格的片語之輸出。Rail Fence Cipher Decoder 不使用位移、從最頂列開始、先向下移動,且精確保留每個碼位,因此約定的問題由實作決定,而非從上下文推測。三欄的列圖樣為 0, 1, 2, 1,並以週期長度 2(r−1) 重複,這符合歷史上的三欄描述,但並非符合每道選擇不同起始列的課堂練習。把這四項約定釐清,也是我們另外保留一份 關於比對 Rail Fence 約定的操作指南 的原因;在將輸出與其他工具(例如 dCode Rail Fence 頁面)進行比較之前先確認這些約定,就能避免浪費數小時在錯誤答案的除錯上。
下表總結了所支援的變體與常見替代方案之間的差異;若不同工具產生不同的密文,通常可以在本表中找到解釋該差異的那一列。
| 變體 | 位移 | 第一次移動 | 起始列 | 去除空格 |
|---|---|---|---|---|
| Rail Fence Cipher Decoder(預設) | 0 | 向下 | 頂部 | 否 |
| 位移變體 | 非零 | 向下 | 頂部 | 有時 |
| 由下往上變體 | 0 | 向上 | 底部 | 有時 |
| 去除空格變體 | 0 | 向下 | 頂部 | 是 |
來回驗證、限制與確定性
此頁面公開了八組黃金測試案例,用來斷言標準的三欄範例、相同訊息在兩到四欄下的情形、一個全字母片語、一個純數字字串、一個含空格與標點符號的片語,以及一個輔助 Unicode 字串。每個測試案例都會先斷言為預期密文,然後解密回精確的原始內容;這兩道檢查證明了在涵蓋支援範圍的輸入下,實作具有確定性且可逆。相同的輸入與欄數永遠會產生相同的輸出,而這個特性正是讓一段密文能與另一位同學共享,且無需協商金鑰就能放心採用解答的原因。由於轉換具有確定性,同一段明文編碼兩次會得到相同的密文,這也意味著當其他條件不變時,欄數錯誤是唯一合理的錯誤來源。
規範這些測試案例的官方限制與常數整理如下。
| 限制或常數 | 值 |
|---|---|
| 最少欄數 | 2 |
| 最多欄數 | 100 |
| 最大輸入長度 | 200,000 個碼位 |
| r 欄的週期長度 | 2(r−1) |
| 三欄列圖樣 | 0, 1, 2, 1 |
| 表情符號處理 | 以完整碼位逐一迭代,絕不拆解為 UTF-16 代理對的半部 |
若欄數等於或超過字元數,則每個使用到的位置皆位於各自獨立的初始下降路徑上,輸出將維持不變;當您不確定所輸入的欄數是否適合訊息長度時,這是一項實用的健全性檢查。輸入上限為 200,000 個碼位,以確保在消費級硬體上建構各列時仍能保持回應速度;頁面也會持續驗證欄數為介於 2 到 100 的整數,而不是將無效的輸入默默預設為三。無效的欄數與空白輸入會被視為不同的失敗模式,如此一來,就能一眼區分是打錯字還是漏貼內容。換行字元會以字元身分參與,因此會改變 Z 字形中後續的每個位置;所以即使其他所有約定都相符,一個把換行字元合併成空格的複製貼上動作也無法成功來回轉換。加密時會為每一欄建立一個有序的儲存區,並依據每個碼位在 Z 字形中所屬的列依序附加;解密時則先計算每欄包含多少位置,依據這些數量切割密文,然後在每個原始位置上從對應的列取用一個字元。過程中不會猜測填補,解密也絕不會猜測欄數,因此嘗試不同欄數仍然是一項刻意的密碼分析任務,而不是一個隱藏功能。
安全性的現實檢驗
Rail Fence 是歷史悠久的教學用密碼,而非現代加密技術。它除了欄數這個小秘密之外沒有其他秘密,保留了每個字元的頻率,並且對任何合理的欄數值都能輕易地暴力破解。這八組黃金測試案例只能證明實作是正確的;它們與機密性、完整性或真實性毫無關係。若要保護真正的秘密,請使用經驗證的加密演算法:AES-GCM、ChaCha20-Poly1305,或任何經過審閱、搭配唯一 nonce 的認證加密架構,皆適用於憑證、個人資料、權杖、檔案與機密通訊。請將 Rail Fence 視為認識換位密碼的有趣方式,並把相關工具保留給解題、CTF 暖身題以及課堂作業使用,在這些情境下,欄數本身才是謎題,而不是訊息本身。