大小寫轉換替代工具是一種能在不同大小寫與命名慣例之間轉換文字的程式，而且沒有主流工具的那些麻煩——不需要註冊、不需要上傳到伺服器，也沒有一種風格只能轉一次的限制。最強的替代工具只要貼上一次，就能產生所有常見的變體:UPPERCASE、lowercase、Title Case、Sentence case、camelCase、PascalCase、snake_case、kebab-case、CONSTANT_CASE，以及一種交替樣式，每一種都各自帶有複製按鈕。它們完全在瀏覽器中執行，因此任何資料都不會離開你的裝置，這對於機密草稿、含有商業邏輯的程式碼，以及會讓其他工具卡住的大量貼上內容而言非常重要。可靠的命名風格轉換必須先對輸入重新切割詞元——依據空格、底線、連字號、標點符號，以及 camelCase 與 PascalCase 內部的隱含邊界來切分——而不是只把一種分隔符號換成另一種。Case Converter 完全符合這樣的描述:它接受任何一段文字，並立即在本地端運算出十種變體並排顯示，因此不管輸入的格式為何，相同的輸入永遠會產生相同的輸出。
為什麼人們會搜尋大小寫轉換替代工具
大多數人第一次並不會直接搜尋「case converter」——他們是在對現有工具感到挫折後，才開始搜尋替代方案。這些挫折可以歸納成一個簡短的清單，而每一項都對應到一個更好的工具應該要修正的特質。
註冊牆是首要問題。許多線上大小寫轉換工具在顯示結果前會要求你輸入電子郵件，這對一個本應兩秒搞定的工作多加了摩擦。對於一個在瀏覽器中執行 JavaScript 的工具來說，要求註冊帳號其實是多餘的，而一個能跳過表單的替代工具，才更接近正確的設計。
伺服器上傳是第二個疑慮。幾個熱門的大小寫轉換工具會在你貼上文字後，先把內容送到遠端伺服器，才回傳結果。這代表你所貼上的任何內容——草稿文章、內部文件、嵌在程式碼裡的 API 金鑰——都會離開你的電腦。基於瀏覽器的替代工具則永遠不會把文字傳送到任何地方。
風格涵蓋不足是第三個落差。許多轉換工具只提供大寫、小寫和首字母大寫，然後就沒了。對寫作者來說這樣或許還行，但對開發者來說遠遠不夠。如果一個工具分不出 camelCase、PascalCase、snake_case、kebab-case 之間的差別，它就無法協助變數命名、URL 簡稱產生，或是環境變數的正規化。
脆弱的命名轉換是第四個問題。一個只是把空格換成底線、卻沒有先對輸入重新切割詞元的工具，只要你的輸入混用了分隔符號，就會產生錯誤的結果。下一節將說明怎樣才能讓命名轉換可靠。
一個好的替代工具應該提供什麼
一個真正的大小寫轉換替代工具涵蓋兩種截然不同的風格類別:用於散文寫作的書寫風格，以及用於程式碼的命名風格。把這兩者混為一談，正是許多較弱的工具讓人覺得半成品的根本原因。
書寫風格包含 UPPERCASE、lowercase、Title Case、Sentence case，以及交替樣式。Title Case 將每個字的首字母大寫，適合用於標題與文章標頭。Sentence case 只把每句的首字母大寫——以句號、問號、驚嘆號作為分句依據——這是內文與 UI 標籤的正確風格。UPPERCASE 與 lowercase 則是針對那些不小心全大寫或卡住 Caps Lock 的輸入所做的快速修正。交替樣式會逐字翻轉大小寫，並跳過空格與標點，產生如 aLtErNaTiNg 的視覺波浪效果。
命名風格屬於語法層面，而非單純外觀。camelCase(例如 helloWorld)是 JavaScript 與 Java 中變數與函式的慣例。PascalCase(例如 HelloWorld)用於類別、React 元件與型別名稱。snake_case(例如 hello_world)是 Python 與 SQL 中變數與欄位名稱的慣例——關於 Python 特有考量的更多細節，請參考這篇Python 大小寫轉換方法比較。kebab-case(例如 hello-world)用於 URL、CSS class 與檔案名稱。CONSTANT_CASE(例如 HELLO_WORLD)則標示環境變數與編譯期常數。
一個好的替代工具會在同一次貼中同時呈現所有這些風格，讓相同的輸入一次產生每一種樣式，而不是一次只能產生一種。同樣的特性——單一的標準化詞元切割——讓每一種輸出在任何輸入格式下都保持一致。
如何使用 Case Converter
- 在輸入框中輸入或貼上你的文字。無論是一句話、一個標題、一個變數名稱，還是一整列識別字，都可以。
- 在下方即時看到全部十種大小寫與命名慣例的變體。列表會隨著你的輸入即時更新，因此你不需要按按鈕重新整理。
- 點選任一結果旁的「複製」按鈕，即可將該版本放進剪貼簿，直接貼到你的編輯器、試算表、IDE 或表單中。
沒有註冊、沒有上傳、也不需要等待。這個工具在你的瀏覽器中使用 JavaScript 執行，因此網頁載入後即可離線運作，處理大量貼上內容時也不必與伺服器往返。
為什麼沒有重新切割詞元，命名轉換就會出錯
在駱駝式、蛇式、烤肉串與常數式大小寫之間互轉，聽起來很簡單，直到你拿一個真實的識別字去試才知道。天真的做法——把每一個分隔符號換成目標分隔符號——只有在輸入全部使用相同分隔符號時才會成功。真實世界的輸入往往會混用各種分隔符號。
以 fooBar_baz-qux 為例。天真的轉換工具看到底線與連字號，把它們都換成空格，結果產生像 fooBar baz qux 這樣的東西，完全忽略了一處 camelCase 邊界。輸出看起來合理，實則悄悄地錯了，而這類錯誤正是編譯器、API 與路由規則出問題的根源。
一個會先重新切割詞元的轉換工具，會在所有能偵測到的字詞邊界上切分輸入:空格、底線、連字號、標點符號、camelCase 與 PascalCase 內部的小寫到大寫轉換，以及縮寫結尾處的大寫到小寫轉換。輸入 fooBar_baz-qux 會被切成 [foo, Bar, baz, qux] 的詞元清單，接著每一種風格都不過是用不同方式把這些詞元重新接起來而已。
另外有兩條規則很重要。數字會留在所屬的字詞中，因此 order66 會被視為一個詞元，而不是兩個。縮寫會以大寫到小寫的轉換作為偵測依據，因此 HTMLParser 會切成 HTML 與 Parser，而不是 H、T、M、L、Parser。這兩條規則都能避免那種在凌晨兩點讓人除蟲除到天亮的細微錯誤。
相同的輸入永遠會產生相同的輸出，這在你撰寫腳本批次改整個目錄的檔名、或對一整欄資料做可重現的正規化時格外重要。
不同的工作該挑哪一種風格
這十種變體並不能互相通用。下方表格將每種風格對應到它典型的使用情境，讓你能快速選出正確的一種，不必硬背規則。
| Style | Example | Best for |
|---|---|---|
| UPPERCASE | HELLO WORLD | 強調、按鈕標籤、需要引人注目的標題 |
| lowercase | hello world | 快速修正卡住的 Caps Lock、將全大寫輸入正規化 |
| Title Case | Hello World | 標題、文章標頭、導覽標籤 |
| Sentence case | Hello world | 內文、UI 標籤、說明文字 |
| camelCase | helloWorld | JavaScript 與 Java 的變數與函式 |
| PascalCase | HelloWorld | 類別名稱、React 元件、型別名稱 |
| snake_case | hello_world | Python 與 SQL 的變數與欄位名稱 |
| kebab-case | hello-world | URL 簡稱、CSS class、檔案名稱 |
| CONSTANT_CASE | HELLO_WORLD | 環境變數、編譯期常數 |
| aLtErNaTiNg | hElLo WoRlD | 風格化效果、社群貼文、玩樂用途 |
書寫風格與命名風格服務的對象不同。寫作者會選 Title Case 或 Sentence case;開發者會選 camelCase、snake_case 或 CONSTANT_CASE。一個能在同一次貼上中同時服務這兩種族群的工具，省去了在兩個網站之間往返的成本。
足以讓人換工具的常見情境
有幾種反覆出現的情境會讓人開始尋找大小寫轉換替代工具。
修正標題的大小寫。當你從其他地方貼上內容時，CMS 或所見即所得編輯器常常會把 Title Case 弄得一團亂。與其逐一手動修補每個大寫字母，不如把壞掉的版本貼進工具，再把重新產生的 Title Case 變體複製回去——尤其是當標題很長時，這個方法會快很多。
依團隊風格指南重新命名變數。風格指南之所以存在，是因為不一致會成為每位未來讀者的負擔。把手動把十個 camelCase 識別字改成 snake_case 的成本，單看每個識別字或許很小，但放到整個程式碼庫上就非常可觀;這個工具只要貼上一次就能完成轉換。
在不同層之間轉換 API 欄位名稱。JSON API 通常使用 camelCase，而資料庫則儲存 snake_case。API 中的 createdAt 到了資料庫會變成 created_at，而這個對映在整個 schema 中是一致的。手工處理這種工作，正好是會在某個凌晨兩點引入一個字母級 bug 的那種事。
把標題轉成 URL 簡稱。大多數內容管理系統接受手寫的簡稱，也接受自動產生的版本。自動產生雖然方便，卻常常會冒出令人意外的結果;把標題貼進工具，複製 kebab-case 變體，再貼上去當作簡稱即可。
把環境變數名稱統一為 CONSTANT_CASE。某個腳本裡的 CONFIG_FILE_PATH 與另一個腳本裡的 configFilePath，其實是同一個變數;團隊只要選定 CONSTANT_CASE 作為環境變數的命名，就能用同一份基準來統一舊有的腳本。
產生交替樣式文字。雖然純屬裝飾效果，但 aLtErNaTiNg 文字是社群媒體上一種辨識度很高的風格，而這個工具能以確定的方式產生出來，而不是憑感覺亂打。
在以上所有情境中，這個工具始終有一個關鍵特性:結果是在本地端運算的，因此不論你是在沒有 Wi-Fi 的飛機上，還是在政策禁止上傳的環境中，同樣的貼上內容都會產生同樣的輸出。這個特性，正是它成為一個真正替代工具、而不只是同一支託管腳本的另一層包裝的原因。
想深入了解，可以參考瀏覽器版 Lorem Ipsum 產生器 API 替代方案。