我正在使用“*org.apache.commons.lang.StringEscapeUtils.unescapeHtml(myHtmlString)”将 Html 实体转义转换为包含与转义对应的实际 Unicode 字符的字符串。但是它不能正确解析“em dash”和“en dash”符号。 StringEscapeUtils 将“–”替换为“\u0096”，而正确的错位是“\u2013”。正如我所读到的，“\u0096”相当于“-”的 cp1252。那么我怎样才能让它以正确的方式工作呢？我知道我可以手动替换它，但我想知道是否可以使用 StringEscapeUtils 或任何其他实用程序来替换它。
【问题讨论】：
StringEscapeUtils的哪个方法？
标签： java unicode character-encoding html-escape-characters
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 after 调用 StringEscapeUtils 应该可以工作。
以下内容可以满足您的期望：
System.out.println("Broken\u0096stuff".replaceAll("\u0096", "\u2013"));
但是，您首先应该确保 StringEscapeUtils 真的把事情搞砸了，并且真的，真的，理解为什么/如何在 Java 字符串中得到那个 0x0096。
那么，也许应该向您指出，遗憾的是，Java 的 Unicode 支持是一个主要的 SNAFU，因为 Java 是在 Unicode 3.1 出现之前构想的。
因此，为 char 原语使用 16 位似乎是一个聪明的想法，使用 4 位十六进制数字 '\uxxxx' 转义序列似乎是一个聪明的想法，它似乎是一个聪明的想法来表示String的length()方法中char[]的长度等
这些实际上都是非常非常愚蠢的想法，导致了主要的 Java SNAFU 之一，其中 char 原语实际上不能再保存 Unicode 字符，而 String 的 length 方法实际上 不是 返回一个字符串的实际长度。
我喜欢以下内容：
final char brokenCharCannotRepresentUnicode31Codepoints = '\uFFFF'; // How do I store a Unicode 3.1 codepoint here!?
为什么要吐槽？好吧，因为我不知道 String 的 replaceAll 中的正则表达式替换是如何实现的，但我 真的 如果有案例我不会感到惊讶（ie em> 某些代码点），其中 String 的 replaceAll 像 char 和 length 和 \uxxxx 一样。 . 嗯，完全坏了。
【讨论】：
我怀疑问题不在StringEscapeUtils.unescapeHtml(...) 调用中。
相反，我怀疑这个角色在调用之前 已经变成了'\u0096'。更具体地说，我怀疑您的代码在将 HTML 作为字符读取时使用了错误的字符集。
正如您所说，短划线是 cp1252 中的代码点 0x96。因此，将破折号错误翻译为 unicode 代码点 \u0096 的一种方法是从使用 cp1252 编码的字节流开始，然后使用 InputStreamReader(is, "Latin-1") 对其进行读取/解码。
【讨论】：