將一段文字中的每個單字大寫，意思就是將每個單字的第一個字母提升為大寫，其餘字母保持不變，產生像「Hello World」這種標題、書名和 UI 標籤常用的形式。這種轉換通常稱為 Title Case(標題大小寫)，也是「capitalize each word」(將每個單字大寫)這個搜尋查詢最常見的解讀方式。現代的大小寫轉換工具可以從一次貼上產生 Title Case 以及其他九種大小寫樣式:UPPERCASE、lowercase、Sentence case、camelCase、PascalCase、snake_case、kebab-case、CONSTANT_CASE，以及交錯的 aLtErNaTiNg 樣式，因此您不需要為標題和變數名稱分別準備不同的工具。這種「一次貼上、多種輸出」的工作流程之所以重要，是因為手動將一段落中的每個單字大寫既繁瑣又容易出錯，而手動將 snake_case 變數重新格式化為 camelCase 更糟糕:漏掉一個分隔邊界就會讓程式碼出錯。透過輸入一次並讀取十種變體，您可以同時省下手動工作和避免不一致的問題。
「Capitalize Each Word」的真正含義
這個詞組聽起來簡單，但其實涵蓋了三種不同的意圖，而您屬於哪一種將決定要複製哪一種輸出樣式。第一種是字面上的意圖:將每個單字的第一個字母大寫，其餘字母小寫，因此「the quick brown fox」會變成「The Quick Brown Fox」。這就是 Title Case，適用於標題、文章標題、歌曲名稱、書本章節，以及每個重要單字都大寫的產品卡片。
第二種意圖是 Sentence case(句首大寫)，只有每個句子的第一個字母會大寫。「the quick brown fox. the lazy dog.」會變成「The quick brown fox. The lazy dog.」Sentence case 是內文、部落格段落、UI 標籤、電子郵件訊息，以及任何讀者從頭到尾閱讀的散文所使用的正確慣例。在連續的散文中將每個單字大寫會顯得過於厚重並損害可讀性，這也是為什麼大多數風格指南將 Title Case 保留給標題，其他情況則使用 Sentence case。
第三種意圖與程式設計有關:在變數、函數或類別名稱內，根據您使用的語言的大小寫規則將每個單字大寫。「the quick brown fox」在 JavaScript 中可能變成 theQuickBrownFox，在類別名稱中變成 TheQuickBrownFox，在 Python 中變成 the_quick_brown_fox，作為 CSS 類別或 URL slug 時變成 the-quick-brown-fox，作為環境常數時變成 THE_QUICK_BROWN_FOX。轉換的概念一樣，都是拆分成單字並將每個單字大寫，但連接字元改變了它的意義。
Title Case vs. Sentence Case:選擇正確的那一個
在 Title Case 和 Sentence case 之間做選擇，是寫作者最常面對的大小寫決定，而這條規則比大多數風格指南說明的還要簡單。Title Case 用於標題、頁首和簡短標籤:部落格文章標題、導覽項目、按鈕文字和投影片標題。Sentence case 用於連續的散文:段落、說明文字、清單項目、錯誤訊息和產品描述。大多數風格指南在 Title Case 中會將冠詞、連接詞和簡短的介詞保持小寫(「The Lord of the Rings」，而不是「The Lord Of The Rings」)，但在一般日常網路使用中，簡單的「capitalize each word」形式已被廣泛接受。
如果您不確定需要哪一個，可以將文字貼到 case converter，並並排閱讀兩種版本。當每個單字都大寫時，標題看起來就對;當只有句首大寫時，段落看起來就對。同一段輸入在一種樣式中可能看起來錯誤，在另一種樣式中卻正確，把它們放在一起看就能消除猜測。
| Writing style | Example output | Best for |
|---|---|---|
| UPPERCASE | HELLO WORLD | Emphasis, signage, warning labels |
| lowercase | hello world | Calm tone, resetting caps-lock mishaps |
| Title Case | Hello World | Headlines, article titles, short labels |
| Sentence case | Hello world | Body copy, paragraphs, UI strings |
| aLtErNaTiNg | HeLlO WoRlD | Decorative or playful text |
命名慣例:依您語言的規則將每個單字大寫
在程式設計中，將每個單字大寫不是裝飾性的，而是語法的一部分。大多數語言會拒絕像 useraccountid 這樣的名稱，因為無法辨識單字邊界;但對於 userAccountId 則能順利編譯，因為 camelCase 讓三個單字一目了然。您最常會遇到的五種慣例是:JavaScript 和 Java 變數使用的 camelCase、類別名稱和 React 元件使用的 PascalCase、Python 變數和 SQL 欄位名稱使用的 snake_case、URL 和 CSS 類別使用的 kebab-case，以及環境變數和其他編譯期常數使用的 CONSTANT_CASE。
手動混用這些慣例是小錯誤最常見的來源。一個不小心被貼成 camelCase 的 snake_case 名稱雖然能編譯，但會被讀成一個長字;一個不小心用 camelCase 輸入的 CONSTANT_CASE 常數會變成完全不同的變數;一個不小心混入了底線的 kebab-case URL slug 將無法再對應到路由。一個可靠的避免這些錯誤的方法是:將原始名稱貼到大小寫轉換工具中，然後每次都複製您的程式碼庫所期望的變體。
| Naming style | Example output | Typical use |
|---|---|---|
| camelCase | helloWorld | JavaScript and Java variables and functions |
| PascalCase | HelloWorld | Class names, React components, type names |
| snake_case | hello_world | Python variables, SQL column names |
| kebab-case | hello-world | URL slugs, CSS classes, file names |
| CONSTANT_CASE | HELLO_WORLD | Environment variables, compile-time constants |
從「Capitalize Each Word」開始的常見任務
幾乎所有文字重新格式化的任務最終都會以某種形式變成「capitalize each word」。修正從 PDF 複製貼上後變成全小寫的標題。將 CSV 標頭欄從 Title Case 重新命名為資料庫期望的 snake_case。將部落格標題轉換為 kebab-case 的 URL slug。將 JSON 中的 camelCase API 欄位名稱轉換為 SQL INSERT 使用的 snake_case。將「welcome to the team」轉換為投影片的 Title Case 標語。將因為 Caps Lock 開著而打出來的全大寫文字轉為小寫。將一整列產品名稱標準化，讓每個名稱都以大寫字母開頭。一旦您能從一次貼上看到全部十種樣式，這些任務每一個都只是一行的工作。
一個更細微的使用情境是重新格式化大小寫錯誤的人名、產品名稱或品牌名稱。貼上「ACME corporation」並同時讀取 Title Case(「Acme Corporation」)和 Sentence case(「Acme corporation」)，您就能立刻判斷哪一個符合官方品牌規範。同樣的邏輯也適用於轉換環境變數、標準化 commit 訊息，以及為線框圖準備佔位文字——這類場景中每個標題都必須以大寫字母開頭。
如何一次將每個單字大寫(並產生另外九種樣式)
- 在瀏覽器中開啟 Case Converter。
- 在頁面頂部的輸入框中輸入或貼上您的文字。
- 讀取輸入框下方即時產生的十種輸出變體:Title Case、UPPERCASE、lowercase、Sentence case、camelCase、PascalCase、snake_case、kebab-case、CONSTANT_CASE，以及交錯樣式。
- 並排比較各種變體，挑選最符合您情境的那一個。
- 點選該結果旁的 Copy 按鈕將其複製到剪貼簿，然後貼到您需要的地方。
由於所有轉換都在您的瀏覽器中本地執行，這個工具可以離線使用，處理大量貼上時不需要往返伺服器，也絕不會上傳您輸入的內容。這在您重新格式化內部變數名稱、合約草稿或任何您不想傳送給第三方的內容時非常重要。
為什麼邊界偵測對混合輸入很重要
「capitalize each word」最困難的部分不是大小寫，而是在混合分隔符的輸入中找出單字邊界。一個只會將底線替換為連字號的天真工具，可以乾淨地將 snake_case 轉換為 kebab-case，但遇到像 fooBar_baz-qux 這樣的輸入就會卡住，因為沒有空格可以分割。一個可靠的大小寫轉換工具會先重新對輸入進行分詞:它會根據空格、底線、連字號和標點符號進行分割，並且能偵測 camelCase 和 PascalCase 的邊界，因此 fooBar_baz-qux 無論以何種樣式輸入，都會被正確理解為四個單字(foo、Bar、baz、qux)。
這種重新分詞的機制也能處理數字和縮寫。order66 會被視為一個 token，而不是在數字處切開。HTMLParser 會在縮寫邊界被辨識為兩個單字(HTML、Parser)，因此會轉換為 snake_case 的 html_parser 和 camelCase 的 htmlParser，而不是 html_parser_r 或 h_t_m_l_parser。像 SNAKE_CASE_CONSTANT 這種已經全大寫的縮寫密集識別符，因為每個單字在被重新套用大小寫之前都會先被簡化為單一標準形式，所以能乾淨地標準化為 camelCase。
實際上的結果是，相同的輸入永遠會產生相同的輸出。如果您正在批次處理一組變數名稱、重新格式化一整欄資料，或從一整欄標題產生 URL slug 清單，確定性正是讓結果從第一列到最後一列都保持一致的原因。