проблема с кодировкой с XSS API в CQ5, à отображается как Ã�

Я использую com.adobe.granite.xss для кодирования строк в JSP. Кажется, это работает с большинством символов, кроме Ã. à отображается как Ã�.

Это происходит при использовании метода xssAPI.encodeForHTML(). Я пробовал <cq:text> с escapeXml="true", и у него такое же поведение.

Символы правильно хранятся в репозитории, и я также установил content="text/html; charset=utf-8" в JSP.

Есть ли способ кодировать или фильтровать ввод для XSS без нарушения кодировки в таких ситуациях.

Я пробовал это с разными нелатинскими символами, и на большинство из них не влияет API XSS.

введите здесь описание изображения


xss character-encoding aem diacritics
person Sharath Madappa    schedule 14.11.2014    source источник
comment
Похоже, у персонажа  та же проблема. Так как, например. à = U+00C3, что равно 0xC3 0x83 в UTF-8, кажется, что эта часть данных представляет собой данные в кодировке UTF-8, байты которых неверно истолкованы как данные ISO-8859-1 (и «�», возможно, является признаком того факта, что 0x83 присвоен управляющему коду в ISO-8859-1).   -  person Jukka K. Korpela    schedule 14.11.2014

Ответы (1)


arrow_upward
2
arrow_downward

Похоже, это проблема owasp-esapi-java, которая используется в XSSAPI CQ, потому что она перебирает строку с помощью метода charAt(). Но Ã находится за пределами BMP, поэтому правильным способом итерации будет:

final int length = s.length();
for (int offset = 0; offset < length; ) {
   final int codepoint = s.codePointAt(offset);

   // do something with the codepoint

   offset += Character.charCount(codepoint);
}

(форма Как я могу перебирать кодовые точки unicode строки Java?)

Так что я думаю, что это проблема этой библиотеки.

Попробуйте использовать xssAPI.filterHTML(), возможно, это решит вашу проблему.

person Oleksandr Tarasenko    schedule 14.11.2014