讓人們對轉換文件感到驚訝的是，文件中沒有要轉換的頁面。 .docx 包含有關紙張大小的段落、樣式和註釋，您在螢幕上看到的頁面是透過開啟它的文字進行的文字操作。 任何其他程式都必須再次執行此佈局，具有自己的字體和自己的換行符，這就是為什麼兩個轉換器從一個檔案中給出兩個不同的頁面計數的原因。 了解這一事實解釋了輸出中的每一個驚喜，包括您認為已消失的追蹤刪除出現在 PDF 中的一個。
TL;DR: .docx 是帶有真實結構的 XML 的 zip，因此標題、段落和列表正確到達而不是被推斷。 沒有到達的是外觀：字體、列、表格、標籤站、編號和精確間隔在部分轉換器必須實作文字處理器才能榮譽。 根據真實輸入測量，追蹤刪除被刪除，因此編輯後的文件讀取作為其最終措辭，編號列表返回項目符號，表格變成其單元格，按閱讀順序，選項卡變成空格。 西歐文本渲染；西里爾字母、希臘語、CJK 和 Emoji 沒有，因為內建的 PDF 字體是 Winansi。 那個 Word 到 PDF 轉換器 在瀏覽器中進行排版。
.docx 裡面是什麼？
XML 零件的 Zip 中，其中一個包含此處的所有重要內容。
使用存檔工具開啟任何 .docx，您會發現 word/document.xml 與清單、關係部分以及通常的樣式、字體、主題、編號定義和設定一起。 格式是 ECMA-376，有微軟自己的 實施說明 涵蓋了單字在它上面的作用。
文件部分是序列 <w:p> 元素。 每個都是一個段落，可選屬性說明它使用哪種樣式以及是否屬於列表，並在其中包含一系列承載實際文字的運行 <w:t>.
這真的比 PDF 提供的更好。 在 PDF 中，必須從線條之間的垂直間隙推斷出段落，這就是 另一個方向的轉換 丟失列和表格。 這裡的段落是段落，因為文件是這樣，標題是標題，因為段落命名了一個標題樣式。
扣環在轉換器不讀取的部分。
為什麼結果看起來不像 Word 中的表現？
因為外觀分佈在文字處理器的部分，而轉換器則重新排版文字。
文字在文件部分。 您的文字以 1.08 行間距以 1.08 的 11 點出現在卡利布里 styles.xml。 您的清單中的內容為「1.、2.、3.」而不是「A.、B.、C.」在 numbering.xml。 提供標題顏色的主題再次出現在另一部分，部分屬性控制每個部分的邊距、列和頁面大小。
尊重這一切，正在用 Word 的語義建構一個佈局引擎。 取而代之的是閱讀結構並將其佈置乾淨：時間羅馬的正文，Times Roman 粗體，標題為 56 點，1.4 行間距，在您選擇的頁面大小中。
所以輸出是一個可讀的、正確排序的文件，看起來不像原版。 這是一個真正的限制，值得明確說明而不是埋葬，因為尋找這種皈依的人分成兩組，只有一組被服務。 如果您希望任何人都可以打開的 PDF 文字，這是正確的。 如果你想要 那個頁面，以其字體和間距，請繼續閱讀 Word 自身出口部分。
什麼能在轉換中倖存下來？
結構和閱讀順序，可靠。 這是完整列表，根據代碼而不是假設來衡量。
| 元素 | 結果 |
|---|---|
| 段落 | 保存，按文件順序 |
| 標題 | 保存，按等級大小，設定粗體 |
| 列出項目 | 文字保留，標記被子彈取代 |
| 台單元 | 以閱讀順序保存為單獨的段落 |
| 追蹤刪除 | 掉落，因為單字顯示它們 |
| 標籤和換行符 | 成為一個單一的空間 |
| 粗體、斜體、顏色、字體 | 不攜帶 |
| 圖片 | 不攜帶 |
| 頁首、頁尾、頁碼 | 不攜帶 |
| 註腳和尾註 | 不攜帶 |
這張表的上半部是為什麼這種轉換仍然值得做：其中沒有什麼是必須猜測的。 下半部是不實作 Word 的價格。
追蹤的更改會發生什麼事？
刪除消失了，這是正確的，它需要說的事實是有趣的部分。
帶有變更追蹤的文件編輯將刪除的文字保留在文件中，內部 <w:delText> 在一個 <w:del> 元素。 Word 知道不要將其顯示為當前文字。 走每個文字節點的轉換器不會，除非有人考慮過。
在最初閱讀的段落中測量的“截止日期是 3 月 31 日”，並編輯為“4 月 30 日”：
with the rule: The deadline is 30 April.
without the rule: The deadline is 31 March30 April.
任何人曾經打過的那個句子的每個版本，一起跑，他們之間沒有空間。 在合約或錄取通知中，這不是一個化妝品錯誤：它將文件的談判歷史發佈給收到 PDF 的人。
值得了解的是，無論您使用什麼工具。 如果您向外發送已轉換的文件，請檢查您更改的日期或數字是否出現一次而不是兩次。
編號列表會發生什麼？
它被子彈回了，因為數字不在段落中。
列表段落攜帶 <w:numPr>，它指向另一部分的編號定義。 此定義包含格式、起始值、縮排層級，以及此列表是否繼續上一頁。 段落本身包含文字，沒有其他內容。
因此，只讀取文件部分的轉換器知道該段落是列表項目，而不是它應該攜帶什麼標記。 渲染子彈是誠實的預設：
• First point
• Second point
Ordinary paragraph
當數字具有意義時，這一點很重要。 「請參閱步驟 4」在程序中，或在協議中的編號條款中，失去其引用。 如果您的文件取決於其編號，則此轉換是錯誤的，而 Word 自己的匯出是正確的。
桌子怎麼了？
細胞存活，網格沒有。
一個表格單元格包含 <w:p> 元素和其他任何事物一樣，因此文字以閱讀順序以普通段落的形式出現。 區域和數字的兩列表顯示為：
Region | Q2 | EMEA | 412
四個段落，一個接一個，沒有記錄前兩段是標題行。 將表格帶過意味著承載列寬、行結構、合併單元和邊框，然後佈置一個分頁的網格，這是一個不同的、更大的工具。
這在兩個方向上都是一樣的交易。 PDF 到 Word 壓平了一張表，因為 PDF 從來沒有一個；Word to PDF 將其壓平，因為重建一個是佈局引擎。 兩種情況的誠實建議：如果表格是重點，請截圖或保留原始內容。
為什麼我的選項卡對齊佈局會崩潰？
因為選項卡是位置指令，沒有標籤停止，所以無處可發送。
<w:tab/> 意味著「前進到下一個標籤停止」，並且停止在段落屬性中定義或繼承自其風格。 一個以自己的邊距佈置文字的轉換器沒有有意義的停止跳躍，因此選項卡變成一個單一的空間。 也是如此 <w:br/>:
input: Name <tab> Value <br> Next line
output: "Name Value Next line"
任何建立兩列清單、簽名區塊或帶有標籤的簡單目錄的人都會完全失去對齊方式。 這是轉換文件看起來錯誤的更常見的方式之一，並且在來源中是不可見的：該文件看起來像普通段落，因為它就是這樣。
如果對齊很重要，原始文件中的真實表格不會更好，但至少會失敗得更明顯。
內建的 PDF 字體無法呈現哪些字元？
西歐拉丁以外的任何事物，以及過去對哪個角色有過錯的失敗。
PDF 標準定義了每個讀者都有 14 個基本字體，它們使用 WinansienCoding 進行編碼，這是一套 256 個字元的集合，記錄在附件 D 中 PDF 規範。 使用它們意味著不需要嵌入字體，這使輸出保持小，這意味著字母是固定的。
用 pdf-lib, 圖書館進行繪圖：
| 文字 | 結果 |
|---|---|
Quarterly report |
渲 |
"Revenue" rose, he'd said 有捲曲的行情 |
渲 |
| 使用 em dashes 的句子，u+2014 | 渲 |
Chiffre d'affaires réalisé en Août |
渲 |
Total: €1,249.50 |
渲 |
Отчёт за квартал |
失敗： WinAnsi cannot encode "О" (0x041e) |
Αποτελέσματα |
失敗： WinAnsi cannot encode "Α" (0x0391) |
季度报告 |
失敗： WinAnsi cannot encode "季" (0x5b63) |
四半期報告 |
失敗： WinAnsi cannot encode "四" (0x56db) |
Revenue up 🚀 |
失敗： WinAnsi cannot encode "🚀" (0x1f680) |
法語、德語、西班牙語、葡萄牙語、義大利語和北歐語都很好，歐元標誌、捲曲報價和 em dash 也很好。 俄語、希臘文、中國人、日文、韓文、阿拉伯語、希伯來語、印地語和每個表情符號都不是。
該工具現在在錯誤中命名字元，而不是說文件無法轉換，因為“刪除此字元”是建議，並且“出了問題”不是。 其中一個腳本中的文件需要一個轉換器，它嵌入了字體，這意味著更大的 PDF 和不同的工具。
為什麼 .doc 檔案被拒絕？
因為 .doc 和 .docx 是共享三個字母的不同格式。
.docx 是 XML 的 zip，於 2007 年推出。 .doc 是一個複合二進位檔案，其佈局可以追溯到九十年代初，文字在解析器必須行走的結構之間交錯。 閱讀一個不是閱讀另一個的變體；它是一個單獨的實現。
所以轉換器檢查擴充並這麼說，而不是在無法讀取的 zip 上故障：
| 文件 | 它說什麼？ |
|---|---|
.doc |
那是舊格式。 打開它並先另存為 .docx |
.rtf, .odt, .pages |
不是 Word 文件。 匯出為 .docx |
.pdf |
已經是 PDF；使用另一個方向來處理可編輯的文件 |
在 Word、LibreOffice 或 Google Docs 中開啟 .doc 並將其另存為 .docx 需要幾秒鐘，並且是這些程式做得很好的轉換。
標題的大小如何，它們的深度如何？
按等級，粗體，超過第三層的一切都被視為第三層。
樣式名稱從段落中讀取並標準化，因為兩種拼字都存在於野外。 文字寫 Heading1; 幾個文檔產生器寫入 heading 1。 兩者都解決到同一水平，並且 Title 被視為一級。
| 文件中的樣式 | 使用的水平 |
|---|---|
Title, Heading1, heading 1 |
1 |
Heading2 |
2 |
Heading3 |
3 |
Heading4 通過 Heading9 |
3 |
ListParagraph, BodyText，其他的 |
正文 |
三個視覺層面是故意的停止點。 與第三層區分開來的第四層要么需要另一個大小的步驟，它開始與正文碰撞，要么是重量或樣式改變基本字體不提供的。
PDF 將有多少頁？
不是顯示你的數字，差別不是錯誤。
換行取決於字體，因此 12 點的時代羅馬中的同一段落佔據的行數與 11 的卡利布里不同。 利潤不同。 行距不同。 決定線結束位置的一切都改變了，因此分頁會隨之改變。
在一次測量的運行中，一個標題為 1 個標題和大約 40 個單字的 10 個段落的文件分別為兩頁 A4 頁：第 39 行在第二頁，第 2 行，標題為 20.4 點粗體，而 12 點正文。
實際結果是頁面引用中斷。 「如第 7 頁所述」在轉換後的文件中，現在可以是第 6 頁或第 8 頁。 交叉引用自身頁面的文件應從 Word 匯出，其中的佈局是引用的參考。
什麼時候應該改用 Word 自己的出口？
每當出現或分頁是內容的一部分。 這是一個比聽起來更短的清單，但它上的項目很重要。
| 使用文字導出 | 使用轉換器 |
|---|---|
| 設計文件：信箋、簡歷、帶品牌的報告 | 您需要的純文字文件作為 PDF |
| 任何有表格、圖像、頁首或頁尾的東西 | 筆記、文章、草稿、成績單 |
| 編號條款或交叉引用頁面 | 您只需要閱讀訂單的任何文件 |
| 非拉丁文腳本中的文件 | 您不想在任何地方上傳的文件 |
Word's 檔案，另存為，PDF 是真正的匯出：繪製頁面的相同佈局引擎寫入 PDF，所以你所看到的就是你得到的。 瀏覽器中沒有什麼能比得上，因為瀏覽器中沒有 Word 的佈局引擎。
完全轉換的案例是該表的最後一行，而且沒有手頭。
為什麼它在瀏覽器中運行？
因為文件是人們轉換的最個人化的文件，而這種轉換不需要伺服器。
閱讀 zip、解析 xml 和繪製文字都是瀏覽器本機所做的所有事情。 文件從您的磁碟讀入標籤，在那裡解壓縮，在那裡放置，寫成 PDF 在那裡，然後作為下載交回。 沒有請求攜帶文件，也沒有留下任何副本。
有問題的文件是合約、履歷、醫療信函、法律草案和論文。 傳統的替代方案將它們上傳到服務，將它們轉換為您一無所知的機器，並將它們保留在無人閱讀的政策中一段時間。
限制是誠實的：僅限西歐文本，沒有圖像，除了標題和項目符號之外沒有格式。 它們在您開始之前而不是之後被發現，這是值得採取的交易，當替代方案是您不再控制的文件的更好看的 PDF 時。
