明确问题: 很多朋友出现乱码后,就在论坛发帖,或网上搜寻相关文章 . 然 后 , 很 快 就 认 识 了 header("content-type:text/html; charset=utf-8"),iconv('gbk', 'utf-8', " ...."),mysql_query(set names xxx) 以及一个什么 php 实现的 unescape 函数等等 [这就
甚至连为什么产生乱码都没去想,问题有时候还真被解决了 是互联网的神奇之处]
其实,根本问题很容易理解,就是存储方式和读取方式不一致 你存储的是一段 utf-8 编码的文字,却告诉浏览器用 gb2312 的方式去解析.问题自然就来了! 如下面这段代码,用记事本保存为 html 文件,IE 打开是没有任何
问题的!如果你把第四行的 gb2312 改为 utf-8 那问题自然就来了 因为记事本默认的是用 ANSI 标准保存,而 gb2312 是其中的一种!对于简体中文的操作
系统, 我们存储的是一段 gb2312 数据!如果你骗浏览器这 是一段 utf-8 的数据,那这个忠实的仆人自然就会犯错误了![gb2312 改成 utf-8(请在记事本中 修改)后,标题和内容成乱码了]
复制内容到剪贴板
代码:
1.0 Transitional//EN"
无标题文档
整个 ajax+php 应用中,数据要转手两次 存在于三个层次中 分别是前台 html 后台 php 以及 数据库
下面将按一个读取的过程,依次分析两次转手的过程
数据库<->php 过程分析 mysql 编码问题,应该是我们论坛的朋友最熟悉的,就不多说了!
而且没有什么可说的,你只要能确定你当前数据库中的数据不是乱码就行了 这里,提一下 mysql_query("SET NAMES '编码格式如(utf8)'") 我找了一段网上关于 set names 的说明: 复制 PHP 内容到剪贴板 PHP 代码: SET NAMES 显示客户端发送的 SQL 语句中使用什么字符集。因此,SET NAMES 'cp1251'语句 告诉服务器“将来从这个客户端传来的信息采用字符集 cp1251” 。它还为服务器发送回客户 端的结果指定了字符集。 (例如,如果你使用一个 SELECT 语句,它表示列值使用了什么字符 集。 ) SET NAMES 'x'语句与这三个语句等价: mysql> SET character_set_client = x; mysql> SET character_set_results = x;
mysql> SET character_set_connection = x; 将 x 设置为 character_set_connection 也就设置了 collation_connection 是 x 的默认校对规则。
感觉它说得不够俗,咱来通俗点: 其实,他的作用就是告诉数据库,"我传给你的将是一段 X 编码的数据,请按 X 编码理解","你传 给我的数据也必须翻译成 X 编码的,我只懂 X 编码"
注意上面的两个引号部分,这说明他分别设定了读取和写入两个层次 所以在 PHP 读取 MYSQL 中的数据
的时候,只要你的数据库中的数据本身不是乱码!你执行 my
sql_query("SET NAMES '编码格式如(utf8)'")后, 读取出来的数据,都将是 UTF-8 格式的正常数据!同理,只要你执行 sql 语句里的数据都是 utf-8 格式的,存如数据库后都不会是乱码.
下面来做个实验: 复制 PHP 内容到剪贴板 PHP 代码: word); mysql_query("SET NAMES 'UTF8'"); ......省略......
类似以上方式随便在数据库中读取一段数据,他都将保存成一段 utf-8 格式编码的数 据
这里为了你测试方便,我用 iconv 函数模拟了一下 的详细内容]
[本页左上方,可以查看 iconv
如楼上所说,用记事本保存这段代码,所有数据格式将是 gb2312 的 因此下面的变
量$test 未经过 iconv 之前,将是 gb2312 格式的数据!
经过 iconv 后 变成一段 utf-8 格式的数据
而输出的 HTML 如果你不手动设置一下 header 各个浏览器的处理方式是不一样 有兴趣的可以自行测试一下
所以为了统一一下,这里设置一下 header
执行结果第一行将是乱玛,第二行是正常的!
为什么 应该还是很容易理解的吧!
*/ header("content-type:text/html; charset=utf-8"); $test = "大家好!"; echo $test."
"