编码

在进行JS开发过程中，尤其是在开发报表时，报表已集成到Web页面中，通过在页面传递参数至报表中时，会发现有时某些参数值，传递到报表中是显示为问号或乱码等等一系列不能正常显示的情况。 这是由于浏览器和报表服务器的编码不同，字符多次进行编码转换时出现错误导致字符的显示出现乱码，尤其是中日韩文和特殊字符更容易出现乱码问题。 以开发报表软件FineReport为例，在给报表服务器发送请求之前，对URL或者只对URL里面的参数名字和参数值，进行cjkEncode的编码，该方式兼容了各种不同的字符集，如ISO8859-1、 UTF-8、 GBK、 ENU_JP，尤其对中日韩文的处理采取了统一的方案。 javascript中FineReport字符转换原理 在给报表服务器发送请求之前，对URL或者只对URL里面的参数名字和参数值，进行cjkEncode的编码。源码如下： function cjkEncode(text) { if (text == null) { return ""; } var newText = ""; for (var i = 0; i < text.length; i++) { var code = text.charCodeAt (i); if (code >= 128 || code == 91 || code == 93) {//91 is "[", 93 is "

如何向mysql5数据库插入中文 ———— JAVA学习室( http://www.java3z.com ) 向mysql5数据库正常插入中文，操作如下： 1.把字符集设定为能支持中文的gbk(在my.ini文件中改) 2.把数据库的Client Characterset和Conn. Characterset的字符集都设定为gbk； SET character_set_client=gbk; SET character_set_connection=gbk; 之后再尝试向数据库插入中文，这时插入没有出错，但查询显示是乱码。最后再更改； SET character_set_results=gbk; 这样之后，所有的问题都解决了，能正常插入也能正常显示了。 如果还不正常，可以在创建数据库时指定编码gbk, 如下所示 (1) create database if not exists test default character set gbk; 注意：有些人可能会问，建立数据库表时候还没设置编码呢？其实，如果你容器编码是gbk的，则表也是gbk，如下设置表编码为gbk： CREATE TABLE IF NOT EXISTS test( test_id int auto_increment, test_name varchar(50) ) ENGINE=InnoDB DEFAULT

一、开始前的一些建议 1.不要相信任何用户输入或第三方数据来源，包括$_GET、$_POST（$_ FILES ）、 $_COOKIE 、 $_SERVER的部分参数 等。 2.HTML、PHP、MYSQL等使用统一的UTF-8编码。 3.数据库SQL构造时尽量使用'包裹参数。 4.参数对比时正确使用 === 和 == 。 5.尽量选择白名单而非黑名单式过滤。 二、关于SQL注入 1.SQL注入的产生原因 SQL注入的产生在于外界的输入改变了原本定义的SQL语意，譬如： 原本定义的SQL语意， $_GET['name'] = 'abc'; $name = $_GET['name']; SELECT * FROM `admin` where user_name = '$name'; 最终生成的SQL为，SELECT * FROM `admin` where user_name = 'abc'; 外界输入改变后的语意， $_GET['name'] = 'abc\' or \'a\'=\'a'; $name = $_GET['name']; SELECT * FROM `admin` where user_name = '$name'; 最终生成的SQL为，SELECT * FROM `admin` where user_name = 'abc' or 'a'='a';

注：由于两边同步的麻烦，更多更改及调整可参考我的网站： xiaogd.net 上的 字符集编码与乱码系列 ，已将字符集编码系列与乱码探源系列合并，更新及勘误等不再更新到这边。 许多时候，字符集与编码这两个概念常被混为一谈，但两者是有差别的，作为深入理解的第一步，首先要明确： 字符集 与 字符集编码 是两个不同层面的概念 charset是character set的简写，即 字符集 。 encoding是charset encoding的简写，即 字符集编码 ，简称 编码 。 与接口及接口实现的对比 可以把这两者与 接口 及 接口实现 做个对比： 从这里可以很清楚地看到， 编码是依赖于字符集的，就像代码中的接口实现依赖于接口一样； 一个字符集可以有多个编码实现，就像一个接口可以有多个实现类一样。 具体例子及规范用法 可以简单看两个例子，一个自于html文件，用的是charset： <meta http-equiv="content-type" content="text/html;charset=utf-8"> 另一个来自于xml文件，用的是encoding： <?xml version="1.0" encoding="UTF-8"?> 哪一种用法更规范呢？显然是后者，它更加准确地区分了字符集与编码的概念。 “charset=utf-8”容易让人误解为存在一种叫“UTF-8”的字符集

以下在 Python2.6和PyQt4.4.4 for Python2,6环境下讨论： Python中有两种有关字符的类型：Python string object和Python Unicode object。主要使用Python string object进行数据输入输出。 PyQt中与之相对应的字符有关类型是：QByteArray和QString。主要使用QString操作数据。 1. Python和PyQt中的类型对应 注意是类型相似，不是相等。 需要先了解编码：ascii、gb2312、big5，这些是各国自己文字不同的编码；unicode，国际通用编码，就是穷尽这个世界上所有的文字，给 每个文字编一个，又分utf-8方案--最常使用的128个英文字母用一个字节来表示，而中文使用三个字节来表示，utf-16方案--其中英文和中文都 使用两个字节来表示，而其它字符采用四个字节，utf-32方案--所有的文字都用四个字节来表示。 unicode就可用来作为各种独立编码如ascii、gb2312、big5的转换中介。 Python中gkb == gb2312。 1）Python string object可以理解为一个接一个字节（byte，8位）的字节组，至于表示什么编码，与表示文字有关，如："python string"，"中文"。注意它是有不同编码区分的！

前面说到，文本文件中没有编码信息，导致了各种混乱，那么，最关键的就是要指定好所用的编码信息。具体地讲，有以下一些途径。 变相引入 什么是变相引入呢？其实本质与前面提到的一些“文件头”信息是类似的。 xml 我们来看看xml文件的例子，你通常能在最开始看到这样的一行： <?xml version="1.0" encoding="UTF-8"?> 那么这里面，encoding指明的就是所用编码的信息了。 可是，等等！！为了得到这一编码信息，我得先读取这一文件；可要正确读取文件，我又要先知道编码信息！ 这成了一个鸡生蛋，蛋生鸡，又或者说是先有鸡还是先有蛋的问题了。 怎么破呢？考虑这一行信息所有字符都是ASCII中的字符，那么我们可以先使用最基础的ASCII去读取它开头的一些信息，获取到这一编码信息后，再次用这一编码去读取文件即可。 ASCII可谓是这样一个始祖鸟或者始祖蛋一样的存在。 可以动动手做些实验，先建立一个xml文件，比如就叫foo.xml 内容如下： <?xml version="1.0" encoding="UTF-8"?> <foo>向我开炮</foo> 然后初步测试读取编码信息 package org.jcc.core.encode; import static org.assertj.core.api.Assertions.assertThat; import java

在上一篇中，探讨了文件名编码以及非文本文件中的文本内容的编码，在这里，将介绍更为重要的文本文件的编码。 混乱的现状 设想一下，如果在保存文本文件时，也同时把所使用的编码的信息也保存在文件内容里，那么，在再次读取时，确定所使用的编码就容易多了。 很多的非文本文件比如图片文件通常会在文件的头部加上所谓的“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”，保存，然后再查看文件的大小属性

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

关于 BeautifulSoup3 对 gb2312 编码的网页解析的乱码问题，【 这篇文章 】提出了一个勉强能用的解决方法。即 如果中文页面编码是 gb2312，gbk，在 BeautifulSoup 构造器中传入 fromEncoding="gb18030" 参数即可解决乱码问题，即使分析的页面是 utf8 的页面使用 gb18030 也不会出现乱码问题！如： from urllib2 import urlopen from BeautifulSoup import BeautifulSoup page = urllib2.urlopen('http://www.baidu.com'); soup = BeautifulSoup(page,fromEncoding="gb18030") print soup.originalEncoding 为什么网页是 utf8 传入 gb18030 依然能够正常解析呢？ 这是由于， BeautifulSoup 的编码检测顺序为： 1. 创建 Soup 对象时传递的 fromEncoding 参数； 2. XML/HTML 文件自己定义的编码； 3. 文件开始几个字节所表示的编码特征，此时能判断的编码只可能是以下编码之一：UTF-#，EBCDIC 和 ASCII； 4. 如果你安装了 chardet，BeautifulSoup 就会用

最近业务中需要用 Python 写一些脚本。尽管脚本的交互只是命令行 + 日志输出，但是为了让界面友好些，我还是决定用中文输出日志信息。 很快，我就遇到了异常： Python代码 UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3: ordinal not in range(128) 为了解决问题，我花时间去研究了一下 Python 的字符编码处理。网上也有不少文章讲 Python 的字符编码，但是我看过一遍，觉得自己可以讲得更明白些。 下面先复述一下 Python 字符串的基础，熟悉此内容的可以跳过。 对应 C/C++ 的 char 和 wchar_t, Python 也有两种字符串类型，str 与 unicode： Python代码 # -*- coding: utf-8 -*- # file: example1.py import string # 这个是 str 的字符串 s = '关关雎鸠' # 这个是 unicode 的字符串 u = u '关关雎鸠' print isinstance(s, str) # True print isinstance(u, unicode) # True print s.__class__ # <type 'str'> print u._