Кодирование/декодирование HTTP-заголовков в Java
К вашему сведению, я нашел один способ реализовать это, изменив второе поле на пустую сумму - так что внутри есть только одно поле для currencyId. Затем я сделал метод получения для суммы2, который будет восстанавливать полный экземпляр с использованием currencyId из первой суммы. Что-то вроде этого:
@Embedded
@AttributeOverrides({
@AttributeOverride(name="amount", column=@Column(name = "AMOUNT1")),
})
private AmountWithCurrency amount1;
@Column
private BigDecimal amount2;
public AmountWithCurrency getAmount2(){
return new AmountWithCurrency(amount1.getCurrencyId(), amount2);
}
Это все еще не идеальное решение, так как это все еще может вызвать проблемы в запросах и т. Д. Но, похоже, сейчас работает для меня. Надеюсь, это кому-нибудь поможет.
5 ответов
Снова: RFC 2047 не реализован на практике. Следующий пересмотр HTTP/1.1 собирается удалить любое упоминание о нем.
Так, если необходимо транспортировать символы неASCII, самый безопасный путь состоит в том, чтобы закодировать их в последовательность ASCII, такого как заголовок "Краткого заголовка" в Протоколе публикации Atom.
Рабочая группа HTTPbis знает о проблеме, и последние проекты избавляются от всего языка относительно ТЕКСТА и кодирования RFC 2047 - она не используется на практике по HTTP.
См. http://trac.tools.ietf.org/wg/httpbis/trac/ticket/74 для целой истории.
Посмотрите спецификацию HTTP для правил, которая говорит в разделе 2.2
ТЕКСТОВОЕ правило только используется для описательного полевого содержания и значений, которые не предназначаются, чтобы быть интерпретированными синтаксическим анализатором сообщения. Слова *ТЕКСТ МОЖЕТ содержать символы от наборов символов кроме изо - 8859-1 [22] только при кодировании согласно правилам RFC 2047 [14].
Вышеупомянутый код не будет правильно декодировать строку кодирования RFC2047, ведя меня, чтобы полагать, что сервис правильно не следует за спецификацией и ими просто встраивание сырых данных utf-8 данные в заголовке.
Спасибо за ответы. Кажется, что идеал должен был бы следовать за надлежащим кодированием HTTP-заголовка согласно RFC 2047. Значения заголовка в UTF-8 на проводе выглядели бы примерно так:
=?UTF-8?Q?...?=
Теперь вот забавная вещь: кажется, что никакой Tomcat 5.5 или 6 правильно не декодирует HTTP-заголовки согласно RFC 2047! Код Tomcat предполагает везде, что значения заголовка используют ISO-8859-1.
Таким образом для Tomcat, а именно, я буду работать вокруг этого путем записи фильтра, который обрабатывает надлежащее декодирование значений заголовка.
Как упомянуто уже первый взгляд должен всегда переходить к спецификации (RFC 2616) HTTP 1.1. Это говорит, что текст в значениях заголовка должен использовать MIME, кодирующий определенным RFC 2047, если это содержит символы от наборов символов кроме ISO-8859-1.
Таким образом, вот плюс для Вас. Если Ваши требования покрыты набором символов ISO-8859-1 затем, Вы просто помещаете свои символы в Ваш запрос/ответные сообщения. Иначе кодирование MIME является единственной альтернативой.
Пока агент пользователя отправляет значения в Ваши пользовательские заголовки согласно этим правилам Вы, привычка должна волноваться о декодировании их. Это - то, что Сервлет должен сделать API.
Однако существует более основная причина, почему Ваш код sniplet не делает то, что это, как предполагается. Первая строка выбирает значение заголовка как строку Java. Поскольку мы знаем, что это представлено как UTF8 внутренне так в этой точке, парсинг сообщения Запроса HTTP уже сделан и закончен.
Следующая строка выбирает массив байтов этой строки. Так как никакое кодирование не было указано (по моему скромному мнению, этот метод без аргумента должен был быть удержан от использования давно), кодировка по умолчанию существующей системы используется, который обычно является не UTF8, и затем массив снова преобразовывается как являющийся закодированным UTF8. Outch.