Как изменить конфигурацию кодировки символов по умолчанию на сервере приложений Jetty с UTF-8 на ISO-8859-1 - PullRequest
0 голосов
/ 11 октября 2019

Я хочу, чтобы мое приложение полностью поддерживало ISO-8859-1 на сервере Jetty. Но я не могу изменить кодировку символов по умолчанию на ISO-8859-1. Где мне нужно установить кодировку / кодировки?

Это для jetty-distribution-9.4.12, запускающего веб-приложение Struts. Я попытался изменить webdefault.xml для сопоставления кодировки. Но почему-то не удается принять кодировку UTF-8.

Я вижу проблему при присвоении имени ресурсу XML с японскими символами ( 私 の ユ ー ザ ー ). Jetty Server всегда не в состоянии принять это имя на мой ресурс. Когда я проверяю запрос, я вижу, что тип контента - UTF-8 и HTTP 1.1 spec. Я хочу, чтобы мой сервер принимал имя моего ресурса как 私 の ユ ー ザ ー. Чтобы это произошло, я хотел добавить эту совместимость на сервер. Однако, обладая небольшим знанием, я провел некоторые исследования, пытаясь выполнить некоторые настройки на сервере, но, похоже, ничего не помогло.

Пробная версия 1

Изменение web-default.xml * с кодировкой локали

<locale-encoding-mapping> <locale>en</locale> <encoding>ISO-8859-1</encoding> </locale-encoding-mapping>

Пробная версия 2

добавление свойства кодирования в JAVA_OPTIONS в файле jetty.sh

JAVA_OPTIONS+=("-Dfile.encoding=UTF-8")

ссылки:

Проблема кодировки символов Jetty

Jetty 9, кодировка символов UTF-8

1 Ответ

0 голосов
/ 11 октября 2019

Jetty использует текущие спецификации HTTP / 1.1 (да, все эти спецификации говорят о текущем поведении HTTP / 1.1)

Я думаю, что наиболее релевантная спецификация к вашему вопросу от RFC7231 - Приложение B: Обновления от RFC2616

   The default charset of ISO-8859-1 for text media types has been
   removed; the default is now whatever the media type definition says.
   Likewise, special treatment of ISO-8859-1 has been removed from the
   Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)

Идея ISO-8859-1, поскольку набор символов по умолчанию давно устарел, единственное место, где вы найдете ISO-8859-1, обозначенный как набор символов по умолчанию, это старые спецификации, которые теперь помечены как «устаревшие» (такие как RFC2616).

Временная шкала:

  1. Более старая спецификация HTTP / 1.1, RFC2616, была выпущена в 1999 году.
  2. Ошибки в RFC2616 былиВ 2006 году начались обсуждения пересмотренной спецификации.
  3. Обновленные спецификации RFC7230 - RFC7235 были выпущены в июне 2014 года.
  4. Все основные поставщики браузеров (Chrome, Firefox, Edge, Safari,и т. д.) обновлен в этом году для поддержки RFC7230 и связанных с ним спецификаций.
  5. За прошедшие годы основной браузер начал отказываться от концепций и поддержки RFC2616, удаляя поведение и даже тихо отбрасывая функции, которые были из других устаревшихспецификации (например, старый синтаксис заголовка Set-Cookie теперь приводит к неработоспособности на стороне браузера, при этом cookie удаляется).

Сегодня (сентябрь 2019):

  • Протокол HTTP 1.1 имеет кодировку символов по умолчанию UTF-8.
  • Кодировка символов по умолчанию для документа HTTP 1.1 - UTF-8.
  • Протокол HTTP 2 имеет кодировку символов по умолчанию - UTF-8.
  • Символ по умолчанию для документа HTTP 2кодировка UTF-8.

За что сегодня отвечают все веб-разработчики:

  • Вы ДОЛЖНЫ ограничить использование протокола HTTP 1.1 (имена заголовков, значения заголовков) США-ASCII.
  • Имена заголовков должны соответствовать правилам токена HTTP 1.1 . (это подмножество US-ASCII)
  • Значения заголовка, которые содержат символ вне US-ASCII, ДОЛЖНЫ быть сначала закодированы в UTF-8, а затем шестнадцатеричные значения, закодированные в процентах для представления в значении заголовка.
  • Если вы намереваетесь отправить документ ISO-8859-1 в качестве тела ответа, вы ДОЛЖНЫ указать в качестве такового в заголовке HTTP-ответа Content-Type тип mime и кодировку. (например: Content-Type: text/html; charset=ISO-8859-1)

Но, учитывая, что вы не указали, где в HTTP-обмене вы хотите установить эту кодировку символов по умолчанию, трудно выразить подробный ответ / решение для вашеговопрос. (например: это может быть проблема с вашей кодировкой application/x-www-form-urlencoded содержимого тела запроса и его взаимодействием со спецификацией Servlet? которая может быть исправлена ​​дополнительным полем в вашей HTML5-форме между прочим)

...