乱码

已完成 AJAX 输入验证 和 AJAX 数据管理器 。 在此基础上改为 jQuery 输入验证 和 jQuery 数据管理器 后，POST 方式提交出现乱码。 网上查的资料一边倒的说法是“在参数中添加 contentType: "application/x-www-form-urlencoded; charset=UTF-8" 项”，尝试发现无效。 初步调查发现： 原有的 form GET 、POST 提交例子无乱码。 原有的 URL 提交例子无乱码。 原有的 AJAX GET 、POST 提交例子无乱码。 jQuery AJAX GET 提交无乱码。 jQuery AJAX POST 提交有乱码。 经 Firebug 调试查得： jQuery 在 AJAX POST 时默认向 contentType 中添加了“charset=UTF-8”； 在服务器端用 request.getEncodingCharset() 取到“UTF-8”，得以证实。 jQuery 在 AJAX GET 时不发送“charset=UTF-8”； 在服务器端用 request.getEncodingCharset() 取到 null ，得以证实。 再查资料和检查程序，发现原有的 form 提交例子、URL 提交例子和 AJAX 例子并不发送“charset=UTF-8”； 在服务器端用 request

【转】JSP中request.getParameter()乱码问题 博客分类： java中的字符编码 第一，存文件必须以一种编码存；读文件也必须以一种编码读，如不特别设置，去系统默认的编码，中文windows为GBK编码。 从.java->.class过程是，先编写.java文件并按莫种编码方式保存，然后用javac方法编译此文件，注意如.java没按系统默认编码保存则要带encoding参数指明实际编码，否则出错，生成的.class文件存为系统默认编码。 从.jsp->.java->.class，先存为某种编码的.jsp文件，然后tomcat根据pageEncoding读取并转化为servlet存为系统默认编码，然后同上面.java->.class过程。 第二，IDE的encoding为对系统下文件打开的解码方式或保存的编码方式。特例：如果.jsp文件有<%@ page language="java" pageEncoding="UTF-8"%>，则eclipse会自动存为UTF-8方式，不管eclipse的encoding是什么，这也是eclipse的聪明之处。 第三， pageEncoding="UTF-8"表示此文件的编码方式，必须与此文件存储方式一致（所以eclipse会首选根据它来存文件），tomcat根据这个来读此.jsp文件并编译为servlet。

前提 ： 1数据库和表都是utf8_general_ci格式 2程序代码也是utf-8格式，且使用了mysql_query("set names utf-8"); 及 htmlentities ENT_QUOTES,'utf-8' 结果： 即使是这样 插入数据库汉字仍然在数据库中看到的是乱码，但是页面上显示的好的。 原因及解决方法： 原因可能是mysql在安装的时候的设置不对。 解决方法，你无法改变供应商重新安装mysql的话，只能接受这样的事实。就让它乱码吧， 需要导出数据的话可以自己手写代码用csv或者xls导出。 实际上后来发现以下解决方案， phpmyadmin里MySQL字符集:cp1252 West European (latin1) ，解决乱码问题 使用虚拟主机空间上的phpmyadmin操作数据库的时候，如果看到phpmyadmin首页上显示的MySQL 字符集为cp1252 West European (latin1)，当我们导入数据时就会出现乱码，解决的方法是： 在phpmyadmin首页的右边有个Language选项，把默认的中文 - Chinese simplified-gb2312改成 中文 - Chinese simplified，则左边的MySQL 字符集会变成UTF-8 Unicode (utf8) ，乱码问题得到解决！ 如果数据库编码没有问题，则

先讲个小故事，虽然跟主题有点不太相关哈： 唐朝诗人李绅，身为官员，脾气暴躁，瞧不起信教的，尤其鄙视装逼之僧人，动不动就对他们拳脚相加。曾扬言：“我可以接见他们，要能答出来还好，要是答不出来，我弄死他！”有一回一个和尚来跟他宣传因果报应，李绅问：“阿师 从哪里来，到哪里去呢 ？”僧答：“贫僧 从来处来，到去处去 。”李绅当时就急了， 撸起袖子，亮出了手腕：“我去年买了个表！” 来自知乎问答“ 古人是如何「装逼」的？ ”，略有改动。 String到哪里去？ 有了前面僧人的教训，在这里就不故弄玄虚了，应该说String的去处还是蛮确定的，那就是到byte[]中去，方式就是通过getBytes这一方法。 new String与getBytes 如果说new String(byte[], encoding)是从byte[]到String的过程，那么getBytes(encoding)则正好与之相反：它是从String到byte[]的过程。 或许我们应该说，它从去处来，又到来处去。 编码的逆转 显然，我们一直在说，String也不过是一堆byte，getBytes的过程不过是UTF-16编码的byte[]再转回去其它编码的byte[]的过程。无论是new String还是getBytes，不过都是在玩编码的转换而已。 从上图中可以看出String作为桥梁

在上一篇中，探讨了文件名编码以及非文本文件中的文本内容的编码，在这里，将介绍更为重要的文本文件的编码。 混乱的现状 设想一下，如果在保存文本文件时，也同时把所使用的编码的信息也保存在文件内容里，那么，在再次读取时，确定所使用的编码就容易多了。 很多的非文本文件比如图片文件通常会在文件的头部加上所谓的“magic number（魔法数字）”来作为一种标识。所谓的“magic number”，其实它就是一个或几个固定的字节构成的固定值，用于标识文件的种类（类似于签名）。比如bmp文件通常会以“42 4D”两字节开头。 又比如Java的class文件，则是以四字节的“ca fe ba be”打头。（咖啡宝贝？） 即便没有文件后缀名，根据这些信息也是确定一个文件类型的手段。 附：关于用Notepad++查看十六进制的问题，这是一个插件，如果没有装，菜单--插件--plugin manager--available--HEX-Editor，装上它。装上后，它通常在工具栏的最右边，一个黑色的大写的斜体的“H”就是它。单击它可以在正常文本与16进制间切换。要进一步查看二进制，在文本区，右键--view in--to binary。 没有编码信息 那么，对于文本文件，有没有这样的好事呢？可以简单建立一个文本文件“foo.txt”，里面输入两个简单的字符，比如“hi”，保存，然后再查看文件的大小属性

在前面的 字符集编码系列 中，已经探讨了几大主要的字符集编码。在此基础之上，这里将进一步探讨编码的应用及乱码的根源，我们先从基本的文件说起。 文件 文件（内容）就是字节序列。文本文件也是文件，所以它也是字节序列。 文件名与文件内容 通常说到文件时，指的是文件内容，但文件还有文件名，文件名与文件内容是分开存储的。 你可以在硬盘上新建一个文件，它的大小为0.如下： 但它是有文件名的，比如上述的“新建文本文档.txt“，保存这些名字自然也要占用空间，只不过它与文件内容是分离的。 这些由操作系统的文件系统模块负责。 文件名 是一段文本，因此它会涉及字符集编码。 文件内容 则视情况而定： 1. 文本文件，肯定会涉及字符集编码。 常见的比如txt，html，xml以及各种源代码文件等等。 2. 非文本文件，比如图片文件jpg，gif之类，自然跟字符集编码无关了。 有些文件，比如Word的doc之类的，混合了图片跟文本在里面，可以想像，其中的文本部分自然也会牵涉到字符集编码的问题，只不过这些编码不由我们去控制，我们通常也无须去关心。 文件名编码 文件名是一串文本，因此它必然涉及某种字符集编码，只不过这种编码是由操作系统决定的，我们无权干预。 那么，它用的是什么编码呢？在Windows下，可以简单做些实验。我们可以弄些奇怪的文件名如“★★★★.txt”，如下： 结果也能保存

编码问题一直困扰着开发人员，尤其在 Java 中更加明显，因为 Java 是跨平台语言，不同平台之间编码之间的切换较多。本文将向你详细介绍 Java 中编码问题出现的根本原因，你将了解到：Java 中经常遇到的几种编码格式的区别；Java 中经常需要编码的场景；出现中文问题的原因分析；在开发 Java web 程序时可能会存在编码的几个地方，一个 HTTP 请求怎么控制编码格式？如何避免出现中文问题？ 几种常见的编码格式 为什么要编码 不知道大家有没有想过一个问题，那就是为什么要编码？我们能不能不编码？要回答这个问题必须要回到计算机是如何表示我们人类能够理解的符号 的，这些符号也就是我们人类使用的语言。由于人类的语言有太多，因而表示这些语言的符号太多，无法用计算机中一个基本的存储单元—— byte 来表示，因而必须要经过拆分或一些翻译工作，才能让计算机能理解。我们可以把计算机能够理解的语言假定为英语，其它语言要能够在计算机中使用必须经过一次 翻译，把它翻译成英语。这个翻译的过程就是编码。所以可以想象只要不是说英语的国家要能够使用计算机就必须要经过编码。这看起来有些霸道，但是这就是现 状，这也和我们国家现在在大力推广汉语一样，希望其它国家都会说汉语，以后其它的语言都翻译成汉语，我们可以把计算机中存储信息的最小单位改成汉字，这样 我们就不存在编码问题了。 所以总的来说

同事请求帮忙，说程序好好的，忽然就在提交表单的时候乱码了。本着助人为乐的精神，去看了一下。了解了一下情况后开始调试。 发现请求提交到后台的时候中文已经变成了乱码。检查web.xml, 发现有编码转换的Filter, 检查页面，编码是UTF-8，检查request的编码，也是UTF-8，编码都是一致的。就是提交到后台的时候乱码。 试着把取到的乱码进行转码，发现如下的情况可以正常获得中文： <!-- lang: java --> new String(name.getBytes("iso-8850-1"), "utf-8") 接近崩溃的边缘了。再查Post到后台的数据，中文也是UTF-8的编码。 开始百度，有人说在jQuery中设置ajaxSettings的contentType属性，在后面加上";charset=utf-8" <!-- lang: js --> ajaxSettings: { url: ajaxLocation, isLocal: rlocalProtocol.test( ajaxLocParts[ 1 ] ), global: true, type: "GET", contentType: "application/x-www-form-urlencoded;charset=utf-8", processData: true, async: true, ......

本文转载自 http://blog.csdn.net/tanyit/article/details/7747249 暂未做实验验证，请知晓。 目录 一.JSP 编码 contentType 和 pageEncoding 各自对应编码文件 二.JSP 编译过程 三 举例 内容 一.JSP 编码 contentType 和 pageEncoding 各自对应编码文件 <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="GBK" %> pageEncoding = "GBK" 告诉JVM 这个jsp本身采用的"GBK"编码, JVM默认iso-8859. contentType里的 charset = utf -8是指示页面的输出方式为utf-8 pageEncoding是jsp文件本身的编码 　 contentType的charset是指服务器发送给客户端时的内容编码 二.JSP 编译过程 JSP要经过两次的“编码”， 第一阶段会用pageEncoding， 第二阶段会用utf-8至utf-8， 第三阶段就是由Tomcat出来的网页， 用的是contentType。 第一阶段是jsp编译成.java，它会根据pageEncoding的设定读取jsp

在XX项目中解决android webkit处理汉字编码问题的总结 问题： 服务器通过302重定向方式发送给客户端重定向地址，地址中的汉字采用原数据方式发送，没有经过任何编码。因为其中存在汉字，所以在android端经过webkit解码编码之后，最终无法正常在服务器端请求正确数据。Android中默认使用utf-8编码。 Android在framework中解析http信息，Request.java的函数readResponse通过AndroidHttpClientConnection.java的函数parseResponseHeader解析response的header部分。 存储数据使用的是org.apache.http.util.CharArrayBuffer中的CharArrayBuffer。使用SessionInputBuffer的readline来读取一行，进行解析。 我们主要关心的是Location部分，因为重定向主要是通过Location的值重新去请求url。Android中也是这么做的，不会去html的body中解析标记A的herf。 读取的每一行都会被传入到Headers.java中进行解析。Location地址被转换为String存储到mHeaders[IDX_LOCATION]中。 在从CharArrayBuffer变成String的时候，有个值得注意的地方