时间:2021-07-01 10:21:17 帮助过:32人阅读
也许是apache的配置问题吧,记得apache配置中有字符集的设置的
又来了?
windows下任何浏览器下无任何问题。这话说的太武断!
这是 XP 360极速浏览器的截图
我不否认 IE 中为没有问题
这是因为 IE 有强大的字符集识别功能,完全可以忽视 Content-Type: text/html; charset 的影响
这就是网景倒闭的原因之一。
而那些在网景倒闭时公布的浏览器代码(10余兆c程序)基础上建立起来的各种浏览器,由于微软专利的原因,是无法解决这个问题的
当然这是题外话,不在讨论的序列中
你还是要找到在哪里会有 charset=gbk 的
不要过分相信工具软件,最好手工逐行查找。毕竟配置文件也就哪几个
但也不排除你而外安装了什么插件,造成了这种情况
此问题在我本机上完美重现
只要是login.html保存为utf-8编码无BOM,必定乱码。保存时保留BOM,侧无乱码。用UltraEdit反复测试多次,均如此。
关键是你以前的项目有没有这种情况! 如果没有那就是代码问题,如果也有,那可能是服务端问题、操作系统问题或者压根就是你代码输入的有错误(原先sql语句里错了一个字母,折腾一天,因为觉得自己不能犯小错误,实际上还是犯了!)
没什么实质性的东西,我的一点建议,主要是看看到底是代码原因,还是运行环境的原因!
此问题在我本机上完美重现
只要是login.html保存为utf-8编码无BOM,必定乱码。保存时保留BOM,侧无乱码。用UltraEdit反复测试多次,均如此。
检查一下nginx.conf配置文件?有没有gbk?
又来了?
windows下任何浏览器下无任何问题。这话说的太武断!
这是 XP 360极速浏览器的截图
此问题在我本机上完美重现
只要是login.html保存为utf-8编码无BOM,必定乱码。保存时保留BOM,侧无乱码。用UltraEdit反复测试多次,均如此。
不要干扰人家的判断
$url = 'http://parttime.wengege.com/h/login.html';$s = file_get_contents($url, false, null, 0, 10);//echo bin2hex($s); //3c21444f435459504520$url = 'http://parttime.wengege.com/h/test.html';$s = file_get_contents($url, false, null, 0, 10);echo bin2hex($s); //efbbbf3c21444f435459
$url = 'http://parttime.wengege.com/Public/js/search.js';
$s = file_get_contents($url, false, null, 0, 10);
echo bin2hex($s); //2f2fe6a0b9e68daee7b1
/Public/js/search.js无BOM头
BOM 头对于浏览器而言,至多会影响到显示样式,而不会造成乱码
这可说不说,服务器返回是gbk,utf8这样的编码,如果没有BOM头来说明,是按gbk显示还是按utf8显示?明显这里是按gbk来显示的。
又来了?
windows下任何浏览器下无任何问题。这话说的太武断!
这是 XP 360极速浏览器的截图
我不否认 IE 中为没有问题
这是因为 IE 有强大的字符集识别功能,完全可以忽视 Content-Type: text/html; charset 的影响
这就是网景倒闭的原因之一。
而那些在网景倒闭时公布的浏览器代码(10余兆c程序)基础上建立起来的各种浏览器,由于微软专利的原因,是无法解决这个问题的
当然这是题外话,不在讨论的序列中
你还是要找到在哪里会有 charset=gbk 的
不要过分相信工具软件,最好手工逐行查找。毕竟配置文件也就哪几个
但也不排除你而外安装了什么插件,造成了这种情况
ob_start();
header("Content-Type: text/html; charset=gbk,utf8");
echo "测试文本";
ob_flush();
?>
保存为无BOM和有BOM,就会乱码和正常
检查一下nginx.conf配置文件?有没有gbk?
又来了?
windows下任何浏览器下无任何问题。这话说的太武断!
这是 XP 360极速浏览器的截图
也许是apache的配置问题吧,记得apache配置中有字符集的设置的
经测试,保存为utf-8 +bom 可以解决此问题。但原因何在呢?有人能够解释么?
header("Content-Type: text/html; charset=gbk,utf8");
是发出回应的头
get_headers(url)
得到的 Content-Type: text/html; charset=gbk,utf8
是服务器的响应
我什么时候说过请求啦?
相应的头不是你设置的吗?放在配置文件里自动发出,也是你设置的
我一点都没搞混,而是你自己忙晕了!
你换了服务器就正常了,这恰恰表示了出问题的服务器的配置有问题!
以前的相同的代码,还有其它一些html代码,都是没有bom头的,也没有乱码。
关键是你以前的项目有没有这种情况! 如果没有那就是代码问题,如果也有,那可能是服务端问题、操作系统问题或者压根就是你代码输入的有错误(原先sql语句里错了一个字母,折腾一天,因为觉得自己不能犯小错误,实际上还是犯了!)
没什么实质性的东西,我的一点建议,主要是看看到底是代码原因,还是运行环境的原因!
此问题在我本机上完美重现
只要是login.html保存为utf-8编码无BOM,必定乱码。保存时保留BOM,侧无乱码。用UltraEdit反复测试多次,均如此。
其实谁也没有找到原因,只是观察到一些现象
Content-Type: text/html; charset= gbk,utf8
这个 gbk 才是真正的原因,只不过你不肯需找他的来源罢了
为什么发出gbk,不在服务器上翻,估计谁也没法说出具体原因。
xuzuning版主正解!
问题原因找到,是nginx此网站配置时使用了charset gbk,utf-8 这样设置了。去掉gbk就ok了。所以乱码解决。
是我在thinkphp网站有一个网友和我碰到同样问题。提醒我上服务器上查看配置文件解决的。
header("Content-Type: text/html; charset=gbk,utf8");
是发出回应的头
get_headers(url)
得到的 Content-Type: text/html; charset=gbk,utf8
是服务器的响应
我什么时候说过请求啦?
相应的头不是你设置的吗?放在配置文件里自动发出,也是你设置的
我一点都没搞混,而是你自己忙晕了!
你换了服务器就正常了,这恰恰表示了出问题的服务器的配置有问题!
当然,版主也同时提醒我看服务器上配置文件了。xu大,早点提醒我就好了。
如果是ngix charset ?置??,?甚???folder放就可以呢? ??folder??也是用同一?charset的。所以之前才想是不是有.htaccess影??前folder。就是因???,?我?有?得是default charset?置??。
你说你的文件确实保存的是UTF8,好像每个页面的mate标签是可以设置浏览的编码的,会不会是设置了GBK
或者是后台代码输出的字符是GBK?
你用的是cms么?是不是从gbk转成utf8的
其实我对php不熟悉,也只是猜测 猜测哈