PDF「可以搜尋」是指其頁面包含一個真正的文字圖層，檢視器或擷取引擎可以讀取、複製和查詢；只要 PDF 本身已經有文字圖層，你就能透過執行像 PDF to Text Converter 這類的瀏覽器內擷取工具，將其轉換成可搜尋的 UTF-8 文字檔。該工具會透過 PDF.js 讀取每一頁的文字項目，依頁面順序分組，在頁與頁之間插入清楚的分隔符號，並讓你複製結果或下載為 .txt 檔案。整個轉換流程都在你的瀏覽器分頁中本機執行，因此不會上傳任何內容，文件會留在你的裝置上，同時你將其文字圖層轉換成文書處理器、搜尋框或筆記應用程式可以索引和查詢的內容。如果 PDF 是從文書處理器、排版程式或報表產生器以數位方式建立，它幾乎一定帶有你需要的文字圖層；如果是由掃描紙本產生，所謂的「文字」其實只是一張字母的圖片，需要使用不同的工具。
「可搜尋的 PDF 文字」真正的含義
兩個 PDF 在螢幕上看起來可能一模一樣，但當你按下 Ctrl+F 或嘗試拖曳選取一個句子時，表現卻可能截然不同。差異就藏在文字圖層裡。
以數位方式製作的 PDF 儲存了實際的字元碼，連同字型參考和位置資訊，用來告訴渲染器該把每個字形放在哪裡。當你在一般檢視器中開啟這類檔案時，游標會在每個字元上變成文字插入號，閱讀器的尋找功能會在所有頁面中高亮標示相符的內容，螢幕閱讀器也能將內容大聲唸出來。相較之下，掃描產生的 PDF 本質上就是一疊與頁面同尺寸的影像。視覺上看起來像文字，但像素背後並沒有任何字元碼，因此 Ctrl+F 找不到東西，選取也無法產生高亮。
當讀者搜尋如何讓 PDF 文字變得可搜尋時，他們通常是想做以下三件事之一：
- 把可存取的 PDF 中的文字抽出來，以便在其他程式中搜尋、引用或編輯。
- 在將某個 PDF 寄給同事、搜尋引擎或索引流程之前，確認它是否真的有文字圖層。
- 將掃描產生的 PDF 轉換成搜尋框可以讀取的文字，這需要光學字元辨識 (OCR)，而不是文字圖層擷取。
同樣的意圖可能對應非常不同的起點，因此第一個決策是先弄清楚你手上是哪一種類型的 PDF。
文字圖層擷取工具對你的 PDF 是否有幫助？
在開啟任何工具之前，你可以自己用大約五秒鐘測試這份文件。在你常用的檢視器中開啟 PDF，在段落中間點一下，然後嘗試拖曳游標跨過一個句子。如果出現藍色高亮，而且你可以把那些字複製到另一個視窗，代表這個檔案已經有真正的文字圖層，像 PDF to Text Converter 這類的擷取工具就能產生有用的輸出。如果游標無法選取任何內容，或只會選取整個影像區塊，則該頁面只有影像，需要使用不同的工作流程。
| PDF 類型 | 可見的文字可以選取嗎？ | 轉換器會回傳什麼 |
|---|---|---|
| 以數位方式建立（文書處理器、排版程式、報表工具） | 可以 | 完整的 UTF-8 文字，通常與原文相當接近 |
| 含有已填寫欄位的表單 | 大多可以 | 表單值、版面配置，以及該圖層所暴露的任何扁平化文字 |
| 混合型（文字圖層加上頁面影像） | 可以，但文字可能很稀疏 | 文字圖層中包含的內容；影像區域不會回傳任何東西 |
| 掃描紙本 | 不行 | 幾乎沒有文字——需要 OCR |
| 損壞或加密 | 視情況而定 | 顯示錯誤訊息，而非部分輸出 |
這個表格是一份快速分流指引。如果你落在前三列，轉換器就是合適的工具。如果你落在後兩列，請在執行擷取之前先更換策略，而不是等著拿到一個空白的結果檔案。
如何在瀏覽器中將 PDF 轉換為可搜尋的文字
轉換本身只需要點幾下。完整的流程是在單一瀏覽器分頁中使用 PDF to Text Converter，並產生一個在任何地方都能開啟的 UTF-8 .txt 檔案。
- 在你的瀏覽器中開啟 PDF to Text Converter。頁面載入後轉換器就已就緒，在你真正開始擷取之前不會要求 PDF.js worker。
- 從你的裝置中選擇一個不超過 25 MiB 的非空 PDF。檔案選擇器只接受單一文件；如果你需要先合併多個 PDF，請在另一個步驟中完成後再回到這裡。
- 點擊「Convert to Text」開始擷取。轉換器會依序向 PDF.js 請求每一頁上的文字項目，並開始組裝 UTF-8 結果。PDF.js 及其 worker 在這個時間點才會被要求載入，這讓初始的頁面 bundle 保持精簡。
- 觀察預覽逐頁建立。每一頁在合併輸出中都會有一個清楚的分隔符號，這樣某一頁的頁尾就不會不小心接到下一頁的標題。空白頁會保留在結果中，因此預覽中的頁碼仍然與來源文件一致。
- 在預覽標頭中檢視字元數與頁數。這些計數反映你實際看到的結果，並會在你切換輸入檔案時一起變動，因此它們不會在不知情的情況下描述先前的擷取結果。
- 將文字複製到剪貼簿，或點擊「Download TXT」。這兩個動作都作用在同一份組裝完成的結果上。下載時使用的是 UTF-8 文字 Blob，檔名由你原始的 PDF 檔名以確定性的方式產生，因此檔案會直接落入你的下載資料夾，可立即用於搜尋或編輯。
如果轉換器回報限制或錯誤，並不會悄悄產出檔案——該分頁會告訴你文件超出了某項預算，而不是交給你一份看起來完整但其實不完整的結果。
為什麼輸出不一定符合視覺版面
PDF 儲存的是定位過的文字，而不是像文書處理器那樣以段落形式儲存。每個字元或字詞都被放置在頁面上的某個座標，而閱讀順序是根據檔案中這些位置的排列方式重建出來的。轉換器會依照 PDF.js 所暴露的項目順序、遵循 PDF 作者嵌入的明確換行標記，並在屬於同一群組的相鄰項目之間插入保守的單一空格。
這種做法對簡單的單欄頁面處理得非常好，但有幾種常見的文件格式可能會產生令人意外的輸出：
- 多欄版面。兩欄式頁面可能會把左欄底部與右欄頂部交錯在一起，因為文字項目的排序是依據位置，而不是閱讀邏輯。
- 表格。儲存格會失去其格線對齊，變成以空格分隔的純文字行；像是欄位標頭這類語意結構不會被保留。
- 頁首、頁尾與頁碼。這些在輸出中會於每一頁重複出現。由於轉換器會保留頁面邊界，因此這些重複內容會保留下來，而不會被自動去除。
- 表單與註解。當欄位值位於文字圖層中時會被讀取，但隱形的註解、註解和 widget 不會被解讀為獨立的內容。
在依賴結果之前，務必將其與來源 PDF 進行比對——特別是合約、科學記號、財務表格，以及多欄的參考資料。
轉換器所強制執行的限制及其意義
由於解析與組裝都在你的瀏覽器分頁中執行，轉換器會強制實施一組硬性限制，以保持頁面的回應速度，並防止悄悄產生不完整的檔案。
| 限制 | 設定值 | 為何重要 |
|---|---|---|
| 最大檔案大小 | 每個 PDF 25 MiB | 讓瀏覽器分頁中的記憶體用量受到限制。 |
| 最大頁數 | 每份文件 40 頁 | 避免非常長的書籍讓 UI 凍結。 |
| 每頁的文字項目數 | 每頁有上限 | 防止項目數爆量的病態 PDF 造成問題。 |
| 總文字項目數 | 整份文件有上限 | 對整份檔案施加同樣的保護。 |
| 單一項目的長度 | 每個項目有上限 | 避免單一格式錯誤的項目佔用過多記憶體。 |
| 輸出字元總數 | 整份結果有上限 | 保證預覽與下載不會超出分頁資源。 |
當文件超過這些門檻中的任何一個時，轉換器會回傳明確的錯誤，而不是被截斷的檔案。PDF.js 也會針對加密、格式錯誤或損壞的 PDF 回報失敗，且此工具不會嘗試繞過密碼、修復結構或驗證數位簽章。如果你需要先移除密碼，必須在另一個具備密碼處理能力的步驟中完成。
內部的安全機制會在工作被取代、取消，或元件卸載時釋放載入任務、串流讀取器、頁面資源和暫存的下載 URL。原始的 PDF 永遠不會被修改。
當你的 PDF 沒有文字圖層時該怎麼辦
如果你的文件是乾淨的掃描件，沒有可選取的文字，那麼任何文字圖層擷取工具都無法憑空為你產生逐字稿。頁面影像中只有像素，沒有字元，擷取工具只會回傳一份近乎空白的檔案。
在這種情況下，你需要一個能分析影像並產生字元碼的 OCR 工作流程，然後理想上把這些字元碼重新嵌入 PDF 中作為新的文字圖層。一旦 OCR 產生了一份含有文字層的 PDF，再將它送回轉換器，你就能得到一份可搜尋的 UTF-8 文字檔，與原檔並存。對於視覺呈現比文字擷取更重要的文件——例如你只需要檢視而無須搜尋的版面——將每個 PDF 頁面渲染為 JPG 或 PNG 的頁面影像工具可能更為合適。
要記住的核心原則很簡單：可搜尋性始於文字圖層。PDF to Text Converter 會在文字圖層存在時讀取它、在不存在時清楚地失敗，並且絕不會假裝一份文件是可搜尋的——如果它實際上並非如此。
若想更深入了解，請參閱 TXT to PDF：將純文字轉換為乾淨的 PDF 文件。
若想更深入了解，請參閱 在不上傳檔案的情況下從 PDF 擷取文字。