我將兩頁報告轉換為 Word 以檢查某事，第二段回來如下：
第三次員工人數增加四人，在兩家支持的四分之一支持下。 招聘大幅更新簽署了八月第四季的計劃。 保證金持平。 在六個角色上沒有變化。
兩列完全普通的散文，一行一行地讀過排水溝，所以每句話都拼接到旁邊的一句話。 什麼都沒有壞。 轉換器完全按照轉換器可以做的事情，而這與短語“pdf to word”的承諾是本指南的全部主題。 下面引用的每個輸出都來自運行轉換，而不是描述它。
TL;DR: PDF 儲存座標的字形。 它不儲存段落、列、表格或標題，因此轉換器必須從位置推斷它們，其中一些推論以您可以預測的方式是錯誤的。 在測試報告上測量：兩列逐行交錯，四行表格平整到一行讀數“地區 Q3 EMEA 412 455 AMER 388 401 APAC 120 166”，一個標題合併到它下面的段落，一個沒有文字圖層的頁面根本沒有產生任何內容。 您可靠地得到的是可編輯的頁面順序，對於大多數工作來說，這就是您想要的。 那個 PDF 到單字轉換器 在瀏覽器中執行，因此文件不會上傳。
PDF 中儲存了什麼？
繪製頁面的說明，而不是文件。
PDF 的內容流顯示諸如“將此字體設為此大小，移動到 x 60，y 720，顯示這些字形”。 那個 規範本身 是繪畫模型的描述，文字運算子坐在畫線和填充形狀的旁邊。 文件中沒有一個物件意味著「段落」，沒有一個物件意味著「這是一個表格」，也沒有記錄兩個文字區塊是列而不是一個寬的物件。 該格式的設計使頁面在各處都相同地列印，並且透過將頁面描述為標記而不是內容來實現這一目標。
所以轉換器會接收定位運行的清單。 pdf。js，這個解析器運行，就像頁面繪製它們一樣將它們完全交還給它們。 在測試檔案中，第一頁產生了其中的 34 個，第 2 頁產生了 4 個。 每次運行都是帶有 x、y、寬度和字體高度的字串，它們到達的順序是繪製頁面的順序，這不一定是您閱讀它們的順序。
word 文件所需的一切 PDF 沒有，轉換器必須從這四個數字重建。 這種重建是接下來的全部，包括出錯的地方。
轉換器如何從座標重建段落？
在兩次通過中，每個都有一個閾值。
第一個通過組按基線運行：運行其 y 值在彼此的半個字體高度內的運行是一行。 第二個將它們之間的垂直間隙分成段落。 大於通常行間距約 1.45 倍的間隙開始一個新的段落，其中「通常」是該頁面上的中位數間隙，而不是固定的數字，因此該規則適應了以 9 點或 14 點設定的文件。
一行內有第三個閾值。 PDF.js 經常在幾次運行中分割一個單字，它們之間沒有間隙，因此在空間上運行“檔案名稱”進入“f i l e n a m e”。 修復方法是僅當水平間隙超過字體高度的四分之一時插入一個空間，大約是真實單字空間的寬度。
這三個數字幾乎決定了輸出的一切。 當結果好時，他們是對的。 當標題貼在其下方的段落時，間隙低於中位數和規則所述一段的 1.45 倍。
為什麼兩列交錯？
因為列的唯一證據是水平間隙，而線分組首先看垂直位置。
我的測試頁面中的兩個區塊位於 x 60 和 x 320，它們的行在共享基準上。 分組看到六個基線，每個基線都從兩邊傳來文字，並閱讀每個基線。 結果是本指南頂部的段落：左列的每一行都緊接著旁邊的行。
這與 OCR 中的 Scrambled Columns 相同，它具有相同的根：閱讀順序是對由幾何圖形製成的佈局的判斷，由無法閱讀的內容組成。
處理列的轉換器首先執行頁面分割步驟，尋找一個一致的垂直空白帶，運行頁面高度並在任何行分組之前將頁面拆分。 這適用於報紙或期刊報紙，那裡的排水溝寬且規律。 在常見的情況下，它不太可靠，其中側邊欄、拉引報或兩列表格會破壞頻段。
如果您的文件有列，實際答案是檢查輸出並修復每個頁面的第一段，或在文件足夠長以值得的情況下一次轉換一列。
桌子怎麼了？
它變成了一個句子。
我的測試檔案有一個四行表格，有三列。 這是轉換後的全部內容：
Region Q2 Q3 EMEA 412 455 AMER 388 401 APAC 120 166
每一個價值都存活下來。 結構沒有。 你無法從那條線中看出 412 是 EMEA 的 Q2 數字，而不計算位置和了解原始的形狀。
原因是大多數 PDF 也不包含表格。 PDF 中的表格通常是在座標上繪製的文字，周圍繪製了一些線條，而這些行是圖形操作，在文件中沒有任何內容將它們連接到它們所附帶的文字。 轉換器必須檢測數字的對齊方式，推斷網格，並決定哪個單元屬於哪個單元格，這是一個研究問題，而不是解析問題。
有些 PDF 確實具有真實的結構，透過添加的標籤以可訪問性，並且轉換得更好。 他們是少數：標記的 PDF 來自仔細的文字或 InDesign 輸出，而不是來自印刷驅動程式。
如果表格是您想要的東西，請手動將其複製到電子表格中，或將 PDF 轉換為文字並在那裡重塑。 轉換後的 Word 檔案不會給你儲存格。
為什麼我的標題合併到段落？
因為它下面的空間不足以絆倒段落規則。
在測試檔案的第二頁，標題「註」比正文高出 40 分，而身體線相距 18 分。 這個間隙是行間距的 2.2 倍，這應該是分割的，但事實並非如此，因為只有四次運行的頁面上的中位數間隙並不是對任何事情的可靠估計。 輸出是：
Notes Note 14 covers intercompany revenue and the treatment of
deferred items carried over from the prior year.
這是整個問題的誠實形式。 閾值規則在具有足夠文字以建立基線節奏的頁面上運作良好，而在稀疏節律上運作良好。 扉頁、簡短的註釋、封面或表格通常會作為一個連續的段落回來。
這也是事後解決的最容易解決的問題。 標題對人類讀者來說是顯而易見的，在正確的位置按下返回需要一秒鐘，這比任何工具都要花更少的時間來正確處理它。
掃描頁面會發生什麼事？
什麼都沒有出來，這是正確的行為。
我的測試檔案的第三頁根本沒有文字圖層，只有一個灰色的矩形站在上面進行掃描。 PDF.js 傳回零運行，轉換器為它產生零段落。
該頁面仍然計數。 它在 Word 文件中顯示為空白頁面，因此頁面在與原始頁面保持一致後中斷，當有人使用頁碼工作時，這很重要。 一個默默掉落的轉換器會每晚一頁移動一頁。
頁面都是所有圖像的 PDF 是掃描的，沒有轉換器可以從中提取文字，因為沒有文字要提取。 這需要的是 OCR，它讀取字母的圖片並猜測字元，並帶來自己的錯誤率。 該交易的測量版本在 關於什麼打破 OCR 的指南: 傾斜超過三度是破壞掃描的原因，而不是解決問題。
一個有用的經驗法則：打開 PDF 並嘗試用游標選擇一個句子。 如果文字突出顯示，轉換器可以讀取它。 如果您在圖像上獲得選擇矩形，則首先需要 OCR。
.docx 裡面有什麼？
三個文件在一個 zip 中，這就是真正的全部。
.docx 是一個開放式包裝約定檔案，標準化為 ECMA-376: 包含 XML 部分的 zip 加上一個清單，說明每個部分是什麼。 微軟自己的 格式概述 走同樣的三個部分。 以 Word 文件開啟的最小值是三個條目：
| 部分 | 目的 |
|---|---|
[Content_Types].xml |
聲明包中每個部分的媒體類型 |
_rels/.rels |
主要文件部分的點 |
word/document.xml |
內容本身 |
單字檔案通常攜帶的其他所有內容，樣式、字體、主題、設定、編號定義，都是可選的。 將它們排除在外，讀者會應用其預設值。
測試文件，三頁 83 個字，到達一個 1,305 位元組 .docx word/document.xml 為 1,169 個位元組。 我用 Apple 自己的文件閱讀器打開它，這是 TextEdit 和 Pages 使用的，它按順序渲染每個段落，頁面完好無損。 最小的包裹不是退化的。
XML 中的一個細節比看起來更重要。 每次運行都用 xml:space="preserve"。 沒有它，以空間開始或結束的運行會失去它，而原始包裝中的每一行都以它的最後一個字連接到下一個。
圖像會發生什麼事？
它們被刪除，單字檔案沒有提到它。
這裡寫的包裹分為三個部分，但都不是媒體部分。 一個標誌、一個圖表、一個掃描的簽名、一個嵌入在報告中的截圖：一切都消失了，沒有佔位符的位置。 圍繞著他們的文字關閉了，就好像他們從未去過那裡一樣。
這是使輸出小而可靠的相同設計的結果。 攜帶圖像從 PDF 中提取它，決定其格式，將其寫入 word/media/，為它添加內容類型，添加關係部分，並在流程的右側點放置一個繪圖元素。 每個都是讀者拒絕文件的地方，而 .docx 一個文字處理器拒絕打開比缺少一個徽標更糟糕的是。
對於圖像是內容而不是裝飾的文件，最重要的是。 報告中的圖表轉換為無，Word 文件的讀者無法知道圖表曾經存在。 當散文中提到一個人物時，請在轉換旁邊檢查原件。
為什麼文件有時完全拒絕開啟？
XML 禁止和 PDF 包含的控制字元。
PDF 的文字圖層從產生的任何內容中挑選字元：從列印管道中提取 Form 的 Feed、來自損壞的編碼的 Null 位元組、文件中沒有任何意義的其他 C0 控制碼。 XML 1.0 不允許它們中的大多數，甚至逃脫：規範允許的字元範圍從 tab、newline 和回車返回並跳過 C0 塊的其餘部分。
失敗並不優雅。 Word 不會警告或刪除字元；它拒絕開啟檔案並說內容不可讀。 所以轉換器在寫作之前剝離了這些字元，而不是試圖逃避它們。 它們在來源中沒有任何意義，它們會花費您整個文件。
如果您收到文字處理器拒絕為不可讀的 .docx，這是第一個懷疑的事情，這就是為什麼轉換器手寫 XML 必須考慮它的原因。
您應該轉換為單字還是純文字？
word 如果你要編輯它，如果你要處理它，請發短信。
他們共享相同的提取。 區別只是最後寫的：一個將段落寫入 XML 的 Zip，另一個將它們寫入 .txt 檔案。
| 你想 | 使用 | 因為 |
|---|---|---|
| 編輯散文並發送 | pdf 到字 | 段落結構，分頁符號，同事可以打開的東西 |
| 搜尋、grep 或將其輸入到腳本 | pdf 到文字 | 路上沒有標記 |
| 完全保持佈局 | 兩者都不是 | 編輯 PDF，或取得原始檔案 |
| 閱讀掃描 | 先行 | 沒有要提取的文字圖層 |
第三排是值得坐的。 如果佈局很重要，那麼轉換為 Word 是錯誤的方向，因為轉換是佈局丟失的地方。 詢問向 PDF 發送它從中匯出的文件的人。 它需要一條訊息，這是唯一可以保持格式化的方法。
轉換需要多長時間？
足夠長的時間來閱讀文件，而不是現在。
沒有編碼步驟，也沒有影像處理。 工作是解析 PDF 結構，提取每個頁面的文字內容，分組運行，並將 XML 序列化為 zip。 測試檔案花了幾毫秒，這不是一個有用的數字，因為它是三頁。 一份 200 頁的報告以 PDF.js 解析為界，頁面數量大致呈線性化，而且速度很快。
您在大型文件上注意到的是記憶體，因為整個文件與解析的結構一起保存在瀏覽器標籤中。 那是這裡真正的天花板而不是速度。
您應該檢查輸出中的內容？
四件事，順序很可能是錯的。
- 每一頁的第一段。 這是列交錯和標題合併出現的地方。
- 任何桌子。 確認數字存在，然後接受網格消失，如果您需要，請重建它。
- 行尾的連字符單字。 PDF 中一行的一句話，中間的連字號又回來了。
- 頁數。 它應該與原始內容相符，包括任何空白或掃描的頁面。
該列表在十頁文件上需要一分鐘，這是您可以發送的文件和一個靜靜地包含拼接句子的文件之間的區別。
為什麼它在瀏覽器中運行？
因為人們轉換的文件是合約、報表、信件、醫療結果和禁運下的東西。
轉換是解析和 zip，瀏覽器都做得很好。 檔案從您的磁碟讀取到頁面，並在那裡解析為 Web 編譯，在記憶體中組裝成 .docx，然後作為下載傳回。 沒有請求攜帶文件，伺服器上沒有儲存任何內容，也沒有任何人可以刪除以後的任何內容。
通常的選擇是一個網站，它可以獲取您的 PDF，在您一無所知的機器上轉換它，並透過電子郵件向您發送連結。 對於公共傳單，這很好。 對於僱傭合約，這是您沒有被要求有意識地做出的決定。
成本是非常大檔案的標籤記憶體，掃描頁面沒有伺服器端 OCR。 兩者都是可見的限制，而不是安靜的限制，這是值得擁有的交易。
