駝峰式命名轉蛇形命名的轉換，是依據一組固定的 token 清單，將一個識別符號對應到另一種命名樣式，屬於確定性的對應;而一張速查表會把斷詞規則、縮寫行為以及六種輸出格式全部收錄，讓你預測每一個結果。Camel Case to Snake Case Converter 完全遵循這些規則:貼上一個識別符號或短詞，從小寫到大寫的轉折處切開、把連續大寫序列跟其後的大寫開頭單字分開、把非字母與非數字的連續字元當成分界、把每個 token 統一為小寫，再組裝出 snake、kebab、camel、Pascal、constant 與 title 等輸出。每種輸出會同時顯示，各自帶有複製控制項，讓你不用重新執行工具就能比較各種格式。同樣的邏輯會從 XMLHttpRequest 產生出 snake_case，也會產生出 xml_http_request，因為縮寫仍然維持成組 —— 斷詞器偏好更聰明的分界規則，而不是簡單地在每個大寫字母前插入底線。本速查表彙整了這些規則、限制，以及複製結果後你在專案端仍須執行的步驟。
Token 邊界如何劃定
斷詞是任何命名轉換工具最容易出錯的環節，因此速查表從這裡開始。Camel Case to Snake Case Converter 依序套用三條規則，每一種輸出樣式的每個邊界，都是由這三條規則決定。
小寫到大寫的邊界。 一個小寫字母或數字，後面接著一個大寫字母，就會切開。userName 會切為「user」與「Name」;version2Beta 會切為「version2」與「Beta」，因為小寫的「n」緊鄰著大寫的「B」。在一般的 camelCase 與 PascalCase 輸入中，大部分切分都來自這條規則。
縮寫到單字的邊界。 一段連續的大寫字母，後面接著一個同樣以大寫字母開頭的單字時，會在縮寫與單字之間切開。XMLHttpRequest 因此會切為「XML」、「Http」、「Request」，而不是切到逐個字母。若沒有這條規則，結果會變成 x_m_l_http_request，完全失去縮寫的語意。同樣的規則也讓 HTTPSConnection 維持為 https_connection，而不是 h_t_t_p_s_connection。
分隔字元邊界。 任何既不是字母也不是數字的連續字元都視為切點，且連續的分隔字元會合併，而不是產生空 token。空格、連字號、句點、斜線、加號、直立線以及其他標點符號都屬於此類。像 get-URL-by-id 這種以連字號分隔的輸入，因此會斷詞成「get」、「URL」、「by」、「id」，而連字號本身會成為所選樣式所預期的連接符號。
斷詞器保留 Unicode 字母與數字，但在大小寫轉換時套用明確的英文地區設定，讓相同的輸入在每個瀏覽器上無論系統語言為何，都能產生相同的輸出。數字會在邊界允許的情況下留在所屬詞內，userProfile2FA 結尾的「2」會保留在該單字中，而非作為新 token 的開頭。空白會被合併。最終輸出是一份穩定的 token 清單，供六種樣式共用，這也是為什麼同一份貼上內容能同時產生 snake、kebab、camel、Pascal、constant 與 title 等輸出。
六種輸出樣式一覽
這六種樣式涵蓋了原始碼、設定檔、URL 與顯示文字中最常用的命名形式。沒有一種是普遍正確的 —— 該用哪種取決於專案政策。
| 樣式 | 連接符 | 大小寫規則 | 常見用途 |
|---|---|---|---|
| snake_case | 底線 | 所有 token 全小寫 | Python 變數、SQL 欄位、檔名 |
| kebab-case | 連字號 | 所有 token 全小寫 | URL slug、CSS class 名稱、CLI 旗標 |
| camelCase | 無 | 第一個 token 小寫，其餘首字大寫 | JavaScript 變數、部分 API 的 JSON 鍵 |
| PascalCase | 無 | 每個 token 首字大寫 | C# 類別、React 元件、TypeScript 型別 |
| CONSTANT_CASE | 底線 | 所有 token 全大寫 | 環境變數、C 語言巨集 |
| Title Case | 空格 | 每個 token 首字大寫 | 顯示標籤、文件標題 |
Camel Case to Snake Case Converter 同時會一次顯示所有樣式，各自帶有複製控制項，讓你可以從同一份貼上內容，複製 snake_case 給 Python 模組、複製 kebab-case 給 CSS class，以及複製 PascalCase 給 TypeScript 介面。語言、框架、資料庫與團隊各自對於開頭是否可用數字、保留字、最大長度、可接受字元等都有不同限制，任何轉換器都無法預先得知，因此這六種輸出只是常見形式，並非強制規定。此轉換器不會轉寫其他文字系統、不會將單詞單複數化、不會拼字檢查、不會保留標點，也不會推測語意縮寫，因此 user ID 會變成 userId，而不是你團隊可能偏好的專案特定寫法 userID。請在任何重新命名動作之前，先把這些縮寫決策白紙黑字寫下來。
四個步驟轉換任何識別符號
速查表版本的工作流程可以歸納為四個可重複執行的步驟。每一步都有明確的產出，讓你在往下進行前先加以驗證。
- 把一個識別符號或短詞貼到輸入欄位。camelCase、PascalCase、含大量縮寫的名稱、以連字號分隔的詞，以及混合短詞都可接受。空白輸入或僅含標點的輸入會被拒絕，因為其中沒有可轉換的 token。
- 檢視斷詞結果。工具會顯示它如何把輸入切成 token，讓你察覺意料之外的狀況，例如某個縮寫沒有在你預期處切開，或數字邊界以出乎意料的方式聚合。在這個階段確認斷詞結果，能避免日後重新命名時犯錯。
- 選擇符合程式碼庫慣例的輸出。六種輸出同時可見，且各自有獨立的複製控制項，因此你可以複製 snake_case 給 Python 模組、複製 kebab-case 給 CSS class、複製 PascalCase 給 TypeScript 介面，而無須重新輸入。
- 複製所選的值，並執行專案層級的檢查。搜尋所有參考處、執行格式化工具與 linter、進行型別檢查、在匯出的識別符號、資料庫欄位、環境變數、URL 或 JSON 屬性名稱變更時準備遷移或相容性別名，並在合併前確認測試仍然通過。
整個流程透過 React 在本機端執行，不會執行貼上的內容。輸入上限為五千個程式碼單元，以維持算繪與剪貼簿操作的負載在合理範圍，因此非常大的檔案需要分批處理。即使此工具不會上傳或儲存任何內容，也請勿貼上機密資料、API 金鑰、私有原始碼或可識別個人身分的資料，除非你的組織允許本機端處理。
常見識別符號的實作範例
同一套斷詞規則對不同的輸入會產生差異極大的輸出，以下幾個實際例子可以展示邊界究竟落在哪裡。
| 輸入 | snake_case | kebab-case | camelCase | PascalCase | CONSTANT_CASE | Title Case |
|---|---|---|---|---|---|---|
| XMLHttpRequest | xml_http_request | xml-http-request | xmlHttpRequest | XmlHttpRequest | XML_HTTP_REQUEST | Xml Http Request |
| userProfile2FA | user_profile2_fa | user-profile2-fa | userProfile2Fa | UserProfile2Fa | USER_PROFILE2_FA | User Profile2 Fa |
| get-URL-by-id | get_url_by_id | get-url-by-id | getUrlById | GetUrlById | GET_URL_BY_ID | Get Url By Id |
縮寫規則正是讓 XMLHttpRequest 不會變成 x_m_l_http_request 的關鍵。數字規則讓「2」留在 userProfile2FA 所屬的單字中，因此 camelCase 會以 userProfile2Fa 呈現，其中邊界落在數字「2」與大寫「F」之間。以連字號分隔的輸入其行為，等同於輸入以空格分隔 —— 連字號會成為邊界，而六種輸出都會把它們吸收為連接符或大小寫重設點。這些都是機械式形式，而非通用的風格規則;若某個專案偏好將該縮寫的標準形式定為 userID 而非 userId，任何基於規則的轉換器都不會產生 userID;而縮寫政策、單複數選擇、非英文文字的轉寫，以及產品名稱內部大寫字母的處理方式等決策，都落在工具範圍之外。
文字轉換器並不等於重構
轉換器產生的是文字，重新命名改變的則是系統。在一次大規模的大小寫調整之後，將這兩者混為一談，正是建置失敗最常見的原因。
變更一個匯出的識別符號、資料庫欄位、環境變數、URL 路徑或 JSON 屬性，即使新的拼法看起來更整潔，也屬於破壞性變更。呼叫端、序列化的承載內容、儲存的查詢、彙整的記錄、儀表板以及下游服務，都可能仰賴既有的大小寫形式。檔案系統與資料庫依據不同的大小寫敏感性規則來比對識別符號，因此一個僅在大寫上有所差異的重新命名，通常需要一個中介名稱 —— 例如先 user_profile、再 userProfile、最後 UserProfile —— 才能避免衝突，並讓消費者有一段更新參考的過渡期。產生的程式碼、透過反射機制探索的元件、設定檔、伺服器端樣板、外部消費者的程式碼以及第三方整合，也都可能包含語言感知型重命名工具所無法找到的參考。單純在原始檔中搜尋並取代，將會漏掉所有產生的檔案、所有編譯後的成品、所有快取的序列化結果，以及所有文件範例。
請規劃涵蓋所有消費者的重新命名作業，在納入版本控制的檔案以及任何外部儲存的參考清單中執行搜尋，並為你無法更新的呼叫端所引用的符號準備相容性別名。在合併一次大規模重新命名之前，請檢視差異並規劃部署順序。多服務的重新命名通常以下列方式進行較為安全:新名稱與舊名稱並存、在一次發行週期內讓程式碼庫逐步遷移至新名稱，並在遙測資料確認已無剩餘參考後，才移除舊的別名。對資料庫而言，請撰寫前向遷移與回復遷移;對 API 而言，請發布棄用通知標頭與停用日期;對環境變數而言，請在設定載入器中同時保留兩個名稱的對應，持續至少一個發行週期。Camel Case to Snake Case Converter 給你的是正確的拼字;而測試、遷移、相容性別名以及分階段的部署計畫，才是讓變更得以落地的關鍵。
若你正在權衡各種選項，Excel Formulas Cheat Sheet: Command Line vs Online 對此有詳細說明。
若你正在權衡各種選項，Git Cheat Sheet Alternative Built Around Safer Copy Habits 對此有詳細說明。