3.2 標點符號處理
本文翻譯自 http://www.tei-c.org/release/doc/tei-p5-doc/zh-tw/html/CO.html#COPU, 2011.12.9-16
標點符號對於文本標記導致兩個不同類別的問題：該符號可能不在所使用的字集裡，以及它們可能會有顯著的歧義。
某種程度上來說，Unicode 字集解決了第一類問題，因為它提供了大部分標點符號的編碼，另外從它區分用於不同功能的字形(例如句點、逗點、連字號) 來說，它也解決了第二類問題。
如果標點本身是研究的主題，可以使用 pc (punctuation character, 標點字元) 元素明確標示，如 17.1.2 Below the word level 所進一步討論的。
如果所使用的標點符號在 Unicode 之中未提供，可以使用 5 Representation of Non-standard Characters and Glyphs 描述的 g 元素以及其它機制來標示。
標點的功能
標點符號本身就是一種形式的標記，它的出現是為了提供讀者一個指示，關於該文本應該如何閱讀。
因此，不足為奇的，標記人員常會想要直接標記標點符號所提供的目的，可能跟標點同時存在，其至取代標點符號本身。
下面我們討論一些典型的案例。
句點可以標示句子的邊界、縮寫、小數點，或者做為印刷數字的視覺輔助。
這些用法可以分別使用 16.3 Blocks, Segments, and Anchors、3.5.5 Abbreviations and Their Expansions 以及 3.5.3 Numbers and Measures 的 S-單位、縮寫以及數字標籤來做區分。
然而，不管有沒有用句點標示，也有另外一些獨立的原因要加上這些標籤，而句號本身的多義性也許跟書寫系統的任何其他字元沒有差別。
問號跟驚歎號經常標示句子的結尾，但是作者也可能用作句子中間的註釋 (! 表示驚訝或某種其他的強烈情緒，? 用來詢問一個字詞或表示式。或在語言討論中將某句話標示為有疑問的)。
這些用法可以標示 S-單位來區分，標點在句子中間的用法就可以不標記，或者使用 17.1 Linguistic Segment Categories 討論的 pc 元素來標記。
破折號(dash)的用途很多種：遺漏、插入或中斷的標示；在對話中顯示一個新的說話者接手；或者表示一個清單的項目。
尤其是後兩種情況，顯然需要使用 q 或 item 標示它們的功能以及呈現，分別參見 3.3.3 Quotation 以及 3.7 Lists。
引號可能會因為編輯理由而從文本的 q 或 quote 元素中移除，或者它們可能以多種方式標示；請看 3.3.3 Quotation 對於引用及相關功能的討論。
Apostrophes (撇號、所有格符號) 必須與單引號區別。
類似連字號 (hyphens) 的情況，消歧義最好的方式是選用適當的 Unicode 字元，雖然也可以如上面建議的使用適當的引文 XML 標記。
然而，撇號有多種用途。
在英語中，它們標示收縮、屬格(genitive)形式，以及(偶爾) 複數形式。
這些用途的完全消歧義屬於語言分析及詮釋的層次。
圓括號 (parentheses) 以及其他懸置標示，例如破折號或橢圓形，經常用於標誌文本片段的句法結構資訊。
它們的用法的完整消歧義也是屬於語言分析及詮釋的層次，因此需要使用 17 Simple Analytic Mechanisms 討論的機制。
當標點符號籍由在文本中標記它們的功能 (例如引文) 來消除歧義，它們應該被排除或保留在文本中，可能會有爭議。
以引號來說，使用適當的 Unicode 字元來區分開始以及結束符號可能比使用 q 元素更方便，不管有沒有 @rend 屬性。
當自動執行文本分割的時候，如果不同標點字元的功能先被明確標記，可以大大增進結果的正確性。
並不需要所有情況都這麼做，而是只有當標點標記的結構功能 (例如作為一個單字或詞組的分隔符) 有歧義的時候。
這樣，可能可以區別指示縮寫的小圓點與指示句子結束的小圓點，以及句子中間的驚歎號或問號與結束一個句子的驚歎號或問號。
此外，在標記史料的時候，可能會認為保留原始標點是有必要的，不論是使用適當的字元編碼，如果有的話 (或者沒有的話就使用 g 元素)，或是使用 pc 明確標記。
採用的特定方法會隨著關心的功能以及專案的目的而有所不同。
連字符
使用連字符的現象通常在產生印刷或螢幕顯示格式化文字時最受關注：關於在什麼地方使用連字號、為什麼使用連字號，不同的語言以及系統已經發展出相當複雜的規則。
這些通常與文本標記人員無關，既然它們屬於格式化的領域，而且通常會交由所使用的 rendition software 處理。
在這節裡，我們討論為了分析或其他處理而重新標記的現存格式化文本裡的連字符產生的問題。
Unicode 區分四個長得像連字符的字元，包括基於相容性因素而保留的未分化的連字符-減號 (U+002D)。
硬連字符 (hard hyphen, U+2010) 跟用於數學表示式的減號 (U+2212) 不同，也可能出現在「born digital (出生時就是數位版)」文件裡的軟連字符 (soft hyphen, U+00AD) 不同，軟連字符指出文件格式化時可接受插入連字符的位置。
從歷史上看，硬連字符因為兩個不同的目的被用於印刷或手寫文件中。
在許多語言中，它被用在單字之間表示它們是當做一個語法或詞彙單位。
例如法文中的 est-ce que；英文中的 body-snatcher, tea-party 等等。
它也可能在消歧義中扮演重要的角色。例如，區別 man-eating fish(吃人魚) 跟 man eating fish(人吃魚) 的不同。
這種用法，雖然在進行語言分析時可能有問題，但通常不會引起文本標記人員的關注：連字符字元通常會保留在文本裡，因為它可以被為複合字或其他詞彙項目的拼寫方式的一部份。
決定一個複合字是否要分解成它的組成部分，如果要的話那要如何做，這是另一個不同的問題，涉及到考慮單純一個連字符之外的許多其他現象。
然而，當它出現在印刷或書寫的行末時，硬連字符通常表示 (可能與預期的正好相反) 某個字還沒有完成，而是延續到下一行 (也可能是下一頁或欄或其他邊界)。
在這種情況下，連字符並不是字詞的一部分，它只是一個信號指出這個字詞跨行。
不幸的是，很少語言會在視覺上區分這兩種情況，這必然會造成文本標記人員的問題。
例如，假設我們希望調查一個歷時久遠的英語文集之中出現的 "tea-pot" 以及 "teapot"，以找出這個複合字在某個時間點變成詞彙化的證據。
任何跨行、以連字符連接的字詞的情況，像這樣：
tea-pot
這完全是歧義的(ambiguous)：根本沒辦法決定它是兩種拼寫法的哪一種。
跟別的地方一樣，標記人員可以有一些選擇：
- 他們可能決定簡單將所有行末連字符移除，理由是它的出現純粹只是次要的格式問題。明顯地，如果行末本身被視為不重要的，也會實施這種方式。
- 或者，他們可能決定記錄連字符的存在，理由可能是它提供有用的形態學資訊；也可能是為了保留原始來源的視覺外觀資訊。這兩種情況，不管哪一種，他們都需要決定是否要明確的記錄它，藉由在文字資料中含括一個適當的標點字元，或是隱含式的在用來記錄分行事實的 lb 或其他 milestone 元素的一個或多個屬性提供適當的符號值。
類似範圍的可能性，同樣適用於其他常見標點符號的表示，尤其是引號，3.3.3報價討論，如 3.3.3 Quotation 所討論的。
組成 XML 文件的「文字資料」可以分解成更小的單位，這裡稱為 orthographic tokens (拼字正確的符記)，即使這些單位沒有用 XML 標記明確的指示出來。
行末連字符的歧義，也會因為缺乏明確的標記，在處理器辨識這些 tokens 的方式中導致問題。
如果 token 邊界沒有明確標示出來 (例如使用 seg 或 w 元素)，對於大多數語言來說，處理器會依據字元類別資訊來決定如何找到它們：有些標點字元會被視為會切斷字詞，而其他的則不會。
在 XML 裡，文字資料裡的換行字元是空白的一種，因此它會切斷字詞。
然而，如果假設永遠保留緊鄰標記標籤的空白，這通常是不安全的；如果假設標記標籤本身等同於空白，這更是決然不安全的。
值得注意的是 lb、pb 以及 cb 是這個一般規則的例外，因為它們的功能就是代表 (或替代) 換行、換頁、換欄，這些通常被視為等同於空格 (譯註：中文情況則不是如此，lb、pb 以及 cb 元素不能視為空白，也不能視為斷詞的邊界，它們前後的字元在文字串中應視為緊鄰而沒有任何分隔的)。
這些元素提供一個更可靠的方式來保留來源文件中的換行、換頁等，因為標記人員不應假設 XML 來源檔中的換行等 (未標記的) 一定會保留。
要控制如預期的斷詞 (tokenization)，標記者可使用這類元素的 @break 屬性指出該元素是否可視為等同空格。
這個屬性的值可以是 yes 或 no 來指出該元素是否為 token 的邊界。
該屬性值也可以是「maybe」，如果標記者不想(或不能)決定該行末是否可以做為斷詞的分隔。
最後一個複雜的地方，要注意在某些語言，尤其是德文和荷蘭文，行末連字符的存在可能改變一個單詞的拼寫。
例如，荷蘭文的 opaatje (爺爺)，出現在行末時可能會加上連字符變成 opa-tje，字母 a 只出現一次。
標記者如果想要保留這個 orthographic token 在印刷文本的原始形式，同時還要能辨認出它是 opaatje 這個單字，那就需要一個更複雜的處理程序，而不只是簡單的將連字符移除。
然而，這跟其他形式的「伴隨拼寫或形態變異辨識的正規化」一樣：它可能使用 3.4 Simple Editorial Changes 所討論的 choice 元素，或用 17 Simple Analytic Mechanisms 所討論的更複雜的語言分析機制。