IE 和 Firefox 不显示 UTF-8，而 Chrome 则显示
我正在使用 Zend 框架。我尝试通过对操作使用 Ajax 请求来验证表单：
$.ajax({
type: "POST",
url: URL_TO_ACTION,
data: DATA,
success: function(result,status,xResponse) {
var error = xResponse.getResponseHeader("error");
alert(error);
},
error: function(e){
alert(e);
}
});
在控制器中，我有一个操作来处理此问题：
public function validateAction(){
$response = $this->_response;
$response->setHeader(
"error","Hãy chọn một module"
);
}
在 IE 和 Firefox 中，它显示“Háy chá»n má»t Module”，而 Chrome 则显示“ Hãy chọn một module”
在布局中我确实有：
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
我在这里做错了什么？
I'm using Zend Framework. I try to validate a form by using an Ajax request to an Action:
$.ajax({
type: "POST",
url: URL_TO_ACTION,
data: DATA,
success: function(result,status,xResponse) {
var error = xResponse.getResponseHeader("error");
alert(error);
},
error: function(e){
alert(e);
}
});
In the controller, I have an Action for handling this:
public function validateAction(){
$response = $this->_response;
$response->setHeader(
"error","Hãy chọn một module"
);
}
In IE and Firefox, it says "Hãy chá»n má»t Module" while Chrome says "Hãy chọn một module"
In the layout I do have:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
What did I do wrong here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不要依赖 HTTP 标头来传输 ASCII 之外的任何内容。在实体主体中对错误消息进行编码。
长答案：
在我看来，这是 HTTP 标准的一个糟糕的领域。根据HTTP/1.1标准，
RFC 822 说，
因此，HTTP 标头是 ASCII。然而，在文档的前面，HTTP/1.1 是这样说的：
（4.2 说标题由 TEXT 组成）
任何八位位组序列都与 ASCII 不同，并且文本“仅当根据 ISO-8859-1 [22] 编码时才可以包含来自 ISO-8859-1 [22] 以外的字符集的字符”（对我来说）间接表明标头是 ISO-8859-1。然而，这并不比这句话的全部内容重要：
事实上，RFC 2047 为我们提供了一种将任何字符集中的任何字符串编码为 ASCII 的方法。 （RFC 2047 是电子邮件如何在主题行或发件人行中包含日语等内容的方式。）
现在是令人悲伤的部分：我认为没有任何主要浏览器实现 RFC 2047。正如您所见，Chrome 对待标头为 UTF-8，Firefox 为 ISO-8859-1。您可以以 RFC 2047 或类似的方式（例如 base64）发送它，并在 javascript 中对其进行解码，但此时，您也可以只在正文中发送它。
Don't rely on HTTP headers being able to transmit anything outside of ASCII. Encode your error message in your entity body.
The long answer:
This is, in my opinion, a sucky area of the HTTP standard. According to the standard for HTTP/1.1,
RFC 822 says,
So, thus, HTTP headers are ASCII. However, earlier in the document, HTTP/1.1 has this to say:
(and 4.2 says headers are composed of TEXT)
any octet sequence is not the same as ASCII, and the text "MAY contain characters from character sets other than ISO-8859-1 [22] only when encoded according" seems (to me) to suggest indirectly that headers are ISO-8859-1. However, that's less important than the whole bit of that sentence:
Indeed, RFC 2047 gives us a means to encode any string, in any character set, into ASCII. (RFC 2047 is how emails can contain things like Japanese in a Subject line or a From line.)
Now for the sad part: I don't think any major browsers out there implement RFC 2047. And as you've seen, Chrome treats headers as UTF-8, Firefox as ISO-8859-1. You could send it encoded in RFC 2047, or something simliar, like base64, and decode it in the javascript, but at that point, you may as well just send it in the body.
听起来很明显，但是您是否清除了浏览器缓存，或者尝试在 Ajax 请求中设置“cache: false”？
Sounds obvious but have you cleared your browsers cache, or tried setting "cache: false" in your Ajax request?
HTTP 标头值编码与页面的编码无关。
特别是，标头值通常限制为 ASCII，除非定义标头的规范表明适用 RFC 2047。通过字节膨胀（对于 ASCII 来说是正确的）将字节转换为相应的 Unicode 代码点将为您提供上面看到的 IE 和 Firefox 结果。
HTTP header value encoding has nothing to do with the encoding of your page.
In particular, header values are typically restricted to ASCII unless the spec defining the header says that RFC 2047 applies. Converting bytes to corresponding Unicode codepoints by byte-inflation (which is correct for ASCII) would give you the IE and Firefox results you see above.