1

我正在尝试使用 IronPDF EAP 2021.6.3135 将一些 HTML 转换为 PDF 文档。创建新的 ChromePdfRenderer 后，我在其上调用 RenderHtmlAsPdfAsync，将 HTML 字符串作为唯一参数传递。HTML 是一个<div>带有多个嵌套<div>的 s，其中一个包含 CJK 文本。IronPDF 似乎将该文本解释为 ASCII 或 UTF-8；在任何情况下，它都将其视为无稽之谈。这可以在 IronPDF (2021.3.1) 的当前版本中正常工作（无需下面提到的解决方法）。

在字符串的开头插入字节顺序标记 ( \uFEFF) 可以解决问题，但我不需要这样做。EAP 分支的 API 中是否有我忽略的新设置/选项？或者这是一个在发布前会得到解决的已知问题？

4

2 回答 2

0

看起来像一个可靠的错误报告。我通过电子邮件与 Iron Software 的 Darren 和 JD 进行了交谈，他们报告说将在发布前修复。

我怀疑这是使用旧式 HtmlToPdf 类的问题

我尝试了 ChromePdfRenderer 类，但渲染 UTF-16 字符串没有问题：（在这里找到https://ironpdf.com/object-reference/eap/api/）

ChromePdfRenderer Renderer = new IronPdf.ChromePdfRenderer();
var doc = Renderer.RenderHtmlAsPdf("سلام دنیا");
doc.SaveAs("test.pdf");

EAP 软件的字面意思是 - “它并不完美 - 请报告错误，以便我们在发布前修复它们”......所以感谢 Rich 作为 EAP 用户。

他们在developers@ironsoftware.com 上，并试图帮助甚至无偿用户

于 2021-08-03T06:08:33.030 回答
0

Chrome 编码自动检测因 html 字符串过长而失败。

建议包括：

<meta charset="utf-16"/>

在任何包含 utf-16 字符的 HTML 文件的开头。（这是一个合理的要求，因为最终很难确定所需的解码）。

Iron Software 正在审查IronPDF在未指定其他编码的情况下自动默认为 utf-16 编码的可能性，以帮助缓解此类问题。

于 2021-08-25T04:25:39.350 回答