“org.apache.commons.lang.StringEscapeUtils”和“破折号”

Question

我正在使用“*org.apache.commons.lang.StringEscapeUtils.unescapeHtml(myHtmlString)”将 Html 实体转义转换为包含与转义相对应的实际 Unicode 字符的字符串。但是它无法正确解析“em dash”和“en dash”符号。 StringEscapeUtils 将“–”替换为“\u0096”，而正确的错误位置是“\u2013”​​。正如我所读到的，“\u0096”相当于 cp1252 的“–”。那么我怎样才能让它以正确的方式工作呢？我知道我可以手动替换它，但我想知道是否可以使用 StringEscapeUtils 或任何其他实用程序来替换它。

Answer 1

And as I have read "\u0096" is cp1252 equivalent for "–".

我不这么认为。 Unicode 中的 0x0096 是 C1 控制代码：

http://en.wikipedia.org/wiki/C0_and_C1_control_codes

并且不太可能替代“-”（如您所写）。

好吧，如果 StringEscapeUtils 真的搞砸了（短划线确实应该是 \u2013），并且如果它是唯一的转义符，那么它就会搞砸，并且如果没有理由在您的字符串中包含任何其他 0x0096，那么replaceAll之后调用StringEscapeUtils应该可以工作。

以下内容实现了您期望的替换：

System.out.println("Broken\u0096stuff".replaceAll("\u0096", "\u2013"));

但是，您应该首先确保 StringEscapeUtils 确实把事情弄乱了，并且真正真正理解为什么/如何在 Java 字符串中获得 0x0096。

然后，也许还应该向您指出，遗憾的是 Java 的 Unicode 支持是一个重大问题，因为 Java 是在 Unicode 3.1 出现之前构思的。

因此，使用 16 位作为 char 原语似乎是一个聪明的主意，使用 4 个十六进制数字 '\uxxxx' 转义序列似乎是一个聪明的主意，表示 的长度似乎是一个聪明的主意String 的 length() 方法中的 char[] 等。

这些实际上都是非常非常愚蠢的想法，导致了主要的 Java 问题之一，其中 char 原语实际上无法容纳不再是 Unicode 字符，并且 String 的 length 方法实际上不返回 String 的实际长度。

我喜欢以下内容：

final char brokenCharCannotRepresentUnicode31Codepoints = '\uFFFF'; // How do I store a Unicode 3.1 codepoint here!?

为什么这样咆哮？好吧，因为我不知道 String 的 replaceAll 中的正则表达式替换是如何实现的，但如果有情况，我真的不会感到惊讶（ie 某些代码点），其中 String 的 replaceAll 是，就像 char 和 length 以及 \uxxxx 一样。嗯，彻底崩溃了。

Answer 2

我怀疑问题不在 StringEscapeUtils.unescapeHtml(...) 调用中。

相反，我怀疑该字符在调用之前已被转换为 '\u0096' 。更具体地说，我怀疑您的代码在将 HTML 读取为字符时使用了错误的字符集。

正如你所说，破折号是 cp1252 中的代码点 0x96 。因此，将短划线错误翻译为 unicode 代码点 \u0096 的一种方法是从使用 cp1252 编码的字节流开始，并使用 InputStreamReader(是“Latin-1”）。