我们在做网站时，偶尔浏览时会出现乱码,下面我们来分析一下：

今天，用javascript脚本做了一个ASP.NET页面中的菜单工具，保存为menuScript.js. 在页面中用<script language="javascript" src="http://img.sxsky.net/it/../js/MenuScript.js"></script>调用, 结果在运行中奇怪的现象发生了：页面中的汉字正常显示，可菜单中的汉字却显示为乱码。
   不用问，用膝盖想一想也是编码出了问题在该页面的“查看”-“编码”选项中切换utf-8和GB2312两种编码，结果页面中的汉字和菜单中的汉字交替变为乱码
   解决方法：配置文件中有编码设置：<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
   menuScript.js文件保存时有编码选项（可用Word打开此文件再另存，选择编码），只需保持这两处编码一样即可。
   为了更好的了解编码问题，在CSDN中找到了一篇这方面的文章，作者：fmddlmyy。在此转载一下,以供参考：
  谈谈编码
  谈谈编码#region 谈谈编码
   /**//*
   0、big endian和little endian
  　　big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时，究竟是将6C写在前面，还是将49写在前面？如果将6C写在前面，就是big endian。还是将49写在前面，就是little endian。
  　　“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，其中一个皇帝送了命，另一个丢了王位。
  　　我们一般将endian翻译成“字节序”，将big endian和little endian称作“大尾”和“小尾”。

  1、字符编码、内码，顺带介绍汉字编码
  　　字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码，为了处理汉字，程序员设计了用于简体中文的GB2312和用于繁体中文的big5。
  　　GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。
  　　GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。2000年的gb2312是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持gb2312，对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。
  　　从ASCII、GB2312、GBK到gb2312，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK到gb2312都属于双字节字符集 (DBCS)。
  　　有的中文Windows的缺省内码还是GBK，可以通过gb2312升级包升级到gb2312。不过gb2312相对GBK增加的字符，普通人是很难用到的，通常我们还是用GBK指代中文Windows内码。
  　　这里还有一些细节：
  　　GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。
  　　在DBCS中，GB内码的存储格式始终是big endian，即高位在前。
  　　GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBK和gb2312的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析：在读取DBCS字符流时，只要遇到高位为1的字节，就可以将下两个字节作为一个双字节编码，而不用管低字节的高位是什么。

  2、Unicode、UCS和UTF
  　　前面提到从ASCII、GB2312、GBK到gb2312的编码方法是向下兼容的。