乱码的根本原因是字节和字符的问题(转)

1,为什么会出现乱码

     乱码的根本原因是字节和字符的问题。

     我们在大学学习c的时候,老师就有介绍字符和字节。

     字节由8个bit位表示,最早的编码是ASCII码,ASCII码是单字节的编码字符。因为单字节8个bit位对于中文字符和其他国家的字符来说根本不够用,需要更多的bit位来表示字符。我们现在常见的编码有GBK,BIG5,GB2312,UTF-8,通过编码映射表可以确定bit位和字符之间的映射关系。

    一个应用从服务端把需要展现的文字换成一段字节流传输给浏览器,浏览器把字节流组装字符展现的过程一般是这样(应用的编码是GBK):

    服务端:String text->getBytes("GBK")->byte[] bytes

    浏览端:byte[] bytes->new String("bytes","GBK") ->String text

   如果字节流处理的转换过程使用编码不一致就会出现乱码问题。

2,常见的乱码现象

    a,提交表单的时候出现乱码(页面编码和服务端编码不一致)

      页面是jsp的时候,会经常出现的问题,这个比较容易发现和修改,只要改下jsp文件的头就可以了。

      <%@ page contentType="text/html;charset=GB2312" language="java"  %>

    b,系统之间接口调用出现乱码(如果两个应用的编码格式不一致,get和post方式都是会出现乱码问题的)

       今天遇到一个问题,系统A调用我们的http接口他们提交过来的数据是乱码,主要是因为两个系统的编码格式不一致。我们的应用是GBK,对方的是UTF-8。

       解决方法是:

           需要他们重新指定下http request的编码格式。

   c,和前端交互的时候容易出现乱码(同一个应用get方式)

       页面脚本传种中文到后台的时候会出现乱码,而且中文编码是不同的浏览器有各自的实现,后端想用 new String(“乱码”.getBytes(“GBK”),”UTF-8”)这种方式  

       去还原字符,最后得到是问号。

        前端来说最简单的解决方式是用js对页面上传输到后台的中文进行encodeURI编码,传到服务端如果是进行decode。

      (tomcat默认会先进行一次decode,所有有时候js会对中文进行2次编码)

       另外一种get方式乱码的解决方式是修改容器的encodingURI来实现。

       jboss : 修改 /server/default/deploy/jbossweb.sar/server.xml              

<Connector port="6666" address="${jboss.bind.address}"

  maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

  enableLookups="false" redirectPort="8443" acceptCount="100"

  connectionTimeout="20000" disableUploadTimeout="true" <span style="color: #ff0000;">URIEncoding="GBK"</span>/>

   tomcat:/conf/server.xml

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1"

    redirectPort="8443"

    URIEncoding="UTF-8" />

 

  

 

 

                 

 

       

    https://www.ibm.com/developerworks/cn/java/j-lo-chinesecoding/

http://www.cnblogs.com/iusmile/archive/2012/06/01/2531262.html

时间: 2024-09-17 03:50:28

乱码的根本原因是字节和字符的问题(转)的相关文章

字节,字符,Unicode及Web编码

1. 字节 字节是一个具体的概念,它表示的就是实实在在的数据,这里之所以从它开始说起,是因为在与计算机相关的数据描述中,它是基本单位(与比特位是等价的).8 位二进制的比特位为 1 个字节,比如: 0010 1101 方便些写成 16 进制: 2D 这里需要强调的是,字节本身是不具有任何意义的东西.它仅仅是数据,或者,也可以说,它仅仅是数字.就像你看到一堆单纯的数字,比如"1 4334 332 2129 98 212",没有任何意义. 所以,自然地,原始的字节数据,需要在特定的上下文环

Java IO: 字节和字符数组

原文链接  作者: Jakob Jenkov   译者:homesick 内容列表 从InputStream或者Reader中读入数组 从OutputStream或者Writer中写数组 在java中常用字节和字符数组在应用中临时存储数据.而这些数组又是通常的数据读取来源或者写入目的地.如果你需要在程序运行时需要大量读取文件里的内容,那么你也可以把一个文件加载到数组中.当然你可以通过直接指定索引来读取这些数组.但如果设计成为从InputStream或者Reader,而不是从数组中读取某些数据的话

myeclipse javadoc时候乱码-编码 GBK 的不可映射字符

1,在项目列表中按右键,选择Export(导出),然后在Export(导出)对话框中选择java下的javadoc,提交到下一步.在Javadoc Generation对话框中有两个地方要注意的:javadoc command:应该选择jdk的bin/javadoc.exedestination:为生成文档的保存路径,可自由选择.按finish(完成)提交即可开始生成文档.   2,用菜单选择:File->Export(文件->导出),剩下的步骤和第一种方法是一样的.   3,选中要生成文档的

JS按字节截取字符长度实例_javascript技巧

* * 处理过长的字符串,截取并添加省略号 * 注:半角长度为1,全角长度为2 *  * pStr:字符串 * pLen:截取长度 *  * return: 截取后的字符串 * 复制代码 代码如下: function autoAddEllipsis(pStr, pLen) {     var _ret = cutString(pStr, pLen);     var _cutFlag = _ret.cutflag;     var _cutStringn = _ret.cutstring;   

java-Android系统socket通信字节乱码。

问题描述 Android系统socket通信字节乱码. 编写了android socket通信的软件,可以和主机通讯互相收发数据.但是一个字节的数据超过0x80就会乱码,也就是说如果数据小于128,那么正常超过就会乱码.请问这是哪里有问题.我确认硬件没有问题,换了设备也是可以的. public class Tcp40Activity extends Activity { /** Called when the activity is first created. */ Button BnSend

Java基础,字节字符

(一)"字节"的定义 字节(Byte)是一种计量单位,表示数据量多少,它是计算机信息技术用于计量存储容量的一种计量单位. (二)"字符"的定义 字符是指计算机中使用的文字和符号,比如1.2.3.A.B.C.~!·#¥%---*()--+.等等. (三)"字节"与"字符" 它们完全不是一个位面的概念,所以两者之间没有"区别"这个说法.不同编码里,字符和字节的对应关系不同: ①ASCII码中,一个英文字母(不分

python-Python中文字符输出乱码的问题

问题描述 Python中文字符输出乱码的问题 我有一个文本 你好,中国 然后使用Python发现是乱码 f = open('file.txt') print(f.readlines()) 结果如下: ['xe4xbdxa0xe5xa5xbdxefxbcx8cxe4xb8xadxe5x9bxbd '] 怎么让程序自动打印出中文结果? 解决方案 import urllib 然后 urllib.quote('zhongwen') 解决方案二: [搬家][Python][Windows]Windows

关于ORACLE和MYSQL中文字符乱码的根源剖析

关于数据库的字符集问题一直都是一个比较恶心的问题,如果不了解其实质可能一直 都搞不清楚这个问题的根源,只能出了问题去度娘,这里我打算兼容ORACLE和MYSQL对字符集 的处理来描述乱码出现的情形和如何防止乱码问题出现的可能,本文只用UTF-8和GBK为 例子进行描述,请大家先记住'去'这个字的UTF8和GBK编码,因为整个文章将用'去'字为 例子进行讲述 GBK     UTF8   中文 C8A5    E58EBB  去 同时整篇文章数据库DATABASE端的字符集始终为UTF8 一般来讲

JSON数据乱码问题

背景 程序员一提到编码应该都不陌生,像gbk.utf-8.ascii等这些编码更是经常在用,但时不时也会出个乱码问题,解决这个问题的方法大部分都是先google和baidu一下,最后可能在某个犄角旮旯里找到一点信息,然后就机械的按部就班的模仿下来,结果问题可能真就迎刃而解了,然后就草草了事,下回遇到相似的问题,可能又是重复上面的过程.很少有人有耐心去花精力弄明白这写问题的根本原因,以及解决这些问题的原理是什么.这篇文章就是通过一个实际案例,试着去讲清楚什么是编码,乱码又是怎么产生的,以及如何解决