理解數字世界中的紙張：PDF | 科普

HTML · 發表 2018-09-12 14:38:07

摘要：引言 PDF 是我們打交道最多的檔案格式之一。提到這個格式，即使是對技術並不熟悉的使用者，也能說出「通用性好」、「格式不會亂變」這些優點。但同時，PDF 也是讓我們感到困惑最多的格式之一，因為與 Word 文件等其他常見辦公軟體格式相比，PDF 似乎有著太多的「怪癖」，例如複製文字困難、...

引言

ofollow,noindex" target="_blank">PDF 是我們打交道最多的檔案格式之一。提到這個格式，即使是對技術並不熟悉的使用者，也能說出「通用性好」、「格式不會亂變」這些優點。但同時，PDF 也是讓我們感到困惑最多的格式之一，因為與 Word 文件等其他常見辦公軟體格式相比，PDF 似乎有著太多的「怪癖」，例如複製文字困難、幾乎沒法編輯等等。PDF 軟體數量繁多、質量良莠不齊的現狀，也進一步讓很多使用者無法正確理解和使用 PDF。

然而，事實並非如此。這些問題大多不是 PDF 格式的「缺陷」，而是因為我們 在觀念上把 PDF 當成了和其他辦公文件格式相近的東西 ，並因此期待 PDF 也具有和後者相似的功能和特徵。

儘管 PDF 格式和 Word 格式在實際用途上有諸多重疊之處，但那只是表面現象。從技術角度看，兩種格式之間的差異要遠遠大於 Word 文件和網頁之間的差異，甚至還要大於 Word 文件和 Excel 表格之間的差異。

但這並不意味著 PDF 就是一種難以理解的格式。恰恰相反，對大多數使用者來說，PDF 可能是他們接觸到的格式中最「接地氣」、與現實生活最接近的。因為， PDF 與其說是一種數字文件，不如說是實體文件在數字世界中的影像。對 PDF 的操作，很大程度上可以看成對真實紙張的操作，只是操作環境從物理世界換到了數字世界而已。PDF 的建立就是一種虛擬的列印，複製 PDF 文字的過程更像是一種抄寫，而 PDF 的編輯實質上是一種塗改。

一旦接受了這個觀念，PDF 的很多「怪癖」就顯得順理成章了：打印出來的東西當然不會因為位置的變化而改變外觀；抄寫的結果很可能與原文存在誤差，並且受制於抄寫者對文字的理解；塗改的可行性則取決於原有佈局留下了多少改動空間，並且再輕微的塗改也會對紙張造成損傷。

當然，只給出這樣的結論並不足以令人信服。因此，下文的主要任務就是通過回答幾個關於 PDF 格式普遍關心的問題，結合 PDF 的結構和語法，解釋為什麼 「PDF 的本質就是數字化的紙張」 ，從而深化對 PDF 格式的理解。

為什麼 PDF 的外觀非常穩定？

在我們日常使用的文件格式中，PDF 檔案的外觀是最穩定的。一經生成，無論在什麼作業系統上、用什麼軟體開啟，得到的顯示效果幾乎總是一致的。相比之下，Word 所使用 docx 格式的保真性就差得多了：哪怕只是換臺電腦，顯示效果都可能發生了變化，更不要說用不同版本的 Word 或者第三方軟體打開了。

PDF 的這種保真性讓它廣受青睞，但它究竟是如何做到這一點的？PDF 的穩定是絕對的嗎？

「列印」出來的 PDF

如果平時注意觀察，容易發現各種軟體中涉及 PDF 的操作，用詞都比較特別。其他格式都是被「新建」（new / create）出來或者「儲存」（save）下來的，只有 PDF 是被 「匯出」 （export）甚至 「列印」 （print）出來的。這些詞語並不是隨意選用的，它們本身就說明了 PDF 的重要特徵：「匯出」暗示著檔案編輯已經告一段落，而「列印」則更是形象地表明 PDF 的建立是一個「固化」的過程。

為了進一步理解這種區別，讓我們來對比一組外觀上完全相同的 Word 文件和 PDF 文件。下圖中，右側的 PDF 格式檔案是由左側的 Word 檔案匯出得到的，兩者的內容都只有「Hello world!」一行居中文字。（注：為了避免不必要的複雜性，我們暫時只以英文文件為例。）

先來看 Word 是如何實現這一版式效果的。用任意解壓工具將該文件解開（docx 檔案 XML" rel="nofollow,noindex" target="_blank">實質上就是一個壓縮包），找到其中的 /word/_rels/document.xml 並開啟。其中的關鍵部分如下（程式碼經過整理）：

<w:pPr>
<w:jc w:val="center"/>
<w:rPr><w:rFonts w:ascii="Times" w:hAnsi="Times"/><w:lang w:val="en-US"/></w:rPr>
</w:pPr>
<w:r w:rsidRPr="003C75CF">
<w:rPr><w:rFonts w:ascii="Times" w:hAnsi="Times"/></w:rPr>
<w:t>Hello world!</w:t>
</w:r>

不必恐懼這些陌生的程式碼，它們的意義很容易從文件內容本身反推出來。先看倒數第二行，這裡記錄了整個文件最重要的資訊——「Hello world!」這串文字。在它的上面一行， w:rFonts 屬性將字型設定為 Times。那麼前四行是做什麼的呢？從第二行的 center 字樣不難猜出，它們控制的是文字所在段落的樣式，包括居中對齊等等。

這就是 docx 格式這類 標記語言 （Markup Language）文件的特徵：在純文字上包裹各種「標籤」（tag）來描述文字的樣式（顏色、位置、字型等等），從而獲得格式豐富多變的文件。常見的網頁（HTML）、Evernote 筆記（ ENML ）所用的語法本質上都是標記語言，區別只在於支援的標籤各不相同、因此能實現的格式有多有少罷了。

PDF 又是怎麼做的呢？我們用純文字編輯器開啟上圖中的 PDF 檔案（是的，PDF 可以用文字編輯器開啟檢視原始碼），其中的關鍵部分如下（經過處理）：

BT
1 0 0 1 1036 572 Tm
/TT1 12 Tf
[ (He) 24 (l) -48 (l) -48 (o) ] TJ
ET
BT
1 0 0 1 1147 572 Tm
/TT1 12 Tf
( ) Tj
ET
BT
1 0 0 1 1160 572 Tm
/TT1 12 Tf
[ (w) 24 (or) -84 (l) -24 (d) ] TJ
ET

即使你被這些凌亂的數字和代號弄得一頭霧水，大概也能看出它與 docx 格式有著截然不同的畫風。如果我們粗略地把這些語句翻譯成「人話」：

【文字開始】
縮放比例1倍 座標(1036,572) 【文字定位】
/TT1 12磅 【選擇字型】
[ (He) 間距24 (l) 間距-48 (l) 間距-48 (o) ] 【繪製文字】
【文字結束】
【文字開始】
縮放比例1倍 座標(1147,572) 【文字定位】
/TT1 12磅 【選擇字型】
(空格) 【繪製文字】
【文字結束】
【文字開始】
縮放比例1倍 座標(1060,572) 【文字定位】
/TT1 12磅 【選擇字型】
[ (w) 間距24 (or) 間距-84 (l) 間距-24 (d) ] 【繪製文字】
【文字結束】

請在頭腦中想象一下這個過程——是不是有一種強烈的「機械感」？如果說 Word 文件使用的標記語言很像是給人下命令（「這裡有一段話，把它用 Times 字型寫出來，位置上居中對齊……」），那麼 PDF 的語言則更像是在控制機器，定位、調整、落筆、抬起，移動到下一行；如此重複。聯想一下，鉛字排版和印表機的工作機制不也是類似的嗎？可見，用「列印」一詞來搭配 PDF 是十分恰當的。

如此對比之下，PDF 顯示效果的保真性就容易解釋了。雖然 Word 格式使用的語法明顯更容易理解，但問題在於不同「人」——不同軟體環境——聽到同樣一段指令，頭腦中的反應未必是相同的。「用 Times 字型顯示」——哪個是 Times 字型？沒有安裝這個字型怎麼辦？「居中對齊」——以什麼為參照物居中？怎麼計算居中？Word 文件對此笑而不語，把問題留給了軟體去思考。正是這種自由裁量的空間為顯示效果的差異留下了隱患。

在 PDF 中，這樣的問題就很難出現。與標記語言那種相對的、描述式的標籤不同，PDF 語言幾乎都是絕對的、指令式的。例如，上面的 PDF 中，文字明顯是居中的，但程式碼中從頭到尾沒有半個字提到「居中」；相反，它直接指明瞭文字的座標。因此，無論什麼閱讀器讀到這份檔案，只要根據座標「照葫蘆畫瓢」地繪製，一定能得到相同的顯示效果。

類似地，下面這段程式碼的作用是繪製出一個點狀的「L」形，很難想象它會給軟體留下什麼「自由發揮」的空間：

8 w 1 J [20] 0 d【設定畫筆為 8pt 寬、末端圓角、20pt 點狀線】
200 200 m 200 100 l 250 100 l 【移動到(200,200) 畫直線到(200,100) 畫直線到(250,100) 】
S 【確認繪製】

PDF 外觀穩定性的另一個原因是它嵌入了各種需要用到的外部資源。我們注意到，上面的 PDF 在設定字型時，沒有像 docx 檔案那樣直接指定字型名稱，而是引用了一個代號般的 /TT1 。實際上， /TT1 指向的是一個內嵌的字型，儲存在 PDF 內部的偏後位置。顯示時，閱讀器將根據這個代號找到字型，按照其中記載的形狀、寬度等資訊，將字元「書寫」在指定的座標上——就好比活字排版工按指示從字盤中取出字模，並放在母版上的特定位置一樣。相反，Word 文件預設是不嵌入字型的；只要另一臺電腦上沒有安裝用到的字型，或者安裝了不同版本的字型，就會導致顯示效果的差異。

保真性的例外

不過，PDF 的這種保真性也不是絕對的。儘管 PDF 語句已經非常精確，也不能排除存在不同解讀方式的可能。特別是在 PDF 檔案本身有瑕疵（例如語法不合規範、資原始檔缺損等）時，閱讀器就必須「猜測」檔案原本的意圖，誤差也就因此產生了。

例如，下面這份 PDF 格式論文是從中國知網下載的。在用 Adobe 的官方 PDF 工具 Acrobat 開啟時，檔案基本顯示正常。而在用 macOS 自帶的預覽 app 或 PDF Expert 開啟時，就能明顯看出顯示效果是有問題的——所有的中文都變成了黑體，而不是應有的宋體。（你可能注意到從知網下載的 PDF 經常存在字型顯示問題。這是因為它們並非由排版軟體直接匯出的「一手」版本，而是從私有的 CAJ 格式轉制而來的，存在很多相容性問題。）

為什麼會出現這樣的問題呢？用 Acrobat 附帶的 Preflight 工具檢查檔案，可以發現它引用了包含 STSong-Light （即華文宋體細版）在內的數個字型，但卻沒有嵌入對應的字型檔案。顯然，這種空頭支票式的做法會引起閱讀器的困惑，它們將只能「猜測」該用什麼來代替 STSong-Light ，不同的猜測結論將引發不同的顯示結果。

其中，Acrobat 是一個非常「仁慈」的閱讀器，會盡可能做一些合理推測來修復檔案本身的瑕疵。可以看出，它選擇了一個類似的字型——同屬宋體的 Adobe Song Std Light——來代替這個不存在的 STSong-Light 。相反，自帶的預覽 app 就沒有那麼多考慮了，它選擇直接回退到 系統介面的預設字型 —— 蘋方來顯示，於是我們就只能和一片黑糊糊的黑體大眼瞪小眼。而如果用 Acrobat 的修復功能將缺失的字型檔案補充進 PDF 後，將會發現預覽 app 也能正確顯示中文字型了，這印證了我們對問題成因的分析。

為什麼 PDF 中的文字經常難以複製？

如果說 PDF 顯示效果的穩定是它吸引人們使用的主要優勢，那麼「文字難複製」一定是它讓很多人敬而遠之的原因之首。確實，從網頁上覆制文字的那種方便靈活在 PDF 這裡幾乎是一種奢望。很多時候，就連第一關——準確選中要複製的文字，都是難以跨越的障礙。

PDF 為什麼對複製操作這麼不友好呢？換種問法，滿足什麼條件的 PDF 才能正確複製出文字呢？答案是， PDF 檔案的內容、文字的排列方式，以及文字和字型的編碼都會影響到文字的複製。另外，閱讀器對於複製操作的優化也是不可忽視的。

從掃描版 PDF 複製文字

要把文字複製出來，一個前提是 PDF 中必須真的包含文字。這聽起來好像是一句廢話，但實踐中大多數「文字複製不出來」的問題，原因都是目標 PDF 中根本沒有文字。這尤其多見於那些掃描而來的電子書和電子文件；如果不經處理，它們的每一頁不過是原始檔案的一張「照片」而已，顯然無法複製出文字。

當然，掃描版 PDF 是完全可能支援複製的。OCR（光學字元識別）工具可以識別出影象中的文字，並將其寫入 PDF 中，使其支援選中和複製；這也是很多收費 PDF 軟體主要宣傳的功能點。需要避免的一個認識誤區是，即使經過 OCR 處理的 PDF，其中的文字也並不是「附身」在原來的圖片上的。相反，它們通常被儲存在一個單獨的 文字物件 中，與圖片中的文字位置一一對齊。只不過由於 PDF 中的文字可以被設定為隱藏，當用戶試圖選中和複製這些隱藏文字時，看起來就好像是直接在圖片上選中和複製文字一樣。

這就解釋了為什麼在一些掃描版 PDF 中，文字選中效果看起來是「歪」的；而在另一些 PDF 中，選中和複製操作總是不連續或不完整。前者是因為加入的隱藏文字圖層沒有與圖片上的文字位置對齊，後者則是因為 OCR 識別不全，或者將連續的文字識別成了孤立的文字。

跨行和跨段複製文字

麻煩還遠沒有結束。即使確認了 PDF 中包含文字，也並不意味著就能把它們原封不動地複製出來。在複製跨越數行乃至數段的大片文字時，我們往往不能得到所預期的完整段落，而是多了一些無用的空白或者換行。例如，在下圖所示的複製結果中，PDF 似乎把頁面上的換行和連字元照單全收了，即使它們顯然不是原文的一部分。同樣的問題也會影響到文字搜尋，很多 PDF 中，斷成兩行的詞是無法正常搜尋的。

這類現象仍然可以從「紙」的比喻中得到解釋。和紙質檔案一樣，PDF 只負責記載形態而不記載含義。一個可能違反直覺的事實是， PDF 對於「段落」是沒有概念的。 在其他格式中複製跨越兩行的文字，之所以能得到連續的結果，是因為軟體知道這串文字 屬於同一個段落 ，顯示成兩行只是因為文件寬度的限制。類似地，如果一個長單詞被拆成兩行顯示，其他格式在複製時是不會帶上連字元的，因為軟體知道那 不是單詞的一部分 。

在 PDF 中，這些結論都不適用。還是以上面那份 PDF 為例。觀察它的第一段第二行到第二段第一行：這三行涉及了分詞（行尾連字元）和分段兩個排版要素。這一部分在 PDF 程式碼中的反映是：

q 1 0 0 1 57 755 cm BT 【定位到(57,755)】
13 0 0 13 0 0 Tm /Tc1 1 Tf 【設定字型】
[(…略去之前部分…) -141.7 (indepen) ] TJ 【繪製第一段第二行】
ET Q
q 1 0 0 1 533 755 cm BT 【定位到(533,755)】
13 0 0 13 0 0 Tm /Tc1 1 Tf 【設定字型】
(-) Tj 【繪製行尾的連字元】
ET Q
q 1 0 0 1 57 738 cm BT 【定位到(57,738)】
13 0 0 13 0 0 Tm /Tc1 1 Tf 【設定字型】
[ (dent o) 6 (…略去中間部分…) (ems) 5 (. ) ] TJ 【繪製第一段第三行】
ET Q
q 1 0 0 1 57 715 cm BT 【定位到(57,715)】
13 0 0 13 0 0 Tm /Tc1 1 Tf 【設定字型】
[ (Based ) (…略去之後部分…)] TJ 【繪製第二段第一行】
ET Q

這裡，我們需要關注的只有兩點：第一，程式碼中的 Tj 或 TJ （繪製文字）命令每次處理的文字都不超過一行。實際上，PDF 實現換行和分段的方法，只不過是把那個「想象中的筆尖」移動到下一行或下一段的起始座標處罷了。換句話說，除了筆尖移動幅度更大（以反映段間距）， 分段和普通分行在 PDF 中沒有任何區別。

第二，原文第二行行尾的連字元出現在了 PDF 程式碼中。在同一份文件的 Word 版本程式碼中，這個連字元是不存在的，因為它並不是輸入內容的一部分。換句話說，其他格式不在檔案中記錄，只在開啟時才根據需要顯示的排版特性，製成 PDF 後卻被 「固化」 下來了。

既然 PDF 不記錄段落資訊，而換行和連字元又明明白白地寫在檔案中，它們會出現在複製結果裡也就並不奇怪了。

當然，閱讀器可以根據文字的內容和佈局等特徵進行推斷，提供更為合理的複製效果。例如開啟上面的 PDF 時，PDF Expert 和 Chrome 瀏覽器內建的閱讀器都會對行尾的連字元作特殊處理，複製的結果是一個完整的單詞，搜尋中間斷開的「independent」整詞也能定位到結果；相反，用 macOS 自帶的預覽 app 和 Firefox 內建的閱讀器開啟時，複製操作會把連字元當作單詞的一部分，搜尋整詞也得不到結果。

可能有人會問：PDF 為什麼連如此基礎的段落功能都不支援呢？這實際上是一種有意為之的選擇。PDF 是作為一種電子化的列印被發明出來的，而列印意味著 編輯工作的終點 。因此，PDF 完全可以不考慮巨集觀層面的排版功能（因為用來建立它的字處理和製版軟體在這方面更專業），而只保留對少數區域性版式（例如文字間距/Kerning）的支援。這不僅有利於節省檔案空間，也進一步強化了 PDF 跨平臺顯示的穩定性。

複製 PDF 文字的亂碼問題

確認了 PDF 裡有文字，文字的排列也很整齊，是不是就能皆大歡喜了呢？很遺憾，對於中文使用者來說，從 PDF 中複製文字經常還會遇到一道坎：亂碼。

亂碼問題雖然在其他場合（例如網頁、遊戲等）也存在，但那基本都是發生在文字的顯示階段。既然 PDF 都正確顯示了文字，為什麼一經複製卻變得不是那回事了呢？

如上所述，PDF 的生成本質上就是一個「虛擬列印」的過程。這個比喻的言外之意—— 印表機是不識字的 。它的全部使命，就是在紙張上按照座標和字型記載的形狀，照葫蘆畫瓢地排列出指定的文字；整個過程完全不涉及「這是什麼字」之類的問題。類似地，PDF 繪製文字的流程，也不過是從字型資原始檔中取出特定碼位上的字元（glyph），放置在某個座標位置上。至於取出來的到底是什麼字，PDF 根本不關心。

可如果 PDF 是一個「文盲」，它在複製操作中又是靠什麼給出我們需要的文字的呢？

我們知道，計算機中的文字是通過編碼來區分和呼叫的。目前，最通用和常見的編碼方案是 Unicode 。另一方面，在 PDF 內部嵌入的字型檔案中，每個字元也有一個編碼；繪製文字時， Tj / TJ 命令可以通過這個編碼向字型檔案索取需要的字元。

上述兩套編碼可以是（並且在非英文環境下往往是）不同的，它們之間的「橋樑」，就是字型所附帶的 ToUnicode 屬性。 ToUnicode 的值是一張對映關係表（稱作 character map / CMap），它給出了字型檔案中每個碼位上的字元與 Unicode 編碼的對應關係。在複製、搜尋等操作中，PDF 就是靠 CMap 這張表得知每個字元到底是什麼「字」的。

問題是：如果這張表弄丟了呢？或者雖然沒有丟，但是缺損了一塊？或者被人惡意篡改了？

讓我們來做一個「指鹿為馬」的實驗。下圖是一個非常簡單的 PDF 檔案，上面只有一個「鹿」字。

用文字編輯器開啟 PDF，可以看到 <ba6f> Tj 這一語句。不難猜出，該語句的作用是繪製字型檔案中編碼為 0xBA6F 的字元。根據 PDF 物件的交叉引用關係（後文會介紹）找到 CMap，其關鍵部分為：

1 beginbfrange
<ba6f> <ba6f> <2fc5>
endbfrange

不難看出，這個 CMap 告訴閱讀器：字型檔案中編碼為 0x6ABF 的字元對應 Unicode 中的 U+2FC5 。查 Unicode 碼錶可知， U+2FC5 正是漢字「鹿」。

現在，我們將上面程式碼中的 2FC5 改成 9A6C ，然後重新開啟 PDF 檔案。外觀上，檔案似乎並沒有任何變化。但如果你試著把這個字複製出來，會發現得到的結果是「馬」。

這並不是什麼靈異事件，因為「馬」在 Unicode 中正是 U+9A6C 。

上述實驗表明， PDF 中的「所見」未必就是「所得」。 只要 /ToUnicode 的內容（較舊的或者英文的 PDF 也可能是 /Encoding 屬性）發生丟失或者錯誤，文字複製就會出現亂碼。與此同時，PDF 的顯示卻不會受到任何影響（因為文字繪製是由與編碼完全無關的語句控制的）。反過來思考，利用亂碼故障的原理，也可以通過故意破壞或者修改 CMap，製造出表面正常但完全無法複製和搜尋的檔案，間接達到加密的效果。

為什麼 PDF 很難編輯？

除了顯示、複製上的問題，PDF 難以編輯的特性也經常引發使用者的疑問。不僅大多數可以免費獲得的 PDF 工具都只有閱讀功能，即使是那些具有編輯功能的軟體，編輯效果也往往達不到預期，甚至反而影響其他部分的格式。

如何解釋 PDF 的這一特徵呢？還是回到本文一以貫之的思路： 把 PDF 看作真實的紙張來理解。

試想你手上有一份紙質筆記或者檔案需要臨時塗改。生活經驗告訴我們下面幾點事實：第一，塗改操作只可能是小範圍的、逐字逐詞的。即使真的不得不修改一大段內容，你也只能慢慢用塗改液或者膠帶把它們抹去。第二，紙上原有的內容越多、格式越複雜，塗改起來就越困難。在增刪文字時必須要考慮到前後文的限制；原來的內容越密集，留下的修改餘地就越小。第三，很難實現完全不留痕跡的塗改。任何塗改操作都會對紙張造成損傷；對文字的修正，從紙張的角度看反而是一種「汙染」。

這些描述幾乎完全適用於 PDF 檔案的編輯，而原因還是要從內部結構來分析。前文中，我們已經瞭解了 PDF 語句如何在區域性層面繪製出文本和圖形，這裡再從巨集觀角度簡單介紹一下 PDF 的構造。

一個 PDF 檔案主要由四個部分構成，依次是檔案頭（Header）、主體（Body）、交叉引用表（Cross-Reference Table）和檔案尾（Trailer）。在其中最重要的主體部分，頁面、文字等元素和字型、圖片等資源儲存在稱為 「物件」 （object）的單元中。每個物件都有唯一的編號，並且可以無盡地相互包含和引用。例如，一個編號為 2 的頁面物件可以包含一個編號為 3 的子物件來描述頁面尺寸，又包含一個編號為 4 的子物件來儲存該頁上的文字；後者在指定字型時，又可以引用一個編號為 20 的字型物件，而這個字型物件的大小、字元寬度、曲線輪廓等資訊也是分別儲存在其他物件中的；等等。

讀取 PDF 時，閱讀器首先從檔案頭確定檔案型別和版本號，旋即跳轉到檔案尾，獲取交叉引用表的位置（以位元組位置表示），它進而列出了 PDF 中所有物件的位置。憑藉這張表，閱讀器就能找到每個物件，解析它們之間的包含和引用關係，並按照其中的命令將檔案的全貌繪製出來。

這樣的構造對 PDF 的編輯有什麼潛在影響呢？可以看出，PDF 的結構是 高度固化並且相互依賴 的。它就像是一個積木堆，其中的每一塊「積木」——PDF 中的一個物件——都不是獨立的，而是與四周的其他積木相互支撐。編輯 PDF 檔案就如同試圖改變一個成型的積木堆：移去或挪動一塊積木（物件），周圍的木塊不僅不會自動補上空白，反而可能因為失去支撐（物件的交叉引用關係）而變形。比如，從 PDF 中刪去一段，後面的文字並不會自動調整位置；相反，如果繪製它們的語句引用了被刪除部分的樣式，這些樣式也可能隨著刪除操作而丟失。

而如果要往積木堆上增加一塊——往 PDF 中增加內容，面臨的風險同樣很大。且不論現有的空隙是否允許這麼做，你也無法預知剩餘的積木塊中是否有自己需要的。例如，出於節省體積的考慮，PDF 中嵌入的字型檔案往往都是高度 「子集化」 的，只包含檔案中用上的那部分字元。如果準備追加的字恰好不在其列，就很可能引發顯示問題。

退一步說，即使編輯操作倖運地沒有引發任何問題，它的成本也是很高的。哪怕只是插入一個字母的「微量」編輯，也會導致排在它之後所有內容的地址向後偏移 1 位元組，於是依靠位元組計數來定位的交叉引用表必須整個重寫。假如你的改動幅度更大（例如用了新的字型），就需要靠新增物件來實現，於是其他物件也必須相應更新以反映物件編號的變化。另一方面，從 PDF 中刪去內容時，編輯器未必能聰明到把不再有用的物件一併刪去。很多時候，這些成為空殼的物件就被「拋棄」在原地，白白佔用空間，並且增加閱讀器解析檔案時的計算成本。

作為對比，Word 格式那種 標記語言 的特性——在純文字上包裹標籤來記載格式資訊——決定了它對於編輯操作是十分友好的。由於文字的內容和格式相互獨立，修改文字內容並不會對格式造成影響，反之亦然。這就好比把水倒在有造型的容器中，換掉一部分水，剩下的水依然服從於容器的形狀；換一個容器，水的形狀隨之變化，但還是原來那些水。

需要加以區分的是，對 PDF 的標註（annotation）操作——包括高亮、下劃線、筆記等——不屬於「編輯」的範疇。在實現層面，PDF 中的標註是附屬於所在頁面的子物件，其中記載了標註的型別、位置、形狀（如果有）、文字（如果有）等，與儲存檔案內容的物件相互獨立。它們就像是紙上的便利貼，可以隨時移除而不留下痕跡。

那作為使用者，如果確實遇到編輯 PDF 的需求，應當如何解決呢？

首先，應當考慮是不是真的需要修改 PDF 檔案本身。假如你將一份檔案打印出來以後發現了錯別字，第一反應恐怕是回到電腦上修改、然後重新列印那一頁，而不是用膠帶粘去錯字然後手寫。類似地，既然 PDF 檔案的本質就是「電子紙張」，如果發現錯誤，最正確和簡捷的做法應該是 改動用於生成這個 PDF 的原始文件，然後重新匯出一遍 ，而不是考慮怎麼修改 PDF 本身。

即使手上沒有生成 PDF 的原始文件，在直接修改 PDF 時也應該儘量控制編輯幅度。因為修改越多，對檔案的「汙染」就越大，也就越有可能造成格式混亂、體積膨脹等結果。如果要修改的內容確實很多，甚至可以考慮轉換/ OCR 為其他格式—編輯文字—匯出為 PDF 這樣的路徑，或許效果反而比直接編輯好得多。

最後，儘管 PDF 對編輯操作非常不友好，但畢竟「事在人為」，不同軟體的編輯能力有很大差別。例如，來自第一方的 Acrobat Pro 就明顯高於平均水平。根據測試，它不僅能從 PDF 的佈局中判斷出段落並以此為單位編輯（而不是孤立的文字塊），還能在編輯中一定程度上維持原有的對齊方式、段間距等設定。更為「黑科技」的是 Acrobat 的 OCR 功能，它甚至可以做到在識別文字的同時，將文字向量化後、分離到與背景獨立的圖層中，從而能 增刪掃描版 PDF 中的文字 。

結語

任何檔案格式都有自己最擅長的用途。對 PDF 來說，它擅長的領域就是 跨平臺交換和檔案歸檔 ，而那些需要頻繁編輯文字內容和版式的應用場景，則是其不能勝任的。只是在日常使用中，我們常常被 PDF 和其他文件格式在外觀上的相似所誤導，把它用在了不擅長的領域，然後反過來抱怨這種格式在編輯和複製中的「笨拙」。這多少是錯怪了 PDF。本文之所以一再將 PDF 類比為實體文件，一方面是為了便於解釋技術原理，另一方面也是為了提供一種選用 PDF 格式的標準：適合打印出來的內容，一般也才適合「列印」成 PDF。

理解 PDF 的原理也有助於挑選合適的閱讀/編輯工具。如上所述，軟體對瑕疵 PDF 的寬容度和修復能力，對文字搜尋、複製的識別、優化能力等細節，是最值得重點考察的；這些看似不起眼的功能點對使用體驗和工作效率有極大影響。相反，那些頻繁被當作營銷「亮點」的功能，特別是 PDF 編輯、格式轉換等，反而不那麼重要。因為 PDF 從結構上就不適合修改，這些所謂的編輯功能很難達到使用者的預期，何況還有大量類似於 SmallPDF 的免費工具可以滿足臨時的、精度不高的編輯需求。至於嚴肅、專業的 PDF 編輯，Acrobat 可能是唯一的選擇。

最後需要說明的是，PDF 涉及的技術非常複雜，這篇文章只是從日常使用的角度做了最粗淺的介紹。文中很多地方為了便於理解，採用的解釋和比喻是過度簡化的。如果對 PDF 格式的原理有進一步的興趣，建議直接閱讀 PDF 的標準檔案。這份標準雖然十分冗長，但並不難讀。哪怕只是挑選幾個關心的主題來瀏覽，相信都會對理解 PDF 格式以至排版技術有很大的啟發。