在Apache Tomcat中,参数URIEncoding
告诉Tomcat如何解释传入的URI:
URIEncoding
这指定用于解码URI字节的字符编码, 在%xx解码URL之后。如果未指定,将使用ISO-8859-1。
Apache Tomcat 7 - The HTTP Connector
但是,如What is the proper way to URL encode Unicode characters?中所述,URI中的非ASCII字符始终按照当前标准(RFC 3986和3987)以UTF-8编码。
所以:
这仅仅是因为Tomcat设置早于标准,并且为了向后兼容而保留了吗?或者是否存在与UTF-8不同的值有意义的情况?
答案 0 :(得分:3)
Tomcat 8中参数URIEncoding
的说明 - Apache Tomcat 8 - The HTTP Connector:
这指定在%xx解码URL之后用于解码URI字节的字符编码。如果未指定,将使用UTF-8,除非org.apache.catalina.STRICT_SERVLET_COMPLIANCE系统属性设置为true,在这种情况下将使用ISO-8859-1。
因此,描述与Apache Tomcat 7的描述有所不同.Apache Tomcat 8的默认值org.apache.catalina.STRICT_SERVLET_COMPLIANCE
为false。因此,UTF-8是Apache Tomcat 8的URIEncoding的默认值,这意味着Tomcat现在遵循标准(和常见用法)。
至于为什么Tomcat在Tomcat 7之前使用ISO 8859-1作为默认URI编码:
这似乎是因为Tomcat的开发人员认为这是Servlet规范所要求的(正如STRICT_SERVLET_COMPLIANCE设置的名称所示)。
事实上,Servlet规范没有在任何版本中明确提及URI编码。但是,它提到如果Content-Type
HTTP标头未通过charset
指定编码,则必须将POST数据解析为ISO 8859-1(Servlet规范V2.5,"请求数据编码&#34)。显然,这被解释为默认情况下,查询参数(以及整个URI)也应该被解码为ISO 8859-1。
根本问题可以说是Servlet规范没有指定用于解码URI的默认编码,更不用说改变这种编码的方法了。这反过来可能是因为URI规范最初不允许在URI中使用非ASCII字符 - 这只是通过引入IRI标准化,请参见2005年1月的RFC 3987。因此,每个servlet容器都必须提供自己的默认值和配置参数,例如Apache Tomcat中的URIEncoding
。
这两个问题已被报告为针对Servlet规范的错误:
也许有一天Servlet规范会被修改......
答案 1 :(得分:0)
我看到至少对于Tomcat 6及以下的URIEncoding不仅重要,而且是必要的,如果没有明确地将它设置为'UTF-8',很多人都会遇到问题。至于你的问题,我只能假设它是为了向后兼容。开发人员不愿意在编写代码后删除代码,即使再次需要它的可能性为零:)