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

Question

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

Answer 1

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

我不这么认为。 0×0096的Unicode是一个C1控制代码：

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

，是不太可能的替代品“ - ”（为你写）。

好吧，如果StringEscapeUtils真的弄乱这件事（破折号确实应该\ u2013），如果它是唯一的逃避它是搞乱，如果没有理由在你的字符串的任何其他0×0096，那么全部替换后拨打StringEscapeUtils应该工作。

您希望以下并替换：

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

但是你应该首先确保StringEscapeUtils真的弄乱的东西了，真的，真的，明白为什么/如何获取在Java字符串0×0096 。

然后，也应该指出，可悲的是Java的Unicode支持是一个主要的SNAFU，因为Java在Unicode 3.1出现之前就已经被构思出来了。

因此，使用16位来处理原始代码似乎是一个聪明的想法，使用4位十六进制'\ uxxxx'转义序列似乎是一个聪明的主意，但代表长度的char []中字符串的长度（）方法等

这些人其实都是非常非常愚蠢的想法导致了主要的Java天翻地覆的一个，其中焦炭原始不能实际持有一个Unicode字符了何字符串的长度方法实际上是而不是返回一个字符串的实际长度。

我喜欢以下几点：

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

为什么这种言论？嗯，因为我不知道怎么的正则表达式替换字符串的的replaceAll实现，但我真的不会，如果存在这样的情况（即某些码点），其中字符串的的replaceAll是，像焦炭惊讶等长度等\ uxxxx，好..嗯，完全破碎。

Answer 2

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

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

正如你所说，代码点0x96在cp1252中。因此，一种将en-dashed误译为unicode代码点\u0096的方法是从一个使用cp1252编码的字节流开始，并使用InputStreamReader(is, "Latin-1")对其进行读取/解码。