把 PDF 导出成 JSON / Markdown：需要哪几层接口
先说清楚一件事：SDK 里没有现成的「导出为 JSON / Markdown」接口。 但它提供了搭一个导出器需要的全部原语——而这几个原语，恰好把「PDF 里本来不存在结构」这件事补上了。
分水岭是段落识别
- 文本层（
ipdf_pagetext）给你字符和它们的坐标。 - 段落层（
ipdf_paragraph）把字符还原成段落——告诉你「这是一段」、它的边界在哪。
差别很大：只有文本层，导出结果是一长串字符流，Markdown 连分段都做不到；有了段落层，才有「标题、正文、列表项」这些可以落成 Markdown 的单元。
导出器要拼的四层
- 段落文本：
IPDF_Paragraph的GetText/GetText_UTF8—— 出 JSON 或 Markdown 用 UTF-8 这个。 - 逐字的样式：按字符位置读
GetFont、GetFontSize、GetFontColor、GetCharSpace、GetCharUnicode、GetCharsetAt。 - 字体本身的数据：字体家族、字重、字符集与字体标志定义在
ipdf_base；IPDF_Matrix也在那里，做坐标变换用。 - 图片与页面元素：
ipdf_pageobject能枚举图像、文字、路径对象。
（上面这些类名与方法名都可以在接口文档里逐一核对：段落见 ipdf_paragraph，字体与基础结构见 ipdf_base。）
⚠️ 属性是按「字符位置」（caret）读的——所以字号、颜色、字距可以精确到字。这也是「改完和原文一致」与「导出时保留样式」共用的同一套信息。
版面信息别丢
三个容易被忽略、但对导出质量影响很大的接口：
GetBBox：段落在页面上的范围。判断阅读顺序要靠它——分栏排版按坐标排序会读乱。IsRotate：这一页/这一段是旋转的，导出时坐标要换回去。IsVerticalWrittingMode：竖排文档。竖排的段落拼进 Markdown 会完全错乱，需要单独处理。
一个 JSON 大致长什么样
具体的结构由你的应用决定——SDK 不会替你定 schema。作为参考，一个够用的形状大致是：文档 → 页 → 段落 → （文本、字号、字重、颜色、边界框、图片引用）。图片建议导出成独立文件、JSON 里只留引用，而不是塞 base64——否则文件会膨胀得很快。
导出成 Markdown 的难点在哪
- 标题 vs 正文：靠字号与字重推断（字号明显大于正文、且字重更粗 ⇒ 标题）。
- 列表与表格：需要根据 BBox 与缩进自己判断。这一层没有捷径，做得准不准，取决于你愿意在版面上花多少工夫。
- 样式能保留到什么程度：粗体、斜体这类由字体数据决定，能判断出来；而「这一段为什么加粗」这类语义，PDF 里本来就不存在。
一条硬边界
扫描件导不出结构。 扫描件里只有图像，没有文字层——文本接口读不到东西，段落层更无从谈起。这类文档要先做 OCR 生成文字层，那是另一条链路。
常见问题
为什么不做成 SDK 内置接口？
因为导出的目标结构因业务而异（有的要 JSON、有的要 Markdown、有的要喂给检索系统）。SDK 给可复用的原语，schema 由你的业务定——这样才不会被我们的格式绑住。
导出会丢东西吗？
文字与属性是完整的；版面的语义（这是不是表格、这算不算标题）需要推断，会有误差。建议用你自己的文档先跑一批样本评估。
图片能一起导出吗？
页面对象层能访问图像元素，导出为独立文件即可，见图片与图形那篇。
有现成示例代码吗？
接口文档里每个方法都有签名与说明（保留头文件英文原文），见 SDK API 参考；具体示例可在申请试用后的接入文档里与我们确认。
来源：知叶PDF 官方文档。能力范围以 SDK 接口文档为准，更新于 2026 年 9 月。