无论浏览器编码怎么改变,服务端返回的内容都是UTF-8编码
猜测上述会乱码的title和页面底部都是以UTF8中文写在HTML源码中的,HTML源码由浏览器渲染,故浏览器编码设置不是UTF8时就会乱码。
而页头、页面主体的内容是以utf8串(如\u4e2d\u56fd\u5de5\u5546\u94f6\u884c\u7535\u5b50\u94f6\u884c)的形式写在script标签中,或者从服务端ajax请求得到的
浏览器只负责Javascript语法解析及执行,不负责JS输出中文的编码展示,故,js output里的中文显示跟浏览器的Charset设置无关
求助1. 上面只是我的猜测,我分别用browser javascript charset render在google上搜索了半天,没找到官方权威的说法来证实我的猜测,求前端专家指点迷津,给个权威的链接。
2. 切换成韩文为什么js也不正常了呢?是韩文编码环境下,script标签里的js语法解析出错了吗?
ringa_lee2017-04-10 12:46:34
打开 Safari 的 Web检查器,切换到 问题 标签。然后修改浏览器的编码设置,会观察到当切换为韩文的时候,加载 .js 会有很多出错信息。而 GBK / Big5 / Shift JIS 不会。因此估计是 ISO 2022-KR 编码“入侵”了 ASCII 的前 127 个字符造成。
Google 了一下,发现韩文编码典型的一个做法是将反斜杠“\”转换为韩元字符“₩”。因此,加载一个充斥着反斜杠的 .js 自然就会出错了。
更新前面说的不完全正确,因为 Shift JIS 也占用了 \,BIG5 也使用了正常 ASCII 字符的编码。进一步观察 Web检查器,发现当编码设置为 GBK / Big5 / Shift JIS,实际加载的 .js 还是 UTF-8 的,而换成 ISO 2022-KR 则不然。这应该是浏览器具体实现的问题。
迷茫2017-04-10 12:46:34
哈哈,作为微博BigPipe服务端的实现者,我从来没想过诸位会用这么变态的方法测试……
我在chrome下重试了以上的实验,切换各种编码都只是导致页脚乱码,其他区域都正常显示,韩文没有出现头尾乱码页面空白的情况,这个问题可能跟safari对韩文编码的支持有关系。
其实原因前几位都说过了,使用bigpipe是通过回调js的方式做客户端渲染,输出的内容以json编码存在。JSON要求输出unicode,而浏览器中的js引擎负责将unicode字符转换成页面对应的编码,所以无论如何转换都不会乱码。
而页脚的html则是通过后端实现中的框架模式直接写入页面中输出,所以会受到浏览器强制错误编码的影响导致乱码。
至于safari的韩文,这个不敢妄言,毕竟对韩文编码不熟悉。值得一提的是,微博的框架JS是经过打包程序输出,去除了所有的注释,理论上不会包含有大于0x7F的字符。由于我在chrome下没有重现韩文的问题,所以暂时没法定位问题。
PS:
后端已经在鸟哥@laruence 的带领下实现了并行输出,目前正在逐步改造和测试中,完全并行化的输出请拭目以待:D
ringa_lee2017-04-10 12:46:34
基本上楼上两位已经分析清楚了,新浪微博使用了类似 Bigpipe (并不是真正的Bigpipe,因为没有做到后端的多线程) 的页面加载方式。为的是减少用户等待时间,提高加载速度。在步骤 5 中没有出现乱码的那部分内容是由 javascript 动态加载的 DOM 结构,这部分内容的编码在浏览器接收 javascript 代码的时候已经确定了。想弄清楚问题可以试试看找找 Bigpipe 的资料。
迷茫2017-04-10 12:46:34
问题的原因 是JSON将中文字符转成了unicode编码,不管浏览器被设定为什么编码,都可以转换成你设定的编码, 除非不能转换? 比如字符集不支持该字符。或者浏览器不支持的字符集。
你可以研究研究JSON的协议: http://json.org/
PHP中文网2017-04-10 12:46:34
很简单,有两点:
<script type="text/javascript" src="test.js" charset="gb2312"></script>