IronPDF EAP 不会将 C# 字符串解释为 UTF-16答案

【问题标题】：IronPDF EAP doesn't interpret C# string as UTF-16IronPDF EAP 不会将 C# 字符串解释为 UTF-16
【发布时间】：2021-08-02 15:54:36
【问题描述】：

我正在尝试使用 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 中是否有我忽略的新设置/选项？或者这是一个在发布前会解决的已知问题？

【问题讨论】：

请您分享用于呈现文本的确切代码吗？您也可以直接通过ironpdf.com 或发送电子邮件给开发人员@ironsoftware 获得支持 - IronSoftware 很乐意为任何考虑使用该库的人提供支持
@darren：我已经向developers@ironsoftware.com 发送了一封电子邮件，地址中有您的姓名；附上演示该问题的最小 VS 解决方案。我怀疑该问题仅在 IronPDF 处理的 HTML 中（足够）“普通”（非 CJK）文本位于 CJK 文本之前时才会出现。
我已经在GitHub 上放置了一个可以演示问题的有效测试解决方案。
经过进一步调查，我们发现我们的 Chrome 渲染器在 html 字符串长度超过最大无符号短 (65535) 后失败，感谢您提请我们注意，这将在即将到来的IronPdf 的发布。
1.提供的 HTML 示例似乎无法在常规 Chrome 浏览器中正确呈现，因为 Chrome 编码自动检测似乎因 html 字符串很长而失败。 2. 我们建议在任何包含 utf-16 字符的 HTML 文件的开头包含 <meta charset="utf-16"/>。这是一个合理的要求，因为最终很难确定所需的解码。 3. 不过，话虽如此，我们正在审查在未指定其他编码的情况下自动默认为 utf-16 编码的可能性，以帮助缓解此类问题。

标签： c# pdf ironpdf

【解决方案1】：

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

建议包括：

<meta charset="utf-16"/>

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

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

【讨论】：

如果在 65,535 字节之前没有找到 utf 字符.... Chrome 采用 Ascii 编码，除非或是根据需要使用。
最后，我们坚持在字符串的开头插入一个字节顺序标记 (\uFEFF) 与。除了后者的意图更明显之外，以这种方式使用 BOM 是否有任何缺点？

【解决方案2】：

看起来像一个可靠的错误报告。我通过电子邮件与 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 上并试图帮助甚至是无偿用户

【讨论】：