Разбор HTTP - Bytes.length! = String.length

Question

Я использую HTTP через nio.SocketChannel, поэтому я получаю куски данных как Array[Byte]. Я хочу поместить эти чанки в анализатор и продолжить синтаксический анализ после того, как каждый чанк был помещен.

Кажется, что сам HTTP использует кодировку ISO8859, но сама полезная нагрузка / тело может быть произвольно закодирована: Если HTTP-длина содержимого задает X байтов, тело в декодированном UTF8 может содержать намного меньше символов (1 символ может быть представлен в UTF8 2 байтами и т. Д.).

Так что же является хорошей стратегией синтаксического анализа для соблюдения явно указанной Content-Length и / или Transfer-Encoding: Chunked, которая задает длину фрагмента, которая должна выполняться.

• добавляет каждый блок данных к mutable.ArrayBuffer[Byte], ищет CRLF в байтах, декодирует все от 0 до CRLF в строку и сопоставляет с регулярными выражениями, такими как StatusRegex, HeaderRegex и т. Д.?
• расшифруйте каждый блок данных с помощью соответствующей кодировки (например, iso8859, utf8 и т. Д.) И добавьте к StringBuilder. С этим решением я не могу соблюдать ни Content-Length, ни Chunk-Size, но ... мне нужно заботиться об этом?
• любое другое решение ...?

Answer 1

Вы можете использовать UTF-16, который в любом случае является внутренним представлением String в Java. Это 2 байта для каждого символа, кроме случаев, когда есть суррогат. Таким образом, вы можете отсканировать строку на наличие суррогатных символов до разрешенной длины, учесть их соответствующим образом и просто скопировать подстроки.

Answer 2

Я накапливаю весь массив [Byte] в ArrayBuffer, который позволяет мне считать байты. Декодирование протокола HTTP (Status + Headers) выполняется путем поиска CRLF-позиции и затем декодирования от 0 до CRLF с ISO8859.

Чанкованные тела накапливаются в ArrayBuffer и декодируются только с помощью указанной кодировки, если чанк был полностью сохранен в ArrayBuffer. Это позволяет обойти MALFORMED исключения из CharsetDecoder при декодировании данных utf8, которые разбиты прямо на середину 2-байтового символа.

Для потокового HTML у меня пока нет хорошего решения, обычный HTML буферизируется в ArrayBuffer и декодируется после получения всего документа (например, кусков).