Какие причины java.io. CharConversionException с EOF или isHexDigit обменивается сообщениями в Tomcat?
Быстрый пример для игры:
public static void DoThis(int n)
{
var input = new char[n];
for (var i = 0; i < input.Length; i++)
{
input[i] = Console.ReadKey().KeyChar;
}
Console.WriteLine(); // Linebreak
Console.WriteLine(input);
Console.ReadKey();
}
4 ответа
Просто выдвижение гипотезы здесь. Походит на декодирование URL параметров, или их сбои значений (кодирование URL означает кодировать некоторые символы с помощью %XX или %XXXX нотации, где XX или XXXX шестнадцатеричный код символа в ISO-8859-1 или Unicode). В первом случае ошибка могла бы происходить, потому что нет достаточных шестнадцатеричных символов после символа %. Во втором случае это могло бы происходить, потому что символ после символа % не является шестнадцатеричным.
Другой вещью заняться расследованиями является URIEncoding в Вашей конфигурации "Коннектора" Tomcat. Если ссылка будет на закодированной странице UTF-8, то она закодирует URL к байтам с UTF-8, то URL кодирует любой из байтов, которым нужна она. Однако по умолчанию Tomcat думает, что те байты являются ISO-8859-1, который может привести к проблемам.
Инверсия может также быть верной: если страница является ISO-8859-1, и URIEncoding Tomcat был установлен на UTF-8, подобная ошибка могла закончиться.
Вот полезная дискуссия о проблемах в этой области: Ловушки Набора символов в Контейнерах JSP/Servlet
Это также может быть (из Википедии):
Существует нестандартная кодировка символов Юникода: % uxxxx, где xxxx - это значение Unicode, представленное в виде четырех шестнадцатеричных цифр. Это поведение не определено никаким RFC и было отклонено W3C. Третье издание ECMA-262 по-прежнему включает функцию escape (string), которая использует этот синтаксис, а также функцию encodeURI (uri), которая конвертирует в UTF-8 и кодирует каждый октет в процентах.
Таким образом, вы можете использовать старая функция escape в Javascript, но поскольку более поздние версии Tomcat более строги в таких вещах (5.5.17 позволяют этому кодированию скользить), только теперь вы начинаете видеть исключения.
Я начал получать эту ошибку, когда пользователи отправляли "%" по запросу ajax. Оказывается, я не экранировал параметры до того, как сделал запрос. Полное описание этого сценария и исправления содержится в этой записи блога