別再用六個點當省略號了，你天天在用的標點這樣輸入才正確

08-24

來自專欄少數派423 人贊了文章

引言

在電腦和手機上，文本輸入是我們再熟悉不過的操作。但提到輸入，很多人首先想到的只是輸入文字，而符號——包括標點符號和特殊字元——的輸入則往往不太受到重視。觀念上，這似乎是一件非常瑣碎而簡單的事情，不值得單獨討論和專門學習。

真的是這樣嗎？請試試看能不能答得出下面幾個問題：

英文中的右單引號、縮寫詞中的撇號和表示英尺的「撇」是一個符號嗎？它們是垂直的還是彎曲的？

表示一個範圍時，連接前後數字的橫線符號是鍵盤上加號左邊的那個嗎？這個鍵是「減號」嗎？

外國人名字里的圓點是怎麼打出來的？這個圓點到底有多大？

從網上甚至很多印刷品文章中的使用情況看，人們對符號用法和輸入方法的掌握程度並沒有自己想像的那麼樂觀。但是，只要掌握少量的基礎知識和技巧，正確輸入和使用符號是非常輕鬆的。下文中，我將總結一些容易誤用的符號，並說明各平台上輸入符號的一般方法。結合我的學習和使用體會，本文將不會按符號的用法來歸類，而是按符號的「外形」歸類，將幾組形態類似而經常被互相混淆的符號放在一起比較說明。

引號和各種「撇」

引號的彎與直

把引號放在最前面說，不是因為它的使用率最高，而是因為它最容易被用錯。眾所周知，引號不是一個符號，而是一對符號，有前後之分；它們是雙引號 「」（U+201C 和 U+201D Left/Right Double Quotation Mark）或單引號 『』（U+2018 和 U+2019 Left/Right Single Quotation Mark），即所謂的「彎引號」。但是，鍵盤上卻只有一個「引號」鍵，而且輸入的也不是「正牌」的、彎曲的引號，而是垂直的（U+0027 Apostrophe）和 "（U+0022 Quotation Mark），即所謂的「直引號」。這種違反直覺的安排實際上是打字機時代的遺產：為了節省空間、減少機械結構，打字機的鍵位安排思路是「能少一個是一個」，而現代鍵盤則為了遷就習慣而將其原封不動地繼承了下來。

中文用戶可能對這個問題感受不太明顯，因為任何中文輸入法下的引號鍵都會輸出彎引號。「按一次是前引號，再按一次是後引號」是小學信息課就會教的口訣（儘管顯然不嚴謹）。但對於幾乎不需要輸入法輔助的英文用戶來說，圖省事直接用直引號就是再常見不過的做法。因此，引號的「彎」「直」之辨是西文排版的入門課之一。翻開任何一本英文排版書籍，幾乎都能找到對於直引號痛心疾首的批判，理由也很明顯——太丑。在排版中使用直引號（常常也被嘲諷地稱為「打字機引號」或「呆（dumb）引號」）被認為是一種偷懶或業餘的行為。

macOS 和 iOS 作為一家設計導向的公司的產品，顯然不會「放任」這種審美上的瑕疵，默認情況下所有的直引號都會被自動糾正為成對的彎引號。以 Word 為代表的多數排版軟體也會這麼做。但對於工作內容涉及代碼編輯的用戶來說，這種替換顯然會造成困擾（代碼中的引號幾乎都是直引號）。因此，建議關閉引號的自動糾正功能（多數軟體的「編輯」>「替換」菜單下），而使用組合鍵來輸入引號：左側的雙引號和單引號分別是 Option + [ 和 Option + ]，而對應的右側引號則只要分別加按 Shift 鍵。iOS 的鍵盤默認輸入的已經是彎引號，直引號可以通過長按獲得。

要不要用中文引號？

但引號輸入還有一個非常中國特色的問題，即是否應該使用「直角引號」（「」，U+300C 和 U+300D Corner Brackets）。

不可否認，儘管國家標準規定中文引號的形態與西文相同，但直角引號在中文互聯網上的人氣似乎已經蓋過了前者，成為了很多在線社區的成文或事實標準。至少在兩三年前，提供切換引號形態的設置選項就成了輸入法的通行做法；新款國行 MacBook 甚至直接把直角引號印到了鍵盤的大括弧鍵上，中文狀態下可以直接用 Shift + [ / ] 打出，iOS 的中文鍵盤上則可以通過長按引號鍵輸入。

問題是，很多人換用直角引號只是一種隨大流的選擇，並不了解為什麼要這麼換、和原來的用法比起來有什麼優劣，以至於經常打出 「『』」 這樣不倫不類的用法（單層引號的內部應當嵌套雙層引號 「『』」，macOS 在輸入時會自動處理）。實際上，對直角引號的提倡是從知乎開始的，可以追溯到 2012 年前後。在知乎上以「直角引號」為關鍵詞搜索，仍然可以看到當時大量的討論和爭議。

概括地說，直角引號的提倡者主要有如下理由：其一，與冒號、分號等標點都有用於東亞文字的全形版本不同，彎引號缺少一個中文專用的版本。無論中文西文，彎引號都是同樣碼位上的同一對字元，其外形完全取決於字體。在中西文混排的場合，彎引號常常因為套用西文字體而顯示為半形寬度，與漢字和其他中文標點差異很大，從而對排版效果產生不利影響。其二，提倡者認為直角引號的形態與方塊字更加契合。其三，直角引號在香港、台灣和日本都是官方規範，這也為將其「進口」到簡體中文世界提供了依據。

本文無意對兩種引號的選擇作出結論，也缺乏這麼做的資格和必要。但無論你站在哪一邊，都應當是基於技術上或審美上理由的自主選擇，而不是出於對標準原教旨式的遵從（請注意兩岸涉及標點符號的標準文件都不是強制性的）或無謂的「格調」「潮流」之爭。

撇號和角分符號

最後，有必要提一下撇號和角分符號，它們都是常見的、因為形態與引號相近而經常被誤用和混用的符號。

撇號（apos-tro-phe）是英文中用來標示所有格（John』s apple）和省略（isn』t）的符號，其正確形態是一個右單引號，即 』（U+2019 Right Single Quotation Mark），因此同樣需要注意避免用成直引號。另外，對於 rock 』n』 roll 這樣連用撇號的情形，要特別注意撇號的方向：字母 n 兩側的撇號很容易被系統自動「修正」為一對引號；這也是為什麼提倡儘可能直接用組合鍵輸入引號，而不是依賴軟體糾正。

角分符號（primes）是常見於度量單位的符號，包括表示英尺、分鐘等的角分 ′（U+2032 Prime）和表示英寸、秒數等的角秒 ″（U+2033 Double Prime）。這組符號在 macOS 和 iOS 上都沒有快捷的輸入方法；不少西文字體也沒有包含它們，正確輸入很多時候反而會帶來不佳的排版效果。因此有觀點認為，除了在用到時調用符號面板輸入，用直引號來代替也是可接受的妥協方案，並且可以開啟斜體來更好地模仿原符號的傾斜。（但注意不要用彎引號，因為角分符號的形態無論如何不可能是彎曲的。）

各種「橫線」

另一組誤用頻率不亞於引號的符號，大概就是包括連字元、連接號和破折號在內的各種「橫線」形符號了。它們一方面數量繁多且形態相近，另一方面在中英文中的形態和用途並不完全對應，從而更容易產生誤認。

為了方便講述和記憶，我們按照從短到長的順序來梳理這些符號。最短的橫線是連字元 -（U+2010 Hyphen-Minus），也是最容易輸入的，就在鍵盤上數字 0 的右側。但與多數人的直覺不同，連字元在大多數時候並不需要手動輸入：它的主要用途是將較長的西文單詞斷成兩行，而這是由軟體自動加在行尾的。需要手打連字元的場景基本只有在多個部分組成的名稱或辭彙內部，例如 Rolls-Royce、whack-a-mole，等等。

那為什麼我們會覺得連字元是一個高頻符號呢？這是因為它經常被當作更長一些的連接號（dash）用了。在西文中，連接號有一短一長兩個，分別是 –（U+2013 En Dash）和 —（U+2014 Em Dash），它們的名字來源於活字印刷術語——「em」是金屬活字的垂直長度，「en」則是前者的一半。

連接號在英文中的用途非常廣泛。先看較短的 en dash。各種數字（pages 1–10）、日期（Tuesday–Thursday）、年份（1949–2018）、地名（a Beijing–Shanghai train）之間都是用它來連接。它也用在一些由兩個人共同提出的理論、概念中（Herfindahl–Hirschman index）。至於較長的 em dash，它在英文中的作用很像中文的破折號，用於句中的插入語前後（類似逗號）、引出補充說明或列舉（類似冒號）、標示中斷或間隔等。

兩種連接號在 macOS 上可以分別通過按 Option + -（即連字元鍵）或 Option + Shift + - 得到。iOS 的英文鍵盤上，長按連字元鍵就能在彈出的浮動條中看到它們。

以上說的是英文中的情況，中文裡的這些「橫線」又是如何使用的呢？首先，連字元在中文裡基本是沒有用武之地的。其次，對於起連接作用的符號，國內標準將其細化為短橫線、一字線和浪紋線三種，分別對應前面所說的 en dash、em dash，和 ～（U+FF5E Fullwidth Tilde）。至於三種形態的各自用途，國標的列舉過於繁瑣，簡記方法是：一字線（em dash）和浪紋線可以互換，用於表示時間、地域、數字的起止；其他表示「連接」的場合都用短橫線（en dash）。

至於我們最熟悉的破折號，實踐中的用法並不統一。最通用的做法是連續使用兩個 em dash ——。這種用例的問題在於它本質上還是兩個獨立的字元，因此如果字體設置不正確，會產生中間斷開的視覺效果，不符合規範；在一些極端情況下，還會出現後半截被擠到下一行開頭這一令人困惑的情況。因此，排版中有時也會使用佔兩個漢字空間的 ?（U+2E3A Two-Em Dash）充當破折號，相應的問題當然就是輸入不便。

至於這些符號在中文環境下的輸入，在 macOS 上與英文基本沒有區別，多出的破折號通過 Shift + - 輸入也是人盡皆知。iOS 上的情況比較混亂，可以參看下圖。

各種「圓點」

句號

在中文中，除了最常見的圓圈形句號 。（U+3002 Ideographic Full Stop），理工學科的用戶一定也經常見到用與英文句號形態接近的全形「句點」．（U+FF0E Fullwidth Full Stop）充當句號的做法。這是為了避免和數字 0、字母 o 等「圓圈」形字元混淆（想像一下它們被用於下標且位於句尾時的情形）。另外，國內參考文獻標準中，作者、題名等各屬性間也是使用 ．，而不是英文句號。

macOS 的中文輸入法沒有直接輸入全形句點的組合鍵，需要先按 Shift + 6 打開標點輸入面板，按一下 tab 鍵切換到「符號」選項卡，然後向下翻找。iOS 上，全形句點可以通過長按中文鍵盤上的英文句號按鍵找到。

省略號

中文狀態下輸入省略號幾乎人人都會，Shift + 6 組合鍵會輸出連續的兩個…（U+2026 Horizontal Ellipsis），這也是中文省略號的標準形態。問題在於，按照國內規範，省略號在高度上應當居中，因此也有拿兩個數學專用的 ?（U+22EF Midline Horizontal Ellipsis）充當省略號的做法（iOS 中文鍵盤上長按省略號就能看到這個字元）。這實際上是一種「以（造）形害（語）義」——標點符號的形態應該是通過調整字體來控制的——並不值得提倡。

掌握程度普遍較差的是英文狀態下省略號的輸入方法。實際上這也是很多英文用戶搞不清楚的，原因還是拜打字機所賜。當時，由於鍵盤上沒有省略號的一席之地，人們的權宜之計是連用三個句點 .（U+002E Full Stop）代表省略號，有時還在兩兩之間加上空格，即 . . .。這種不規範的習慣被保留至今。雖然大多數自動糾正機制都會把三個點自動替換成正確的省略號 …，但正宗的輸入方式還是值得一記：Option + ;（分號鍵）。iOS 的英文鍵盤上可以通過長按句號來輸入省略號。

間隔號

間隔號這個名字聽起來或許令人有些陌生，實際上卻是一個被頻繁使用的標點，外文人名（史蒂夫·喬布斯）、詞曲名（《天凈沙·秋思》）、節日和紀念日（「3·15」消費者權益保護日）中的「圓點」，用的都是間隔號。

根據標準，間隔號對應的字元是 ·（U+00B7 Middle Dot）。但由於在形態上與其相似的符號太多，很多人在用到時會打開輸入法的符號列表隨手找一個，經常中槍的包括 ?（U+2022 Bullet）乃至 ●（U+25CF Black Circle），看起來頗為古怪。還有一些用戶因為不了解間隔號的輸入方法，用連字元、空格，甚至英文句號代替，這顯然也是不規範的。

實際上，間隔號的輸入非常容易：大多數中文輸入法將這個字元映射在 ~ 鍵（即緊鄰主鍵盤區數字 1 左邊的按鍵）上，直接按下即可輸入。iOS 的中文輸入法直接提供了間隔號。

需要指出，按照國標，間隔號在形態上應該佔據一個漢字的寬度。這就產生了一個和中文彎引號一樣的問題：中文的間隔號沒有單獨的碼位，在與西文混排時往往因為調用西文字體而顯示為半形寬度。這個問題目前沒有很好的解決方案。一些觀點指出可以使用日文的 ?（U+30FB Katakana Middle Dot）來代替，但這顯然存在輸入難度和兼容性上的問題。

「看不見」的符號

回車的「軟」與「硬」

將回車鍵說成是「符號」似乎有些奇怪，但如果打開 Word 敲一下回車，你將能看到一個淺藍色的段落標記，並且可以選中、移動和刪除，這就是它符號身份的證明。回車不僅被程序當作符號看待，而且有一個專門的碼位（U+000D Carriage Return）。當然，它確實具有區別於普通符號的特殊身份——控制字元；換句話說，其主要作用是傳遞某種控制功能。

與回車相關的一些疑惑也正來源於這種雙重身份。例如，Word 文檔打開項目編號時，按下回車就會讓段落序號遞增，但有時我們只是想讓原來的段落新增一行；在微信中，按下鍵盤右下角的藍色按鍵（相當於回車）就會把信息發出去，但有時我們只是想給消息分個段。在這兩種情形下，軟體都把回車操作理解為控制功能（新建段落或發送消息），儘管我們預期的結果更多是語義上。那麼，有沒有一個不帶控制性含義、純粹表示換行的「符號」呢？答案是肯定的，這就是所謂的「軟回車」，它在 Unicode 中的身份是 U+2028 Line Separator。

桌面系統上，軟回車的輸入方式取決於軟體。大多數字處理軟體可以用 Shift + 回車來獲得軟回車；但在一些該組合鍵被其他功能佔用的軟體中（如 Numbers），則也可能是 Option + 回車。iOS 上，不藉助外接鍵盤輸入軟回車是相對困難的，比較可行的方式是為其設定一個自動替換短語。部分設計周全的 iOS 應用也可能在軟鍵盤上方的工具欄中提供這一符號（如 OmniOutliner）。

「軟」「硬」回車的區別主要適用於帶格式文本。純文本不存在「段落」的概念（只有「行」），也就無所謂「軟」和「硬」。至於比較特殊的 Markdown，連續的兩個換行符對應渲染結果中的新段落，而如果想得到一個「軟回車」，則要輸入兩個空格，然後一次回車。

最後要提醒的是，回車不是用來調節排版的工具。任何的行間距、段落間距都應該使用排版軟體的樣式設置來處理；開啟新頁的方式不是一路回車到底，而是插入分頁符。

空格和製表符

將輸入空格的方法拿出來單說似乎也是非常可笑的。但如果在 Unicode 字符集中搜索「space」，你將會看到十幾種不同的「空格」。它們並不只是「回字的四種寫法」那樣無聊的學究，而是切實地在排版和字元顯示中發揮不同作用。

對於日常使用，除了最普通的空格（U+0020 Space），最好還能了解不換行空格（U+00A0 No-Break Space）的用法。如其名稱所示，不換行空格最主要的作用就是禁止在其位置換行。譬如，在 10 Kg、? 2018 這樣的用例中，如果數字和單位、符號與文字之間的空格處發生斷行，顯然會使讀者產生困惑。這時，用不換行空格就能起到將空白前後標記為一個整體的作用，強制使其位於同一行。此外，在 HTML 和 TeX 等標記語言中，連續的多個普通空格會被當作一個空格看待，用不換行空格就可以繞開這種限制，獲得連續的空白——這也是為什麼它又被叫做「硬空格」（hard space）。

不換行空格的輸入方式因軟體而異，如在 Pages 里是 Option + 空格，而在 Word 里是 Option + Shift + 空格，HTML 語言中則可以用   來標示。

與回車一樣，空格也不應被濫用為控制排版的工具。標題居中、段落縮進（即「開頭空兩格」）應當靠排版軟體的樣式設置來實現。靠空格實現的上述效果是災難性的。

最後，tab 鍵對應的製表符（U+0009 Horizontal Tabulation）也是一個與空格相似的字元，通常佔據四個空格的位置。從名字可以看出，製表符本來是用來在打字機上製造表格效果的，但這在富文本流行的今天已經越發顯得過時和簡陋了。如今 tab 鍵更多是被單純用來控制段落縮進。在編程界，代碼縮進該用 tab 還是空格是一場不亞於 Vim 與 Emacs 之爭的聖戰，但這超越了本文的討論範圍。

疑難字元拾遺

帶聲調字母

帶聲調字母在英文中是很少用到的，在中文世界反而因為漢語拼音的普及而變成了常見需求。原理上，輸入帶聲調的拼音字母是通過「借用」附加了變音符（diacritic）的拉丁字母來實現的，其與拼音四聲的對應關係分別是：陰平——ˉ（長音符 macron）、陽平——′（銳音符 acute）、上聲——ˇ （抑揚符 caron），和去聲——`````（沉音符 grave）。

帶聲調字母的輸入在 iOS 上非常簡單：只要按住對應的字母鍵，就可以在彈出的浮動條中看到它們。這一技巧同時適用於中英文輸入法，但帶上聲 ˇ 的字母只在中文鍵盤上才能找到。macOS 上，最簡單的方法是切換到中文輸入法，直接輸入需要注音的字的拼音，然後按 Tab 鍵，就會發現韻母上出現了聲調。反覆按 Tab 直到看到所需的聲調，然後直接回車即可上屏。另外，較新版本的 macOS 借鑒了 iOS 上的交互方式，長按鍵盤上的普通字母即可看到與其相關的帶聲調版本。

數學符號

最常用的加減乘除四則運算符號中，只有加號 +(U+002B Plus Sign）是可以在鍵盤上直接打出來的。鍵盤上的減號實際上是連字元，而不是數學上的 ?（U+2212 Minus Sign）；乘和除則乾脆沒有（分別應該是 U+00D7 × Multiplication Sign 和 U+00F7 ÷ Division Sign）。又因為與減號和乘號形態相近的符號過多，即使用符號面板輸入也非常容易選錯。如果有經常使用這些符號的需求，建議為它們各自指定一個自定義短語。

此外，macOS 和 iOS 的輸入法都支持輸入符號名稱的拼音時在候選詞中顯示符號，但通過這種功能打出來的四則運算符號並不是上述標準形式，而是 emoji 化的「加粗版」（在 Unicode 中屬於 Dingbats，即裝飾字元的範疇），在規範用途中要注意避免。

我們還知道，一些字母在科學上具有特殊含義。有時候，是否大寫、是否加粗、是否使用襯線體等樣式上的區別，都會對語義產生影響（例如函數符號就是小寫、斜體、襯線體的 ??）。這些符號規範的輸入方法不是輸入普通字母，然後用字體設置改變樣式，而是使用 Unicode 中 Mathematical Alphanumeric Symbols 區塊的專用字元。macOS 上可以在字元輸入面板的 Maths Symbol 分類中找到這些符號，iOS 上則只能依靠自定義短語或第三方 app。

順帶一提，在 Twitter 上有時能看到一些非常奇特的用戶名，明顯與系統默認字體不同。這實際上就是利用了上述數學字元的樣式是特定的，因此在顯示時具有無視系統字體的「特效」的原理。

版權、商標符號和其他

常用的版權和商標符號（?、?、?）在 macOS 上可以分別通過 Option + g/r/2 輸入。Word 的自動糾正則會將 (c)、(r) 和 (tm) 替換為對應的符號形態。與它們有關的常見誤用有兩種：一是用成了中文輸入法所提示的 emoji 版本；二是手動輸入 TM 字樣，然後改成上標。

事實上，macOS 幾乎為每個 Option + 字母/數字鍵的組合都安排了一個特殊符號，如果再加按 Shift 鍵，則可以直接輸入的字元還有更多。讀者如果有興趣不妨依次試一遍，並挑一些自己用得到的專門記憶。

符號輸入方法概述

當然，很多時候我們用錯符號，未必是因為不知道該用什麼，而是因為不知道如何輸入、或者因為覺得過於麻煩而不願輸入。雖然上文在說明符號用法的同時，都給出了各自的輸入方式；但篇幅所限，提到的符號也只是 Unicode 的冰山一角。為此，在文章的最後，讓我們歸納一下常見的符號輸入方法，以便今後在遇到任何符號輸入需求時都能應對。

概括而言，主要存在下列四種方法，它們在學習成本、效率、靈活性三方面有不同的表現：

通過組合鍵：即通過按下特定的按鍵組合來輸入字元，如通過 Option + [ 來輸入左雙引號 「。這種方法的效率最高，但缺點是存在學習和記憶成本，並且可能和第三方軟體的快捷鍵衝突。
通過輸入面板：即通過在專用的符號輸入窗口或軟鍵盤中點擊來輸入字元。這種方法的學習成本最低，但使用起來也最麻煩。
通過自動糾正：即由軟體自動將形態相近且輸入方便的符號替換為正確的字元，例如將兩個連字元 -- 修正為長連接號 —。這種方法學習和使用成本都很低，但缺點是不夠靈活，在不需要修正時（例如寫代碼時）需要額外步驟來關閉。
通過用戶詞典：即預先定義一串易記的輸入碼和所需字元的對應關係，從而在輸入時可以直接從候選詞中選取。這種方法的效率、靈活性都較高，但需要花一定成本來設置。

另外，如今的用戶每天面對的不只是一台設備，而是不同形態、不同操作系統的多台設備，不同平台對符號輸入的支持情況也存在各自的特點：

macOS 是一個對符號輸入特別友好的系統。如上所述，默認鍵盤布局為各類常用特殊字元提供了組合鍵。任何文本框中，都可以用 Control + Command + 空格呼出功能完善的符號輸入面板，可以分類檢索或者按名稱搜索；中文輸入法下按 Shift + 6 可以呼出標點選單。macOS 還具有系統級的自動替換和自定義短語功能，並且可以通過 iCloud 與 iOS 設備同步。
Windows 的情況則稍微麻煩一些。Windows 的默認鍵盤布局沒有提供太多符號輸入組合鍵；由於軟體開發環境相對割裂，也很難提供系統層面的文本替換功能，基本需要依靠各個應用自行支持（例如 Word 的自動更正）。不過，Windows 內建了一個稱作「字元映射表」（Character Map）的輸入面板，可以在開始菜單的附件中找到；同時，系統的很多位置可以通過輸入字元的 Unicode 編碼，然後按 Alt + X 組合鍵來獲得該字元（例如，輸入 221A 後按 Alt + X 即可得到根號 √）。
iOS 在早期版本中的符號輸入功能比較羸弱。但經過多年的進化，如今的內建輸入法已經比較完善。無論中文鍵盤還是英文鍵盤，都提供了很多現成的常用字元，在一些鍵位上長按還可以看到與其相關的更多字元。此外，可以安裝 Symbolay、UniChar 這類第三方 app 來獲得字元分類列表、鍵盤擴展等功能。
Android 平台的碎片化較為嚴重，甚至不存在一個共同的默認鍵盤，因此無法作出概括性的評論。如果只考察第一方 app，Gboard 和 Google 拼音輸入法都能直接輸入大量特殊符號。另外，得益於平台的開放性，安裝第三方的文本替換和符號輸入工具是非常容易的，在 Play Store 上以 Unicode 為關鍵詞搜索就能找到大量這類 app。

綜合上述情況，我的建議是採用「分級處理」的策略應對符號輸入的需求：

對於常見、高頻的標點符號（將在下文列舉），應當記住直接輸入的按鍵組合。
對於常用但在移動設備上輸入不便的符號，或者相對不常見、但自己使用較多的符號（例如理科可能會較多地用到專用數學符號），最好用文本替換功能為其指定輸入碼，以便用到時快速、準確地輸入。
對於其他低頻使用的符號，偶爾用到時使用符號輸入面板（電腦上）或第三方 app（移動設備上）即可，沒有必要花費過多時間提前學習組合鍵或設置文本替換。

此外，還有很多效率類工具可以為符號輸入提供便利，例如跨平台的 TextExpander，macOS 上的 [LaunchBar]https://www.obdev.at/products/launchbar/index.html)、[KeyboardMaestro]https://www.keyboardmaestro.com/main/)，Windows 上的 AutoHotKey 等。但這些工具的主要功能並非符號輸入，在此不過多贅述。

最後，考慮到符號數量繁多，在遇到陌生符號或者拿不準用法時，下面這些文檔和工具可以作為參考：

Unicode 的官方字元列表是符號名稱、形態和用例的權威參考，只是檢索起來相對不便。
Unicode Table 是一個非常全面和美觀的網頁工具，可以按照編碼、名稱等檢索 Unicode 字元，還可以將陌生符號粘貼到搜索框來反向查找。
GB/T 15834—2011 是中國關於標點符號用法的國家標準，強烈推薦通讀。
《中文排版需求》（CLReq）是 W3C 描述中文排版需求與問題的文件，目前尚處於草案階段，但已經比較完善。文檔的 §3.1（標點符號與其排版）及附件 A（中文標點符號表）對中文標點的相關技術問題做了細緻的說明。

結語

必須承認，上文歸納的很多符號的區別是細微的，有的離「吹毛求疵」只有一步之遙，因此難免受到質疑：有必要嗎？畢竟，圓點的大小和橫線的長短似乎是很無聊的區別，用直引號代替彎引號、用連字元代替連接號也是大眾做法，「幾十年就是這樣下來」。人生苦短，為什麼要把時間花在學習和輸入符號上？

首先，符號的正確搭配能讓文本更加美觀。長文本中穿插的符號就像湖面上泛起的波瀾、綢緞上鑲嵌的裝飾，為版面帶來節奏和紋理。對我來說，這一個理由便足夠了——美本身就是值得追求的。從更實用主義的角度說，符號不只是文字的附庸，而是本身就具有語義上的重要作用。否則，句讀也就無以成為專門的學問，一個逗號也就無以引發涉及數百萬美元的訴訟。

符號的規範程度也能反映使用者對文本的用心程度。當專業人員將使用直引號斥為「dumb」時，他們指責的或許並不是這個符號本身，而是使用者的態度：如果一個人都不願意多花一點精力輸入成對的引號，怎麼能讓人相信他會認真對待自己寫出的文章呢？我的閱讀經驗也印證了這一點：雖然標點使用考究的媒體未必是（儘管更可能是）可信賴的，但胡亂使用標點的媒體幾乎一定不可能輸出什麼有價值的內容。

至於輸入正確符號的成本問題，如果說在打字機時代因為硬體條件的限制而採用妥協性的方案是可以接受的，那麼在軟體功能強大、輸入方式多元的當今，還以「麻煩」為借口堅持使用不規範的符號，就顯得沒有什麼說服力了。而且，本文也給出了解決方案：結合自己的使用頻率，綜合使用組合鍵、輸入碼和輸入面板。在寫這篇文章的過程中，我思考怎麼故意輸錯符號的時間，反而遠多於輸入正確符號的時間，因為後者經過反覆操作已經是肌肉記憶的一部分了。

當然，本文並不主張在任何時候都要一板一眼地使用最規範的符號。正如沒有必要在口語對話中刻意使用書面表達一樣，私人、日常的交流需要一些非常規的用法來表達更微妙的意涵，這也被顏文字、emoji 的大行其道所印證。何況，無論是在正式場合追求規範的符號，還是在非正式場合選擇更加活潑的變通形式，最終的目的都是一致的——用符號更好地表情達意，拓展文字傳遞信息的帶寬。