「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")對其進行讀取/解碼。