Crystal 报告导出到 Word 时连字符编码不正确

Crystal Reports Improperly Encoding Hyphens On Export to Word

我在生成 word 文档时遇到问题(来自 crystal 报告引擎,通过 C#.net 应用程序)。最初连字符是可见的,但如果使用 "keep text only" 选项或 "remove formatting option" 复制和粘贴文本,连字符字符将变为空白 space" ".

我很确定这是字符编码的问题,可能它被编码为软连字符。有什么方法可以通过 crystal 报告引擎解决这个问题。

我已经检查并确认源文本是数据库中的实际连字符。

Unicode 中常见的 Ascii 连字符 U+002D HYPHEN-MINUS 似乎已转换为在 Word 中被视为不间断连字符的代码。一条评论说,在 Word 的“全部显示”模式下,它看起来像一个连字符,但更长。这意味着它看起来像一个破折号“–”。在内部,它是字节 1E 的十六进制,所以我们可以说它是控制字符 U+001E。但它不受使用AltX的影响。如果您复制包含它的文本并将其作为纯文本粘贴,它会被替换为 U+0020 SPACE,因此它实际上被视为特殊代码而不是字符。

它与 Unicode 中的 NON-BREAKING HYPHEN U+2011 完全相同;相反,它是 Microsoft 自己的想法,用于处理您希望出现连字符但不希望 Word 在连字符后将字符串分成两行的情况(例如,在字符串“F-1”中,这样​​的中断看起来很可笑)。

因此您可以尝试找出这种情况在报表引擎中是如何发生的并加以预防。但它可能比将“-”替换为 bye 1E 更复杂。

如果你需要在Word中处理这个问题,你可以使用查找和替换,其中特殊字符菜单包含“不间断连字符”。您可以将其替换为常见的连字符“-”,从而失去不可破坏性。

您也可以将其替换为不间断连字符 U+2011,这样可以保留 属性。但是,如果转移到其他程序或由于字体问题(并非所有字体都包含该字符),这可能会导致问题。字体问题可能很棘手:Word 会在需要时自动切换到另一种字体并且不会对此进行通知,因此您的文本可能包含不同字体的字符,这可能会导致多种问题(例如行间距不均匀)。此外,当 U+2011 出现时,它可能看起来与常见的 Ascii 连字符不同;它或多或少应该。在排版上,如果您使用 U+2011,您的正常(中断)连字符应该是 U+2010 HYPHEN。