XML 源自 SGML：為什麼它有屬性、命名空間和 DTD

為什麼這個資料格式有屬性？ — 開發人員將 XML 轉換為 JSON 並滿足從未需要的差異 JSON

JSON 有一個物件屬性； XML 區分屬性、子元素和文字。 ToolAcre 將這種差異對應到 `@` 屬性和普通子鍵。當元素同時具有 `id="7"` 和 `<id>` 子元素時，差異是可見的：兩者都在不同的屬性下生存。

此約定解釋了結果形狀，但沒有宣告屬性具有一個通用語意角色。 XML 作者根據自己的模式選擇它們。轉換器保留它可以觀察的節點類別，而不是選擇它的業務原因。

SGML 和檔案傳統 — ISO 8879、發布標記以及標記文字而不是編碼記錄的想法

混合內容、有序子項、屬性、註解和處理指令是 XML 來源中存在的面向檔案的功能。該實現展示了它們的處理方式，但不包含 SGML 年表、ISO 出版歷史或出版業動機的證據。

因此，受原始碼限制的文章從可執行行為開始。子元素周圍的文字是有損的；評論和處理指示被刪除； CDATA 保持標記。這些事實解釋了為什麼檔案樹不能完全適合 JSON 值樹。

以檔案為導向的 XML 功能在實作中可見，沒有 SGML 歷史宣告

解析器驗證格式正確的 XML 並報告行和列。它忽略結果值中的宣告，並將五個內建實體和數字字元參考保留為解碼文字。它沒有建立工作組目標或十原則設計帳戶。

歷史主張需要外部編輯來源，此任務不會新增這些來源。省略它們比從依賴項名稱發明合規性或出處更準確。

解析器處理 XML 語法；儲存庫證據未建立 1998 設計歷史

屬性成為前綴為 `@` 的鍵；元素保留其名稱。結構化元素內的文字移動到 `#text`，而純文字元素則折疊為字串。這使得結構類別在物件模型允許的範圍內保持分離。

寫入 XML 會顛倒約定：`@id` 成為屬性。無效的屬性或元素名稱將被拒絕而不是清理。這項決定可以防止格式錯誤的對應變成帶有悄悄更改名稱的看似合理的 XML 。

在 ToolAcre 的 @ 約定下，屬性和元素保持不同

命名空間前綴在元素和屬性名稱中逐字保留，包括命名空間宣告。它們沒有被解決、刪除或重寫。這保留了來源拼寫，但不是命名空間感知的類型解析。

在 fast-xml-parser 接收檔案之前，每個 DOCTYPE 都會被拒絕。此遮罩可避免註解和 CDATA 內的錯誤相符。這可以防止外部實體請求、本機檔案實體讀取和實體擴充攻擊，並無法繞過拒絕。

命名空間前綴按字面意思保留，並拒絕每個 DOCTYPE

在 `<p>before<b>bold</b>after</p>` 中，文字放置很重要。 ToolAcre 偵測混合內容，將片段連接到 `#text` 下，並警告它們相對於子項目的位置遺失。 JSON 物件屬性無法重現交替文字和元素節點的有序序列。

重複的同名子級成為數組，但不同名稱的兄弟級仍然是屬性。需要精確文件順序的程式碼應使用 XML 節點表示形式，而不是將轉換後的物件視為完整的。

這不包括什麼 — XSLT、XPath 和 XQuery，這些圍繞 XML 發展的處理語言

XSLT、XPath 和 XQuery 不會匯入或公開。此面板也不驗證 XSD、處理 DTD 宣告或建構類型化網域物件。它是具有明確安全性和保真度邊界的資料投影。

查詢或轉換語言可以以純值轉換無法做到的方式保留和導航節點順序。當檔案功能是工作的一部分而不是附帶的打包時，請選擇該工具。

重點：XML 是一種學會攜帶資料的檔案格式 - 以及語法轉換器面板如何顯示翻譯成 JSON 後倖存下來的內容

XML 的可觀察資料模型包含 JSON 所沒有的差異。 ToolAcre 標記屬性、CDATA 和結構化文字，保留命名空間前綴，刪除非資料節點並拒絕 DOCTYPE。每個選擇都是可見且經過測試的。

使用面板來了解投影後的內容，而不是作為歷史權威或完整的 XML 處理器。當排序、架構或命名空間語意很重要時，請保留原始樹並使用專用的 XML 工具。

安全性和保真度也在 DOCTYPE 邊界處交叉。拒絕宣告會阻止實體處理，但從任意遺留檔案中刪除它可能會更改實體引用或驗證假設。如果您擁有原始程式碼，請使用明確安全文字取代所需的實體並驗證產生的檔案。如果您不擁有它，請使用已批准的 XML 工作流程，而不是削弱拒絕或將部分轉換呈現為原始內容。