為什麼是一個工具箱，而不是十二個頁面
「編碼」是個早就被解決的問題，搜尋結果也反映了這一點：每一種編碼各有一個頁面，每個頁面就是一個輸入框，給你一個答案。它們沒給你的，正是真正吃掉時間的那件事——把它套用到四十列資料上，然後向同事（或 CI）交代這個字串究竟是怎麼產生的。
所以這個頁面刻意做成一項批次工作的樣子，而不是單一轉換器：
- 一行一列，一行一個錯誤。 從試算表或日誌裡貼上一整欄，每一行都獨立轉換。某一行不是有效的 Base64，它會拿到自己的錯誤訊息，也不會讓其他三十九行停下來——而且總數會先講在前面，而不是把失敗藏在最下面。
- 答案旁邊就附上命令列。 每一次轉換都會顯示它的 shell 對應指令（`base64`、`xxd -p`、`node -e …`），而且輸入值已經幫你加好引號。那正是泛用編碼器頁面會省略的部分，也正是同一套轉換得在管線裡執行時你需要的那部分。
- 嚴格解碼，不偷偷修補。 如果位元組不是有效的 UTF-8，工具會直接說出來，而不是印出一堆取代字元就當作成功。hex 出現奇數個位數、URL 裡有落單的「%」、或是不認識的 HTML 實體，也都一樣。
- 那些瑣碎的轉換也在這裡。 binary 要不要空格、hex 要不要 0x 前綴與空格、HTML 實體雙向轉換、\uXXXX 跳脫序列（含 emoji 用的代理對）、ROT13／Caesar，以及命名風格家族（camelCase、PascalCase、snake_case、kebab-case、CONSTANT_CASE、dot.case）——從任何輸入寫法都能推導出來。
全部都在你的分頁裡執行：不上傳任何東西、沒有分享連結，你貼上的任何值都不會送到伺服器——這對大家真正想在這裡解碼的字串（token、cookie、payload 片段）來說很重要。兩個誠實的限制：「解碼」指的是還原編碼，而不是解密任何東西；而這個頁面刻意不做位元組層級的工作——雜湊、HMAC、AES-GCM 與 TOTP 都在搭配的密碼學工具箱裡，因為它們需要 Web Crypto，而且是非同步的。