"org.apache.commons.lang.StringEscapeUtils“和"en dash”

Question

我使用"*org.apache.commons.lang.StringEscapeUtils.unescapeHtml(myHtmlString)“将Html转义转换为包含与转义对应的实际Unicode字符的字符串。然而，它没有正确地解析"em破折号“和"en破折号”符号。StringEscapeUtils将“-”替换为“\u 0096”，而正确的错误位置是"\u2013“。正如我所读到的，“\u 0096”是“-”的cp1252等价物。那我怎么才能让它以正确的方式运作呢？我知道我可以手动替换它，但是我想知道我是否可以用StringEscapeUtils或任何其他util来替换它。

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真的搞砸了(en dash应该是\u2013)，如果它是唯一的转义，它就是混乱的，而且如果没有理由在字符串中有任何其他的0x0096，那么调用StringEscapeUtils之后的replaceAll 就会工作。

以下是您期望的替换：

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

但是，您应该首先确保StringEscapeUtils确实把事情搞砸了，并且非常、非常地理解为什么/如何在Java中获得0x0096。

此外，可能还应该指出，遗憾的是，Java的Unicode支持是一个主要的陷阱，因为Java是在Unicode 3.1发布之前构想出来的。

因此，为char原语使用16位似乎是一个明智的想法，使用4-十六进制'\uxxxx‘转义序列似乎是一个聪明的想法，用String的length()方法来表示char[]的长度似乎是一个明智的想法。

这些实际上都是非常愚蠢的想法，导致了一个主要的Java，其中char原语实际上不能容纳Unicode字符，而String的length方法实际上是，而不是，返回字符串的实际长度。

我喜欢以下几点：

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

为什么这么大喊大叫？嗯，因为我不知道字符串的replaceAll中的regexp替换是如何实现的，但是如果存在字符串的replaceAll是像char和类似长度以及类似\uxxxx的情况，那么我真的不会被告知。嗯，完全坏了。

Answer 2

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

相反，我怀疑这个角色在打电话之前已经变成了'\u0096'。更具体地说，我怀疑您的代码在将HTML读入字符时使用了错误的字符集。

正如您所说，n-破折号是cp1252中的代码点cp1252.因此，要使n-破折号误译到unicode代码点\u0096，一种方法是从使用cp1252编码的字节流开始，然后使用InputStreamReader(is, "Latin-1")读取/解码它。