大小寫轉換

兩套標題格式,因為格式手冊本來就吵架。

本機處理
轉換後的文字
護照與報關文件上的英文姓名習慣全部大寫。The Quick Brown Fox Jumps Over the Lazy Dog,NASA 與 iPhone 混在同一句裡。
  • 字元數(進 / 出)85 / 85
  • 斷出的詞數14
  • 長度變化沒有變

有 1 個詞照你的拼法原樣保留。

有 1 個全大寫的字沒有被動。想把它們當一般字處理就把那個開關關掉。

完全在你的瀏覽器裡執行 —— 打開開發者工具的 Network 分頁就能驗證

貼上任何文字,在十四種風格之間切換,從全大寫到 camelCase 都有。按下去之前值得先知道的是:「標題大小寫」根本不是一件事 —— 美聯社與芝加哥手冊對同一句話會給出不同的答案,而幾乎每一個免費工具都默默選了其中一套,也從來不說是哪一套。

AP 與 Chicago 給的答案不一樣,而且兩個都對

拿 a study between two cities 這個片語來說。風格選 AP,你會得到 A Study Between Two Cities;選 Chicago,你會得到 A Study between Two Cities。兩個都不是 bug。兩本手冊對「虛詞」的定義不同,而且那個差異是結構性的,不是品味問題。

AP 手冊用的是長度規則:三個字母以下的冠詞、連接詞、介系詞小寫,四個字母以上一律大寫。這就是為什麼 AP 會寫 Between、Through、Against。那個門檻在上面做成一個欄位、預設是四,讓你直接看到規則,而不是自己從結果反推。

芝加哥手冊走的是相反的路。它讓介系詞一律小寫,不管有多長,所以 Chicago 在標題中間會寫 between、throughout、underneath。Chicago 靠的是一張功能詞清單而不是字母數,所以那個門檻對它完全沒有作用。

兩本手冊在一件多數工具會做錯的事情上是一致的:標題的第一個詞與最後一個詞永遠大寫,不管它是什麼。Something to Look Forward To 的最後那個 To 要保持大寫。這個工具把每一行當成獨立的標題處理,所以你可以一次貼一整串標題,每一行各自套用規則。

你手上的文件到底該照哪一本

新聞機構、新聞稿、以及大部分企業對外溝通走 AP。如果你寫的東西有可能被記者轉載,AP 是比較安全的預設值,這裡的預設值也是它。

學術出版、大學出版社與多數書籍出版走 Chicago。如果你的文件有註腳跟參考書目,它的標題八成要的是 Chicago 的標題大小寫。

網路上沒有統一答案。很多內部風格規範乾脆讓標題一律用句首大寫來繞開這場爭論,而那是站得住腳的選擇 —— 句首大寫沒有模糊空間、在小字級下讀得比較快,也不必要求任何人去背一張介系詞清單。如果你的團隊沒有成文的風格規範,句首大寫是最不會吵起來的那個選項。

「每個詞都大寫」之所以放進來,是因為表單與試算表經常要求這種格式,但沒有任何一本編輯手冊認可它用在正文上。它會把標題中間的 A、The、Of 全部大寫,讀起來像機器輸出而不像編輯過的文字。

轉大寫在不同語言裡不是同一個動作

土耳其文在英文只有一個字母的地方有兩個。一個是有點的 i、大寫也有點,另一個是沒點的、大寫就是普通的 I。用英文規則把土耳其城市名 istanbul 轉大寫會得到 ISTANBUL,那在土耳其文裡是錯的;正確結果是一個上面有點的大寫 I。把語言規則切到土耳其文就會得到它。亞塞拜然文用同一組字母、同一條規則。

希臘文的狀況不一樣。希臘文排版在整個詞轉成大寫時會把重音符號拿掉,所以雅典這個詞的大寫形式上面沒有重音,而 Unicode 的預設對應會把重音留著。在語言欄位選希臘文,套用的是排版慣例而不是逐字母的機械對應。

立陶宛文則是在小寫的 i 同時帶有重音符號時仍然保留那個點,所以把一個帶重音的大寫 I 轉小寫會變成三個分開的部件而不是一個預組字元。那是立陶宛文寫進標準的規則,也是為什麼你切換那個欄位時字元數會跟著變。

這些不是為了看起來很周全而找出來的偏門案例。它們是寫進 Unicode 標準的語言相關大小寫規則,每一個瀏覽器都實作了。幾乎沒有工具做的事情是讓你選一個 —— 於是一個土耳其名字貼進英文工具裡,回來的結果會有微妙的錯誤,而且完全不會有任何提示。

換大小寫會讓文字變長或變短

德文的 ß 是一個小寫字母,在一般用法裡沒有對應的單一大寫字母,所以轉大寫之後會變成兩個字母。六個字母的詞變成七個字母,而且把結果轉回小寫也拿不回原來那個字母。上面的長度指標會即時把這個變化顯示出來。

排版合字的行為也一樣。把 f 與 i 連在一起的那個單一字元沒有大寫形式,所以轉大寫之後會變成兩個普通字母。從 PDF 複製出來的文字經常含有這種合字而沒有人注意到,這也是為什麼換過大小寫之後字數會對不上。

土耳其文那個帶點的大寫 I 用英文規則轉小寫時是反過來的:它會變成一個普通的 i 加上一個獨立的組合用點,於是一個字母變成兩個看起來像同一個字的部件。那串文字之後要是拿去跟一個普通的 i 比對,比對會失敗,而畫面上完全看不出原因。

實務上的結論是:大小寫轉換是一趟單程票。先轉大寫再轉小寫不見得會拿回你原本的文字,與其假設之後可以復原,不如把原稿留一份。這一頁刻意不做交換鈕,正是基於同一件事:換回去的那個方向並不存在,做一顆鈕出來只是在假裝它存在。

縮寫、品牌名,以及你不想被動到的字

把一句含有 NASA 的話丟進一個天真的句首大寫工具,回來會變成 Nasa。上面那個開關會讓任何進來時就已經是全大寫的字原樣保留,縮寫、股票代號、檔案格式名稱都不必另外設定。你要刻意把一整段全大寫的文字改回正常時,才需要把它關掉。

品牌名更麻煩,因為它們既不是全大寫、也不是普通的字。一個開頭小寫的產品名稱是它的拼法,不是打字時的疏忽,而一個把它改成大寫的工具等於在你的文案裡引入了一個錯字。保護字詞那一欄吃逗號分隔的清單,只要整個詞對得上,就把你打的拼法原樣放回去,搜尋時不分大小寫。

比對是以整個詞為單位,所以保護字詞不會對到更長的字裡面那一段。如果你填了一個詞而它在文字裡根本沒出現,畫面會明白告訴你這一欄這次什麼都沒改到;一個沒有作用又不吭聲的設定欄位,比沒有那個欄位還糟。

識別字風格,以及底下那個斷詞問題

camelCase、PascalCase、snake_case、CONSTANT_CASE、kebab-case、dot.case 全部是同一個動作換不同的黏著劑:先找出有哪些詞,再用某種方式接起來。所有有意思的事情都發生在前半段。

難的是那種本身就已經含有大寫字母的識別字。要把 XMLHttpRequest 這種名稱拆開,必須看出「一串大寫後面跟著一個首字大寫的詞」代表那個縮寫要提早一個字母結束,才會得到 XML、Http、Request 而不是一整塊分不開的東西。只在「小寫接大寫」的交界處斷詞的工具會把整串壓成一個小寫詞,這就是為什麼那麼多工具會把這個名稱變成一串讀不出來的字。

數字會另起一個詞,所以版本號裡的數字不會被黏到前一個詞上。中文、日文、韓文完全沒有大小寫,但它們仍然被當成一個詞保留下來,這樣一行混合文字才不會在轉換之後掉字。

有一個取捨是刻意的,也值得講清楚:識別字風格是用找到的詞重新組出結果,所以標點與換行會被丟掉。另外八種風格則完全不動你的空白、縮排與換行結構。如果你貼進一份有排版的文件再選 snake_case,你會拿到一長串識別字 —— 那是預期行為,不是壞掉。

大小寫其實有三種,不是兩種

Unicode 裡有少數字元擁有第三種形式,跟它的大寫與小寫都不一樣。克羅埃西亞文的 dž 二合字母是最常被舉的例子:它有一個全大寫的形式、一個全小寫的形式,還有一個只有第一個部件大寫的形式,三個都是各自獨立的字元、各自有自己的碼位。

這件事對日常文字的影響不大,但對任何要寫轉換工具的人很重要,因為它推翻了「大小寫是一個布林值」這個假設。一個只在兩個狀態之間切換的函式表達不了中間那一個;本頁的反轉大小寫因此是逐字母判斷,不會假裝整串文字只有單一一種大小寫狀態。

它同時解釋了為什麼 title case 這個詞在排版領域身兼兩個毫不相干的職務。一個是編輯慣例上的標題大小寫 —— 標題裡哪些詞要大寫,也就是上面 AP 與 Chicago 那場爭論;另一個是 Unicode 的字元屬性。兩者共用一個名字,除此之外沒有任何關係。

台灣用得到的幾個實際場合

護照上的英文姓名一律全大寫,這是外交部領事事務局的表單規定,不是排版風格。要把中文姓名的羅馬拼音填進申請表、機票訂位或國際包裹的收件人欄位時,全大寫是最不會被退件的寫法 —— 訂位系統與航空公司的訂位代號本來就只吃大寫字母。把拼好的姓名貼進來、選全大寫,比自己一個字母一個字母改快得多,也不會漏掉中間名。

報關文件與商業發票的英文品名同樣習慣全大寫。公司行號在經濟部登記的英文名稱多半也是全大寫登記,所以對外的英文合約、報價單、提單上的抬頭要跟登記名稱一致時,先統一轉成全大寫再比對,比用眼睛看可靠。反過來,要把一份全大寫的舊文件改回正常的英文書寫時,句首大寫加上「不要動原本就全大寫的字」這個開關,可以一次處理好而不會把 NT、TWD、ROC 這類縮寫改壞。

中文本身沒有大小寫,但台灣的輸入環境有一個特有的麻煩:全形英文字母。用注音輸入法時不小心在全形模式下打出來的英文,看起來只是比較寬,實際上是另一組完全不同的字元。它們同樣有大小寫,這個工具也照樣轉換 —— 全形的小寫轉大寫仍然是全形的大寫,不會偷偷變成半形。也就是說,這個工具不會幫你解決全形半形的問題,它只負責大小寫;那是兩件必須分開處理的事,混在一起做會讓你搞不清楚到底是哪一個步驟把文字改壞的。

還有一個每天都在發生的情況:Caps Lock 誤觸,整段英文變成大寫,或者是「只有第一個字母被鎖成小寫、其餘正常」的那種混亂。這種文字用句首大寫處理最快,而且因為原本就全大寫的縮寫會被保留,一段夾雜著公司縮寫的英文段落可以一次改乾淨,不必回頭一個一個修。

文字留在這個分頁裡

轉換是幾百行 JavaScript,跑在你已經打開的這個頁面裡。你的文字不會離開這台機器,理由很單純:我們那一側沒有任何東西在等它。按下 F12、把請求紀錄擺在看得到的位置,然後在輸入框裡按住一個鍵不放:輸出每重畫一次,那份紀錄仍然空空如也。

值得停下來想一秒的是:大家丟進大小寫工具的那些字,多半是尚未發稿的標題、對外還沒講過的產品名、正在重排的客戶清單,或從試算表撈出來的一整欄員工姓名。它們算不上機密,只是普通的工作文件 —— 而這恰恰就是沒有人會在貼進搜尋結果第一個網站之前多想一秒的原因。

載入過一次,瀏覽器就會留一份,所以把連線拔掉也不會讓它停止轉換。這是自己把問題問到底最痛快的方法:能在飛航模式下繼續運作的軟體,根本沒有地方可以送東西出去。

常見問題

AP 跟 Chicago,標題大小寫該選哪一個?

新聞性質的東西、新聞稿與一般商務書寫選 AP;學術與書籍出版選 Chicago。如果沒有人告訴過你該照哪一套內部規範,AP 是比較常見的預設值,這裡也預先選好了它。真的有差別的時候,審稿的人早就會先跟你講。

為什麼轉成大寫之後字母變多了?

有少數字元沒有一對一的大寫。德文的 ß 會變成兩個字母,把 f 跟 i 連起來的合字也會變成兩個普通字母。上面的指標會把這個變化報出來,免得你之後才發現,說明區也會指出是哪些字元造成的。

反方向再轉一次可以拿回原來的文字嗎?

不保證。只要有字元在轉大寫時膨脹過,轉回小寫就會遺失資訊,而且原文裡有意義的大寫也永遠回不來。與其指望來回轉換,不如留一份原稿。交換鈕在這一頁刻意缺席,就是因為那個方向根本不成立。

怎麼讓一個開頭小寫的品牌名不要被改成大寫?

把它填進保護字詞那一欄,照你要顯示的樣子拼,多個項目用逗號分開。搜尋時不分大小寫,所以每個名稱只要打一次,輸出會照你的拼法。項目只會對到完整的詞,不會對到更長的字裡面那一段。

語言規則那一欄到底改變了什麼?

它選的是 Unicode 定義的語言相關大小寫規則。土耳其文與亞塞拜然文會交換兩個 i 的行為,希臘文在轉大寫時去掉重音,立陶宛文則在帶重音的小寫 i 上保留那個點。其餘每一個字母的轉換方式跟預設規則完全一樣。

為什麼選了 snake_case 之後我的分段不見了?

六種識別字風格是用偵測到的詞重新組出輸出,所以空白與標點沒有地方可以放。那是刻意的:一個含有換行的識別字不能算識別字。全大寫、全小寫、句首大寫、兩種標題格式、每個詞都大寫、交替與反轉大小寫則完全不動你的排版。

可以貼多長的文字進去?

我們沒有設上限。真正的極限是你手上這台機器還剩多少記憶體,因為整串文字自始至終沒有離開這個分頁。同一份很大的文件,手機會比筆電更早開始變慢,而且每按一個鍵都會重新轉換一次。