chmod 計算機 API 的替代方案是一種瀏覽器內工具，可在不將數值傳送至遠端端點的情況下，於八進位與符號表示法之間轉換 Unix 權限位元。與其建構 HTTP 請求、傳遞 API 金鑰，並計算配額，您只需在表單中輸入完整的權限快照，網頁就會在您的分頁中回傳正規化八進位值、九個字元的符號字串，以及每個類別的讀取／寫入／執行對照表。Lizely 的 Chmod Calculator 正具備上述特性：它接受剛好三或四個 ASCII 八進位數字，例如 755 或 4755，或完整的九個字元符號值，例如 rwxr-xr-x 或 rwsr-xr-x，並呈現從八進位 0000 到 7777 所有 4,096 種可能模式。所有的剖析、驗證與位元運算皆在本機進行；該工具從不接收路徑、從不執行 chmod，也從不呼叫遠端 API。
純瀏覽器的 chmod 計算機實際取代了什麼
基於 API 的權限輔助工具通常會公開單一端點，接收模式字串並回傳 JSON 物件。此模式雖然可行，卻伴隨固定的成本：每次轉換都需進行一次網路往返、需要管理一把金鑰、存在身分驗證失敗模式，以及可能在除錯過程中耗盡的配額。瀏覽器端的替代方案透過在同一個託管表單的頁面中以 JavaScript 執行相同的位元運算，將往返次數縮減為零。對於可重複的開發者任務——翻譯您在 ls -l 中看到的模式、檢查 Dockerfile 中的 RUN chmod 行，或稽核部署清單——瀏覽器內的路徑更快速、具確定性，且可離線重現。
Chmod Calculator 在輸入邊界保持嚴格，以避免此捷徑成為錯誤來源。八進位輸入必須剛好包含 0 到 7 的三或四位數字，不得有 0o 前綴、符號、空白、分隔符、小數點、底線或 Unicode 相似字元。符號輸入必須剛好包含九個位置有效的字元：在擁有者、群組、其他人的順序下，為 r 或連字號、w 或連字號、x、s、S、t、T 或連字號。其他任何輸入都會遭到拒絕；舊有結果會被清除，使失敗的剖析不會在視覺上與過期的成功結果重疊。該合約對應 POSIX 對模式位元的定義，記載於 GNU chmod 手冊 中，其中描述了同樣的 12 位元配置，由三組權限三元組加上三個特殊位元組成。
嚴格剖析器強制執行的輸入規則
嚴謹正是 chmod 計算機值得信賴的原因。Chmod Calculator 將輸入視為不受信任的文字，並每次都套用相同的規則。諸如 755 的三位數八進位值明確表示沒有特殊位元；4、2 與 1 分別保留給 setuid、setgid 與 sticky，絕不會出現在一般權限位數內部。諸如 4755 的四位數值會將 4 置於擁有者位置之前，因此擁有者位元是第二位，而群組／其他人的位元分別是第三位與第四位。諸如 0755 的前置零會被接受，並代表與 755 相同的模式；當未設定任何特殊位元時，正規化輸出會省略多餘的前導零。
符號輸入同樣遵循此嚴謹度。九個字元，不得有來自長格式列表的前置檔案類型連字號（如同 -rwxr-xr-x 中的那個），亦不得有 chmod 修改運算式（例如 u+x 或 go-w）。這些形式編碼的是不同的操作，因此會遭到拒絕而非猜測處理。原始輸入同樣受到限制：計算機強制執行 32 個 UTF-16 碼元的預算，且不會靜默地截斷，因此確切的邊界會在下一個單位引發明確的預算錯誤前先行顯示。
| 能力 | 基於 API 的計算機 | Chmod Calculator（瀏覽器內） |
|---|---|---|
| 每次轉換的網路往返 | 每次呼叫皆需要 | 無——於當前分頁執行 |
| API 金鑰／帳號需求 | 通常為必要 | 無 |
| 速率限制暴露 | 是，依每次請求的配額而定 | 無——無遠端端點 |
| 八進位範圍涵蓋率 | 通常為精選子集 | 從 0000 到 7777 的全部 4,096 種模式 |
| 特殊位元處理（s、S、t、T） | 依實作而異 | 於每次往返皆保留大小寫 |
| 路徑或檔案洩漏 | 視紀錄方式而定 | 從未要求；從未傳送 |
使用 Chmod Calculator 於八進位與符號間轉換
- 選擇轉換方向。當您持有諸如 755 或 4755 的數值模式時，請選擇八進位轉符號；當您持有諸如 rwxr-xr-x 的九個字元字串時，請選擇符號轉八進位。切換方向會載入新路徑的範例，並清除任何舊有的結果、錯誤或複製狀態。
- 以要求的嚴格形式輸入剛好一組完整的權限快照。對於八進位，請輸入 0 到 7 的三個 ASCII 數字且不帶前綴；若設定特殊位元則輸入四位數字。對於符號，請依擁有者—群組—其他人順序輸入九個字元，可為 r、w、x、s、S、t、T 或連字號。新增前置連字號、空白、0o 前綴或諸如 u+x 的修改運算子將會產生驗證錯誤。
- 進行轉換並讀取三個結果區域。第一個顯示正規化八進位值——即省略多餘前導零但保留任何非零特殊位數的形式。第二個顯示九個字元的符號值，小寫或大寫的特殊字元會保留執行位元的狀態。第三個顯示擁有者、群組與其他人的對照表，其中每個儲存格標示為讀取、寫入、執行或搜尋，而任何 setuid、setgid 或 sticky 位元會依類別標示。
- 僅在交叉核對目標檔案、目前擁有權、特殊位元決策與最小權限需求後，再複製 chmod 範本。剪貼簿動作會寫入 chmod OCTAL FILE 範本；FILE 為佔位符，絕不會被解析、絕不會被存取，也絕不會被傳送至任何位置。若剪貼簿寫入失敗或遭拒，仍可手動選取可見的正規化八進位與符號值。
特殊位元：setuid、setgid 與 sticky 解析
特殊位元共用三個執行位置，並改變其意義而非位置。Setuid 對前導位數貢獻 4，setgid 貢獻 2，sticky 貢獻 1，因此 4755 帶有 setuid，6755 同時帶有 setuid 與 setgid，7755 則三項皆有——即使 7 這個數字本身在一般位置中看起來完全相同。計算機透過將非零的前導數字置於擁有者位置之前，並在同時設定 setuid 與擁有者執行時將執行儲存格呈現為 s，或在僅設定 setuid 但缺少擁有者執行時呈現為 S，來編碼此區別。Setgid 在群組儲存格中遵循相同的小寫或大寫規則；sticky 則在其他人執行存在時使用小寫 t，在其不存在時使用大寫 T。保留該大小寫正是實現真正往返的關鍵：將 rwsr-xr-x 經由八進位往返後必須回傳 4755，而非 7055。
單一的算術逐步說明可確認此配置。以 4755 為例：前導 4 宣告 setuid；擁有者位元 7 等於 4 + 2 + 1，代表讀取、寫入與執行；群組位元 5 等於 4 + 1，代表讀取與執行；其他人位元 5 等於 4 + 1，代表讀取與執行。由於擁有者執行位元開啟，setuid 呈現為小寫 s，產生 rwsr-xr-x。相同的擁有者／群組／其他人分解同樣出現在 Chmod Calculator 中，該頁面是執行端對端轉換的工具頁面。若要從不同角度檢視相同的模式位元宇宙，指南 Chmod Calculator Alternative That Covers Every Mode Bit 將逐步說明 4,096 種模式範圍邊界上的邊緣情況。
模式位元是請求，而非保證
即使是一次完美的轉換，也可能描述出檔案系統不會實際授予的權限。POSIX 定義了位元位置，但作業系統在其上疊加了額外的原則：擁有權決定誰能變更模式、訪問控制清單可覆寫個別位元、諸如 nosuid 的掛載旗標會忽略 setuid 與 setgid、唯讀檔案系統會拒絕所有寫入類別的操作，而應用程式沙箱無論模式為何皆可拒絕存取。處理程序亦需對每個上層目錄擁有遍歷權——若使用者無法進入某個目錄，則位於該目錄內部、模式為 700 的檔案仍會被拒絕存取。Umask 於檔案建立時套用，並非悄悄摺疊進模式的額外數字；它是一個獨立的遮罩，用以縮減所請求的權限，而計算機僅回報所請求的模式位元，並不會套用該遮罩。
特殊位元尤其值得留意。執行檔上的 setuid 與 setgid 會改變有效身分，且當擁有權或檔案系統原則錯誤時，許多系統會將其清除或忽略，因此計算機的輸出僅作為檢視輔助，而非權限的承諾。目錄上的 setgid 通常用於固定新子項目的群組，而目錄上的 sticky 則將刪除或重新命名權限限制為僅有擁有者可執行。請務必優先採用實際服務所需的最小權限，並避免使用諸如 777 此類過於寬鬆的範例來規避存取問題——應先診斷擁有權、群組成員、上層目錄遍歷、ACL、服務身分與掛載選項。該工具的角色在於正確翻譯位元；而工程師的責任則在於確保此翻譯在套用時是安全的。
相關閱讀：Cron Parser Alternative: Five Fields, No Library Required。