"org.apache.commons.lang.StringEscapeUtils" и "en dash"

Question

Я использую "* org.apache.commons.lang.StringEscapeUtils.unescapeHtml (myHtmlString)", чтобы преобразовать экранирование Html-сущности в строку, содержащую фактические символы Unicode, соответствующие экранированию. Однако он не обрабатывает символы «em dash» и «en dash» должным образом. StringEscapeUtils заменяет «-» на «\ u0096», в то время как правильное неправильное размещение - «\ u2013». И, как я прочитал, "\ u0096" является эквивалентом cp1252 для "-". Так как я могу заставить его работать правильно? Я знаю, что могу заменить его вручную, но мне интересно, могу ли я сделать это с помощью StringEscapeUtils или с помощью любого другого утилиты.

Answer 1

Я подозреваю, что проблема не в вызове StringEscapeUtils.unescapeHtml(...).

Вместо этого я подозреваю, что символ был превращен в '\u0096' до вызова.Более конкретно, я подозреваю, что ваш код использовал неправильный набор символов при чтении HTML как символов.

Как вы говорите, точка-дешифровка - это кодовая точка 0x96 в cp1252.Таким образом, один из способов получить неправильно переведенную пунктирную строку в кодовую точку Unicode \u0096 - начать с потока байтов, который был закодирован с использованием cp1252, и прочитать / декодировать его с помощью InputStreamReader(is, "Latin-1").

Answer 2

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

Я так не думаю.0x0096 в Unicode - это управляющий код C1:

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

и вряд ли будет заменой "-" (как вы написали).

Хорошо, если StringEscapeUtils действительно все испортило (en dash действительно должно быть \ u2013), и если это единственный выход, он испортился, и если нет никаких причин иметь какой-либо другой 0x0096 в вашей строке, то replaceAll после с вызовом StringEscapeUtils должно работать.

Следующее заменитель, которого вы ожидаете:

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

Однако вы должны сначала сделатьубедитесь, что StringEscapeUtils действительно испортили вещи и действительно, действительно, понимают, почему / как вы получаете этот 0x0096 в строке Java.

Тогда также, вероятно, вам следует указать, чток сожалению, поддержка Unicode в Java является основным SNAFU, потому что Java была задумана еще до выхода Unicode 3.1.

Следовательно, казалось разумным использовать 16 бит для примитива char , это казалось разумной идеейиспользовать 4-hexdigits '\ uxxxx' escape-последовательность, казалось разумным представить длину char [] в методе length () String и т. д.

На самом деле все они были оченьглупая идея, ведущая к одному из главных Java SNAFU, где примитив char не может фактически содержать символ Unicode больше и где метод длины String действительно not возвращает реальную длину String.

Мне нравится следующее:

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

Почему эта напыщенная речь?Ну, потому что я не знаю, как реализована замена регулярного выражения в replaceAll в String, но я действительно не был бы удивлен, если бы были случаи ( то есть определеннокодовые точки) где String replaceAll был, например, char и как length и как \ uxxxx , ну .. хммм, полностью сломан.