「*org.apache.commons.lang.StringEscapeUtils.unescapeHtml(myHtmlString)」を使用して、Htmlエンティティエスケープを、エスケープに対応する実際のUnicode文字を含む文字列に変換しています。ただし、「emdash」および「endash」記号は正しく解析されません。StringEscapeUtilsは、「–」を「\ u0096」に置き換えますが、正しい配置ミスは「\u2013」です。そして、私が読んだように、「\u0096」は「–」と同等のcp1252です。では、どうすればそれを正しく機能させることができますか?手動で置き換えることができることは知っていますが、StringEscapeUtilsまたは他のutilでそれを行うことができるかどうか疑問に思います。
2 に答える
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 ダッシュは実際には \u2013 である必要があります)、それが唯一のエスケープである場合、それは台無しであり、文字列に他の 0x0096 を含める理由がない場合は、StringEscapeUtils を呼び出した後にreplaceAllが機能するはずです。 .
以下は、あなたが期待する置き換えを行います:
System.out.println("Broken\u0096stuff".replaceAll("\u0096", "\u2013"));
ただし、最初にStringEscapeUtilsが本当に混乱していることを確認し、Java String で 0x0096 を取得する理由と方法を本当に理解する必要があります。
また、Java は Unicode 3.1 が登場する前に考案されたため、残念ながら Java の Unicode サポートは主要な SNAFU であることを指摘しておく必要があります。
したがって、 charプリミティブに16 ビットを使用するのは賢明な考えであり、4 桁の 16 進数の '\uxxxx' エスケープ シーケンスを使用するのは賢明な考えであると思われ、文字列の長さでchar[]の長さを表すのは賢明な考えであると思われました。 () 方式など
これらは実際にはすべて、主要な Java SNAFU の 1 つにつながる非常に愚かなアイデアであり、charプリミティブが実際には Unicode char を保持できなくなり、String の length メソッドが実際にはString の実際の長さを返さないというものでした。
私は次のことが好きです:
final char brokenCharCannotRepresentUnicode31Codepoints = '\uFFFF'; // How do I store a Unicode 3.1 codepoint here!?
なぜこの暴言?ええと、String のreplaceAllの正規表現置換がどのように実装されているかはわかりませんが、String のreplaceAllがcharのようにlengthのように\uxxxxのようになっている場合 (つまり、特定のコードポイント) があったとしても、本当に驚かないでしょう。 ..うーん、完全に壊れています。
問題はStringEscapeUtils.unescapeHtml(...)
通話にないのではないかと思います。
'\u0096'
代わりに、電話の前にキャラクターが変身したのではないかと思います. より具体的には、HTML を文字として読み取るときに、コードが間違った文字セットを使用していると思われます。
あなたが言うように、en-dash は0x96
cp1252 のコードポイントです。したがって、en-dashed を Unicode コードポイントに誤って変換する 1 つの方法は、\u0096
cp1252 を使用してエンコードされたバイト ストリームから開始し、InputStreamReader(is, "Latin-1")
.