開發者工具
那個貼上框，不該變成別人伺服器上的一行 log。
1 個工具
這個分類裡的工具
這個分類放的是你在除別的錯的過程中會順手拿來用的小工具：這個字串裡到底有什麼、這段實際上是幾個位元組、為什麼這兩個值比起來不相等。它們都跑在你的瀏覽器裡 —— 對這一類工具來說，那不是行銷賣點，而是工作前提。
為什麼「開發者工具」特別不該上傳
想一下事故處理的當下，實際上會被貼進線上開發者小工具的是什麼：正式環境的 log、帶著真實 subject 的 JWT、客戶資料表的一列、一個簽名網址、一個正在出問題的系統吐出來的檔名、含內部識別碼的 API 回應。這些東西沒有一個是打算離開公司的，而它們天天在離開 —— 因為面對一個貼上框，那個「應該小心」的反射動作不會啟動。
解法是架構，而不是承諾。這個分類裡的一切都由你已經開著的這個分頁裡的 JavaScript 計算。本站送出的 Content-Security-Policy 把網路連線限制在自己的來源，而執行這條限制的是你的瀏覽器，不論我們的程式想做什麼。你可以在大約二十秒內驗證：打開 Network 分頁然後貼上，或者乾脆把網路斷掉再重新整理 —— 工具照樣能用，因為它們從來不需要伺服器。
現在這裡有什麼
Unicode 字元檢視會把任何文字一個碼位一個碼位拆開：U+ 值、精確的 UTF-8 位元組序列、UTF-16 單位、類別與書寫系統、東亞寬度，以及這個字元是不是那些「畫出來什麼都沒有」的其中之一。它同時報出 NFC 與 NFKC 正規化後的碼位數 —— 那是判斷「兩個看起來一模一樣的字串到底是不是同一份資料」最快的方法。
它針對的是一類特定的 bug：字串看起來一樣但比對失敗、去重之後還有重複、長度檢查過了但資料庫寫入被拒、從 Mac 來的檔名跟 Windows 上同名的檔案比不對。這些幾乎都是隱形字元、代理對，或者同一個詞的兩種正規化形式 —— 三者在逐字表裡都是一眼就看得到。
位元組、編碼單位、字元是三種不同的上限
文字處理最常見的混亂來源，就是這三個詞在口語上被混用，而在實作上完全不能互換。以「字元」宣告的 VARCHAR 通常算 UTF-16 編碼單位；以「位元組」宣告的算 UTF-8 位元組，而一個中日韓字元是 3 個、罕用擴充區是 4 個。maxlength 算編碼單位。QR Code 的容量是位元組預算。HTTP 標頭上限是位元組。翻譯報價是不含空白的字元數。
所以「這個欄位可以填 20 個字」不是一個規格，至少是三個 —— 而到底是哪一個，決定了一個中文姓名放不放得進去。這裡的工具會把它們並排列出來，而不是挑一個然後希望剛好是你要的那個。
接下來會做什麼，以及不會做什麼
JSON、XML、YAML 的格式化與驗證，Base64、URL、HTML 實體的編碼與解碼，雜湊與 UUID 產生器，正規表示式測試器，以及 cron 運算式的白話解釋，都排在這個分類裡。每一個都會用同樣的方式加進來：本機運算、誠實說明這個方法做不到什麼，以及不引入任何「授權對一個有廣告的網站會有問題」的依賴。
我們不會做的是：加一個必須把你的輸入送到伺服器的工具，然後把它描述成隱私友善；也不會為了給你一個可分享的連結，就默默把你打的東西存起來。真的沒辦法在本機完成的（也就是必須代替你向網際網路發出請求的），會掛上「需連線查詢」徽章，並且明白寫出這次到底送出了什麼。
常見問題
我貼進這些工具的東西會被儲存或傳出去嗎？
不會。運算在你的瀏覽器分頁裡完成，沒有任何請求夾帶你的輸入，而本站的 Content-Security-Policy 也會擋掉連往其他來源的連線。這些頁面在斷網的情況下照樣能用。
可以離線使用嗎？
第一次造訪之後可以。頁面與程式會被 Service Worker 快取，而這些工具本來就不需要網路連線。
為什麼 Unicode 檢視不顯示官方字元名稱？
完整的 Unicode 名稱表對這種規模的頁面來說是一個很大的下載檔。我們顯示類別、書寫系統、區段，以及真正會造成 bug 的那些屬性，並且欄位標題照實寫，不會讓你以為那是官方名稱。
一個中文字佔幾個位元組？
常用區在 UTF-8 是 3 個，增補平面是 4 個。這就是為什麼以位元組為上限的欄位，實際裝得下的中文比數字看起來少很多。
有 API 嗎？
目前沒有。這裡的一切在設計上都是客戶端執行，所以沒有一個「在做事的伺服器」可以讓 API 去呼叫。將來若有，會是給真正需要伺服器的工具，並且會明白標示。