zoukankan      html  css  js  c++  java
  • html 等页面防止中文出现乱码的终极解决方案

    网页UTF-8中文乱码问题解决方法

    网页UTF-8中文乱码问题解决方法只有经过多方面测试的东西才有质量的保证和说服力,之前一直都是在本地做开发,经过本地测试也是通过的,但一发布到远程服务器上就问题百出了,比较头疼的就是中文乱码的问题.

    如果把网页都设成charset=gb2312的话,显示中文没什么问题,但是用ajax返回来的却是乱码,上网搜了一下解决方法,说是在返回的信息流前加上一句header("Content-Type:text/html;charset=GB2312");就行了,这个办法也确实行得通,然后我也没深究了.

    但一放到国外的免费空间一测试,页面还是显示中文,但ajax返回的却是乱码,搞了好久都不行,然后还是继续上网搜解决方案,看到有的说把全站都设为UTF-8编码就行了。那就试试呗,结果还是不行,连普通的页面都显示乱码了,shit,我再看看人家yahoo的网页,不也设成utf-8吗,为何人家就能老老实实的显示中文而我的就不行呢????

    后来终于被我找到了原因,尽管我确实是给网页加上了charset=utf-8,但我保存的时候没有注意到这个文件是用非utf-8编码来保存的,所以就会出现这种情况,改用utf-8编码保存后,问题就解决了。

    有许多朋友问过我,为什么在ASP里指定了codepage为65001还经常显示乱码.墨动在这里将这个问题详细解释一下,以免很多朋友再走弯路,甚至排斥UTF-8.如果你还不知道UTF-8是什么东东,那才子建议你先去搜索一下UTF-8的相关资料吧.UTF-8编码之所以被越来越多的人接受甚至喜欢,肯定是有道理的,在WEB2.0盛行的今天,在大谈多浏览器兼容的同时,不得不想到字符编码不同所造成的乱码现象同样需要得到很好的处理.....在N年以前,IE6以下的所有版本,只要没有安装相应的字库,访问相关的页面都是会乱码的,例如,我是IE5 (Windows2000默认) 的版本,在没有安装IE繁体字库的情况下,访问任何繁体页面的网站都是会乱码的,当然前提是该页面采用了BIG5的Charset,而UTF-8作为一种国际编码就能很好的处理该问题,只要将页面存为UTF-8编码格式,再在页面上将codepage及charset全部定义为utf-8就可以在任何客户端浏览器中显示出完全正确的内容,完全不会乱码......

    好了,墨动这里以ASP页面为例,以一个实例来看具体操作吧:

    在这墨动推荐用Editplus来写代码,墨动也专门写过一篇Editplus的使用教程,有兴趣的朋友可以 点击这里 去看看.

    打开新建一个ASP页面,相信玩ASP的朋友都会留意到,许多下载的源码里,页面最上方一般都有一句:

    〈%@LANGUAGE="VBSCRIPT" CODEPAGE="936"%>前面的language应该不用多说了,vbscript就是ASP默认的脚本语言,其实完全可以不用写,写了好像还会影响页面执行效率,在这里我们先不讨论这个问题.

    后面的codepage就是关键了,目的就是告诉浏览器,此页面是何种编码,936代表是简体中文,

    而950代表繁体中文,65001就是我们今天说的UTF-8编码了.我们将936改成65001,整句如下:〈%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>再加上输出几个中文字看看能不能正确显示吧.〈%Response.Write "第一次测试UTF-8页面"%>OK,直接点击"保存",执行这个页面看看,如果不出意外,大家可能看到显示出的是 "一尾UTF-8页" 这几个字,中文有乱码的现象,什么原因呢?OK,请大家再点击最上面的 "文件" 菜单,选择"另存为",最下面一行有个编码,默认应该是ANSI的,请大家点下拉框,选择UTF-8,再点保存,再执行试试看,如果不出意外,乱得更厉害了,呵呵,晕了吧.别急,想想原因,因为我们做的页面是HTML返回的,

    以前我们写HTML时,看到body前面,也就是head里都有一句meta,应该是这样的:〈meta http-equiv="Content-Type" content="text/html; charset=gb2312">也就是指定页面以gb2312编码返回结果,一定要写在有返回结果输出的前面.

    大家都知道gb2312是简体中文吧,我们今天说的是UTF-8编码,我们就将gb2312改成UTF-8吧,全部代码如下:〈%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>〈meta http-equiv="Content-Type" content="text/html; charset=utf-8">〈%Response.Write "第一次测试UTF-8页面"%>再执行看看,嗯,这次正常显示了吧.......

    结论:采用UTF-8编码,除了要将文件另存为UTF-8格式之外,还需要同时指定codepage及charset.

    一般在页面中 明确写明 utf-8 编码外, 还是出现乱码的, 通常是由于 文件保存时 采用的是非 "UTF-8"编码, 特别是一些 "轻量级"的文字编辑器, 如notepad , editplus等等. 所以, 必须在 保存的时候必须保存为 utf-8 , 因为一般编辑器 默认保存的编码都是 ANSI ....

    =====================================================================
    为什么国内几个网站用GB2312反而更多些呢。

      我也对这个疑问进行了思考,我觉得。应该有3种原因:

      1. 国内这些网站本身历史也比较长,开始使用的就是 GB2312编码,现在改成 UTF-8(以前的网页)转换的难度和风险太大。

      2. UTF-8编码的文件比GB2312更占空间一些,虽然目前的硬件环境下可以忽略,但是这些门户网站为了减少服务器负载基本上所有的页面都生成了静态页,UTF-8保存起来文件会比较大,对于门户级别的网站每天生成的文件量还是非常巨大,带来的存储成本相应提高。

      3. 由于UTF-8的编码比GB2312解码的网络传输数据量要大,对于门户级别的网站来说。这个无形之间就要增大带宽,用GB2312对网络流量无疑是最好的优化。

      所以在新做站的情况下,建议还是选择UTF-8比较好。因为没有上面那些原因,兼容为上策

    codepage是服务器端的,charset是浏览器端的。两者必须匹配,才能避免乱码问题. 一般服务器端默认的 codepage都是UTF-8!!!

  • 相关阅读:
    Spyder的汉化
    Python,Pycharm,Anaconda等的关系与安装过程~为初学者跳过各种坑
    好了,我的第一篇博客!
    Xcode 最低要求和支持的 SDK
    python连接hive (安装impyla)的采坑之旅
    java泛型(泛型接口、泛型类、泛型方法)
    oracle命令查看表结构及表索引
    Linux环境下安装、配置Nginx1.14.2(CentOS Linux release 7.6.1810)
    Caffe入门随笔
    Gradient Boosting算法简介
  • 原文地址:https://www.cnblogs.com/bkylee/p/5394351.html
Copyright © 2011-2022 走看看