如何将Jetty app server中的默认字符编码配置从UTF-8更改为ISO-8859-1

我希望我的应用程序在jetty server中完全支持ISO-8859-1。但我无法将默认字符编码更改为ISO-8859-1。我需要在哪里设置编码/字符集

这适用于jetty-distribution-9.4.12，运行struts web应用程序。我已尝试修改webdefault.xml以对映射进行编码。但不知何故，它无法采用UTF-8编码

当使用日文字符为XML资源命名时，我发现了一个问题（私のユーザー）。jetty server总是无法将此名称添加到我的资源中。当我签入请求时，我看到内容类型是UTF-8和HTTP 1.1规范。 我希望我的服务器支持将我的资源名称作为私のユーザー. 为了实现这一点，我想将这种兼容性添加到服务器中。 然而，在我所知不多的情况下，我做了一些研究，试图在服务器上进行一些配置，但似乎没有任何效果

试验1 使用区域设置编码更改web default.xml

EN
ISO-8859-1

试验2 将encoding属性添加到jetty.sh文件中的JAVA_选项

JAVA_OPTIONS+=（“-Dfile.encoding=UTF-8”）

参考链接

---

Jetty使用当前的HTTP/1.1规范（是的，所有这些规范都涉及当前的HTTP/1.1特定行为）

我认为与你的问题最相关的规范是

ISO-8859-1作为默认字符集的想法很久以前就被弃用了，您会发现ISO-8859-1唯一被指示为默认字符集的地方是现在被标记为“过时”的旧规范（如RFC2616）

时间线：

较旧的HTTP/1.1规范RFC2616于1999年发布

已确定RFC2616中的故障，并于2006年开始讨论修订规范

更新的规范RFC7230至RFC7235于2014年6月发布

所有主要浏览器供应商（Chrome、Firefox、Edge、Safari等）都在当年进行了更新，以支持RFC7230和相关规范

多年来，主流浏览器已经开始放弃RFC2616概念和支持，删除行为，甚至悄悄地放弃来自其他过时规范的功能（例如：较旧的

Set Cookie

header语法现在导致浏览器端没有操作，Cookie被删除）

今天（2019年9月）：

• HTTP 1.1协议的默认字符编码为UTF-8
• HTTP 1.1文档的默认字符编码是UTF-8
• HTTP 2协议的默认字符编码为UTF-8
• HTTP 2文档的默认字符编码是UTF-8

今天所有的Web开发人员都要负责：

• 您必须将HTTP 1.1协议使用（头名称、头值）限制为US-ASCII
• 标题名称应该跟在后面。（这是US-ASCII的子集）
• 包含US-ASCII 1以外字符的标头值必须首先在UTF-8中编码，然后编码十六进制值百分比，以便在标头值中表示
• 如果要将ISO-8859-1文档作为响应正文发送，则必须在HTTP响应

  Content Type

  标题中指明mime类型和字符集。（例如：

  内容类型：text/html；charset=ISO-8859-1

  ）

但是，由于您没有指出要在HTTP exchange中的何处设置此默认字符编码，因此很难对您的问题给出详细的答案/解决方案。（例如：您对

应用程序/x-www-form-urlencoded

请求正文内容的编码及其与Servlet规范的交互可能存在问题？这可以通过HTML5表单btw中的附加字段修复）

1：这可能看起来很苛刻，但如果您检查一下，您会发现在US-ASCII之外的HTTP头字段中存在的字符最多会被删除，或者最坏的情况下会被解释为obs折叠或obs文本字符，从而导致整个请求变为坏请求（400个坏请求）

---

所以你只想要UTF-8的子集？只有拉丁语-1。没有国际角色支持？你想故意破坏对Chrome、Firefox和Microsoft Edge的支持吗？是否要使用旧的/过时的HTTP规范？这就是使用ISO-8859-1的意思——日语字符永远不是ISO-8859-1。这一更新的问题本身存在冲突。另外，您是否询问文件名？还是内容？（两个完全不同的概念）您的测试对文件名没有影响，但您的问题似乎表明您希望文件名具有日语字符集。如果是文件名，您必须了解文件名的存储位置（例如：Windows、vs Linux、vs OSX、vs JAR），谢谢您的回复。我已经更新了问题的更多细节。请查收。所以根据更新，我们不能在服务器端有一个默认的字符集定义配置。“头值必须是百分比编码的UTF-8”规则从何而来？表示obs文本为“%x80 FF”。客户端在标题值中使用了iso-8859-1字符，现在是否认为它们已损坏？服务器应该对标头值进行百分比解码吗？@jamshid（答案更新）HTTP标头中的8位字符从未真正得到支持，假设使用ISO-8859-1，这意味着只能访问该代码页较低的127个字符（巧合的是，这是与US-ASCII相同的代码页/编码）。总共127个字符，减去控制字符，就有95个。减去分隔符（HTTP字段值中的特殊含义）您可以在字段值中有效地使用77个字符来表示有意义的值。

   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)

   Historically, HTTP has allowed field content with text in the
   ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
   through use of [RFC2047] encoding.  In practice, most HTTP header
   field values use only a subset of the US-ASCII charset [USASCII].
   Newly defined header fields SHOULD limit their field values to
   US-ASCII octets.  A recipient SHOULD treat other octets in field
   content (obs-text) as opaque data.