Какой смысл установки URIEncoding от Tomcat?

В Apache Tomcat, параметр URIEncoding говорит Tomcat, как интерпретировать входящие URI:

URIEncoding

Это указывает кодировку символов, используемую для декодирования байтов URI, после%xx декодирования URL. Если не указано иное, будет использоваться ISO-8859-1.

Apache Tomcat 7 - коннектор HTTP

Однако, как объяснено, например, в разделе Как правильно URL кодировать символы Юникода? не-ASCII символы в URI всегда кодируются в UTF-8 в соответствии с действующими стандартами (RFC 3986 и 3987).

Так:

  • Почему даже есть настройка для чего-то, что предписано стандартом?
  • Почему дефолт отличается от стандартных мандатов? (ISO-8859-1 вместо UTF-8)

Это просто потому, что настройка Tomcat предшествовала стандарту и была сохранена для обратной совместимости? Или есть какая-то ситуация, когда значение, отличное от UTF-8, имеет смысл?

Источник

2 ответа

Решение

Описание параметра URIEncoding в Tomcat 8 - Apache Tomcat 8 - Соединитель HTTP:

Это указывает кодировку символов, используемую для декодирования байтов URI, после%xx декодирования URL. Если не указан, будет использоваться UTF-8, если системное свойство org.apache.catalina.STRICT_SERVLET_COMPLIANCE не установлено в значение true, и в этом случае будет использоваться ISO-8859-1.

Таким образом, описание было изменено с Apache Tomcat 7. Значение по умолчанию org.apache.catalina.STRICT_SERVLET_COMPLIANCE в Apache Tomcat 8 имеет значение false. Таким образом, UTF-8 является значением URIEncoding по умолчанию для Apache Tomcat 8, что означает, что Tomcat теперь следует стандарту (и общепринятому использованию).

Что касается того, почему Tomcat использовал ISO 8859-1 в качестве кодировки URI по умолчанию до Tomcat 7:

Похоже, это связано с тем, что разработчики Tomcat полагали, что именно этого требует спецификация сервлета (как указывает название параметра STRICT_SERVLET_COMPLIANCE).

На самом деле, в спецификации Servlet явно не упоминается кодировка URI ни в одной версии. Однако в нем упоминается, что данные POST должны быть проанализированы как ISO 8859-1, если Content-Type Заголовок HTTP не указывает кодировку через charset (Спецификация сервлета V2.5, "Запрос кодирования данных"). Очевидно, это интерпретировалось как означающее, что параметры запроса (и, следовательно, весь URI) также должны быть декодированы как ISO 8859-1 по умолчанию.

Возможно, корень проблемы в том, что в спецификации сервлета не указана кодировка по умолчанию, используемая для декодирования URI, не говоря уже о способе изменения этой кодировки. Это, в свою очередь, возможно потому, что спецификация URI изначально не допускала символы не-ASCII в URI - это было стандартизировано только путем введения IRI, см. RFC 3987 от января 2005 года. Поэтому каждый контейнер сервлета должен был придумать свое собственное значение по умолчанию и параметр конфигурации, такой как URIEncoding в Apache Tomcat.

Об этих двух проблемах сообщалось как об ошибках в спецификации сервлета:

Может быть, спецификация сервлета будет изменена однажды...

Источник

Я вижу, что по крайней мере для Tomcat 6 и ниже кодирование URIE было не только важным, но и необходимым, так как у многих людей возникали проблемы, если они явно не устанавливали его в UTF-8. Что касается вашего вопроса, я могу только предположить, что это для обратной совместимости. Разработчики ненавидят удалять код после того, как написали его, даже если вероятность того, что он снова понадобится, равна нулю:)

Источник
Другие вопросы по тегам