Какая кодировка используется AppEngine TaskQueue, когда они кодируют массивы byte[] как строки?

Какова кодировка тела HTTP POST, вызываемого из службы AppEngine TaskQueue?

Если я создаю задачу через TaskOptions#payload(byte[], String), какой будет кодировка тела HTTP-запроса?

Точно так же, какая будет кодировка String, созданного с помощью TaskOptions#param(String, byte[]) и получено через ServletRequest#getParameter(String)?

ОБНОВЛЕНИЕ: Какое имя набора символов я должен использовать в

req.getParameter("myParam").getBytes(charset)

чтобы вернуть двоичные данные, которые я отправил через TaskOptions#param(String, byte[]) ?

Кажется, это значение по умолчанию для конкретного сервлета-контейнера, которое не определено в определении для «application/x-www-form-urlencoded» в http://www.w3.org/TR/html4/Interact/forms.html#h-17.13.4.1 -- потому что все это уже абстрагировано в API сервлета.


person Dr. Max Völkel    schedule 09.03.2011    source источник


Ответы (2)


Если я создам задачу через TaskOptions#payload(byte[], String), какой будет кодировка тела HTTP-запроса?

Кодировки нет — массив байтов, который вы передаете, становится буквальным телом HTTP-запроса.

Аналогично, какой будет кодировка строки, созданной с помощью TaskOptions#param(String, byte[]) и полученной с помощью ServletRequest#getParameter(String)?

Параметры кодируются с помощью formencoding, как в обычном запросе GET или POST.

person Nick Johnson    schedule 10.03.2011
comment
Я предполагаю, что вы имеете в виду «application/x-www-form-urlencoded», как определено в w3.org/TR/html4/interact/forms.html#h-17.13.4.1 — Спасибо! - person Dr. Max Völkel; 10.03.2011
comment
@xamde Это тип содержимого для запроса POST, который содержит параметры, да. - person Nick Johnson; 10.03.2011
comment
Эта кодировка не поддерживает двоичное содержимое. multipart/form-data делает. Наверняка этот массив байтов должен быть как-то закодирован. Как еще вы могли бы получить String из этого? - person BalusC; 10.03.2011
comment
@BalusC Да, это так - байты, которые не являются безопасными для URL, закодированы в % . - person Nick Johnson; 11.03.2011
comment
%-кодирование применяется к символам, а не к байтам. - person BalusC; 11.03.2011
comment
@BalusC Нет, не так. В соответствии с RFC1738, кроме того, октеты могут быть закодированы тройкой символов, состоящей из символа %, за которым следуют две шестнадцатеричные цифры (от 0123456789ABCDEF), образующие шестнадцатеричное значение октета. - person Nick Johnson; 11.03.2011
comment
Это противоречит вашему ответу. - person BalusC; 11.03.2011
comment
@BalusC Как так? Аргумент, переданный TaskOptions#param, является byte[], и я только что объяснил, как они кодируются (используя formencoding). - person Nick Johnson; 11.03.2011

Насчет первого понятия не имею. Однако я сделаю ставку на UTF-8, поскольку в Javadoc везде упоминается UTF-8. Вы можете отладить тело запроса с помощью инструмента отладчика HTTP, такого как Fiddler2. Вы можете протестировать строки со специфическими символами UTF-8, которые преобразуются в байтовый массив с помощью string.getBytes("UTF-8"), а затем считываются на стороне сервлета. Если он возвращает те же символы, то вероятность того, что он использует UTF-8, определенно велика.

Во втором случае это зависит от атрибута charset в заголовке запроса Content-Type. Однако это более чем часто отсутствует (по крайней мере, при использовании обычного веб-браузера). Однако вы можете установить его самостоятельно с помощью ServletRequest#setCharacterEncoding() до доступа к каким-либо данным из тела запроса.

if (request.getCharacterEncoding() == null) {
    request.setCharacterEncoding("UTF-8");
}

В противном случае будет использоваться платформа по умолчанию, как указано Charset#defaultCharset().

person BalusC    schedule 10.03.2011
comment
Спасибо за ответ. Но, к сожалению, это не совсем соответствует моему вопросу, который просто перефразирован. Может, мне стоит просто поэкспериментировать и надеяться, что они ничего не изменят. Однако некоторая официальная документация по этому поводу сделала бы меня счастливее. - person Dr. Max Völkel; 10.03.2011