求助：Chrome无法发送包含特殊字符（如瑞典语ÅÄÖ）的请求头

首先，这个问题的核心原因是Chrome严格遵循HTTP/1.1规范（RFC 7230），该规范要求HTTP请求头的字段值只能包含US-ASCII范围内的字符（不包含ÅÄÖ这类非ASCII特殊字符）。当检测到不符合规范的字符时，Chrome会直接丢弃整个请求头字段，这就是你看到SomeHeader消失的原因。而Firefox和IE11则放宽了这个限制，直接以UTF-8编码发送非ASCII头，所以服务器能正常接收。

可行的解决方案（无需修改服务器） #

既然你不能修改服务器，且要求请求能被服务器同等解析，我们可以按照RFC 2047的标准对请求头值进行编码——这是HTTP标准中允许的非ASCII头传输方式，大部分服务器都支持自动解码（包括原本能处理UTF-8头的服务器）。

具体操作步骤：

1. 将含特殊字符的头值用UTF-8编码后进行Base64转换
2. 用=?UTF-8?B?[Base64内容]?=的格式包裹编码后的内容

以你的示例中的ÅÄÖ为例：

• ÅÄÖ的UTF-8 Base64编码是w4TDpMO2
• 编码后的头值为=?UTF-8?B?w4TDpMO2?=

修改后的代码如下：

$.ajax({
  type: 'POST',
  url: '/echo/html/',
  headers: {
    "SomeHeader": "=?UTF-8?B?w4TDpMO2?=", // 现在Chrome会正常发送这个头
    "SomeOtherHeader": "ABC"
  },
  data: { foo: 'bar', delay: 1 }
})
.fail(function(data){
  alert("Error!");
})
.done(function(data) {
  alert("Success!");
});

适配你的multipart/form-data场景 #

这个方法完全适用于你的实际场景：你只需要对包含特殊字符的请求头字段进行上述编码即可，不需要修改Content-Type中的boundary部分。服务器如果原本能解析IE/Firefox发送的UTF-8头，通常也能自动解析RFC 2047编码的内容，还原出原有的特殊字符。

为什么设置Content-Type无效？ #

Content-Type头控制的是请求正文的编码格式，而请求头本身的编码规则是由HTTP协议单独规定的，所以修改Content-Type不会影响请求头的处理逻辑。

内容的提问来源于stack exchange，提问作者smoksnes