189 8069 5689
我来给你做一个综合解释吧。
成都创新互联公司专注于尧都网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供尧都营销型网站建设，尧都网站制作、尧都网页设计、尧都网站官网定制、微信平台小程序开发服务，打造尧都网络公司原创品牌,更为您提供尧都网站排名全网营销落地服务。
在正常情况下。
PHP脚本 HTML 已经浏览器 然后就是数据库。
都有自己的字符集。何谓字符集。我想你如果是一个真正想热衷于学PHP
那么你应该花一定的时间去了解一下字符集的问题。
因为无论你以后做什么项目开发什么网站都是要牵涉到字符集。
就好比我做第一个项目。因为字符集搞的死去活来。
好进入正题。怎么解决问题呢？
1.PHP的字符集。一般PHP网页的是嵌套在html页面以内。那么如果在没有冲突的情况下可以使用
header方面设置。比如?php header ... ?
2.HTML的字符集，一般是网页的优先字符集，这个问题是牵涉到你的网站是什么定位，比如：你的网站仅仅适合国内的客户。那么用gbk 或者gb2312.如果想老外也开凑凑热闹的话，就用utf-8.至于怎么设置这个字符集，你可以在meta这个标记中看到。
3.数据库的问题。mysql_query("set names gbk"); 这句话意思就是说，在操作数据库的时候已这个字符集去读写。当然这个字符集要对应你的页面的字符集哦。
4.浏览器。浏览器的问题是最万恶的，因为每个浏览器默认的是gb2312.当然不同的浏览器是不同的。所以要想成为一名优秀的程序员，写出优质的代码。你还得去了解每个浏览器的差别。当然目前是不需要的，当然这个问题你慢慢学习。写代码的过程中会慢慢了解到的。
你要做的就是将所有使用字符集确保一致性
问题就这些吧，如果有什么问题可以继续问哦。凡是对PHP有热情的人。我都会尽全力帮一下。哈哈。因为这个加物以类聚。还有这个内容绝对不是复制粘贴的。
所有在页面在编码都要统一，并不是在页面加入utf-8的header就行了，我的就是遇到过这样的，要把网页重新保存为utf-8的编码
一、转码失败
在数据写入到表的过程中转码失败，数据库端也没有进行恰当的处理，导致存放在表里的数据乱码。
针对这种情况，前几篇文章介绍过客户端发送请求到服务端。
其中任意一个编码不一致，都会导致表里的数据存入不正确的编码而产生乱码。
比如下面简单一条语句：
set @a = "文本字符串";
insert into t1 values(@a);
变量 @a 的字符编码是由参数 CHARACTER_SET_CLIENT 决定的，假设此时编码为 A，也就是变量 @a 的编码。
2. 写入语句在发送到 MySQL 服务端之前的编码由 CHARACTER_SET_CONNECTION 决定，假设此时编码为 B。
3. 经过 MySQL 一系列词法，语法解析等处理后，写入到表 t1，表 t1 的编码为 C。
那这里编码 A、编码 B、编码 C 如果不兼容，写入的数据就直接乱码。
二、客户端乱码
表数据正常，但是客户端展示后出现乱码。
这一类场景，指的是从 MySQL 表里拿数据出来返回到客户端，MySQL 里的数据本身没有问题。客户端发送请求到 MySQL，表的编码为 D，从 MySQL 拿到记录结果传输到客户端，此时记录编码为 E（CHARACTER_SET_RESULTS）。
那以上编码 E 和 D 如果不兼容，检索出来的数据就看起来乱码了。但是由于数据本身没有被破坏，所以换个兼容的编码就可以获取正确的结果。
这一类又分为以下三个不同的小类：
1)字段编码和表一致，客户端是不同的编码
比如下面例子， 表数据的编码是 utf8mb4，而 SESSION 1 发起的连接编码为 gbk。那由于编码不兼容，检索出来的数据肯定为乱码。
2）表编码和客户端的编码一致，但是记录之间编码存在不一致的情形
比如表编码是 utf8mb4，应用端编码也是 utf8mb4，但是表里的数据可能一半编码是 utf8mb4，另外一半是 gbk。那么此时表的数据也是正常的，不过此时采用哪种编码都读不到所有完整的数据。这样数据产生的原因很多，比如其中一种可能性就是表编码多次变更而且每次变更不彻底导致（变更不彻底，我之前的篇章里有介绍）。举个例子，表 t3 的编码之前是 utf8mb4，现在是 gbk，而且两次编码期间都被写入了正常的数据。
3）每个字段的编码不一致，导致乱码和第二点一样的场景。不同的是：非记录间的编码不统一，而是每个字段编码不统一。举个例子，表 c1 字段 a1,a2。a1 编码 gbk，a2 编码是 utf8mb4。那每个字段单独读出来数据是完整的，但是所有字段一起读出来，数据总会有一部分乱码。
三、LATIN1
还有一种情形就是以 LATIN1 的编码存储数据
估计大家都知道字符集 LATIN1，LATIN1 对所有字符都是单字节流处理，遇到不能处理的字节流，保持原样，那么在以上两种存入和检索的过程中都能保证数据一致，所以 MySQL 长期以来默认的编码都是 LATIN1。这种情形，看起来也没啥不对的点，数据也没乱码，那为什么还有选用其他的编码呢？原因就是对字符存储的字节数不一样，比如 emoji 字符 "❤"，如果用 utf8mb4 存储，占用 3 个字节，那 varchar(12) 就能存放 12 个字符，但是换成 LATIN1，只能存 4 个字符。
header("Content-type: text/html; charset=utf-8");
另外你的编辑器编码也要对应哦
a. 如果欲使用gb2312编码，那么php要输出头：header(“Content-Type: text/html; charset=gb2312")，静态页面添加meta http-equiv="Content-Type" content="text/html; charset=gb2312"，所有文件的编码格式为ANSI，可用记事本打开，另存为选择编码为ANSI，覆盖源文件。
b. 如果欲使用utf-8编码，那么php要输出头 ：header(“Content-Type: text/html; charset=utf-8")，静态页面添加meta http-equiv="Content-Type" content="text/html; charset=utf-8"，所有文件的编码格式为utf-8。
最近需要用到iconv函数把抓取来过的utf-8编码的页面转成gb2312， 发现只有用iconv函数把抓取过来的数据一转码数据就会无缘无故的少一些。 让我郁闷了好一会儿，去网上一查资料才知道这是iconv函数的一个bug。iconv在转换字符"—"到gb2312时会出错。解决方法很简单，就是在 需要转成的编码后加 "//IGNORE" 也就是iconv函数第二个参数后，如下：
iconv("UTF-8","GB2312//IGNORE",$data)
ignore的意思是忽略转换时的错误，如果没有ignore参数，所有该字符后面的字符串都无法被保存。
PHP程序设计中中文编码问题曾经困扰很多人，导致这个问题的原因其实很简单，每个国家(或区域)都规定了计算机信息交换用的字符编码集，如美国的扩展ASCII码,中国的GB2312-80，日本的JIS等。作为该国家/区域内信息处理的基础，字符编码集起着统一编码的重要作用。字符编码集按长度分为SBCS(单字节字符集)，DBCS(双字节字符集)两大类。早期的软件(尤其是操作系统)，为了解决本地字符信息的计算机处理，出现了各种本地化版本(L10N)，为了区分，引进了LANG,Codepage等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难;软件各个本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理内容降低到最少。这也就是所谓的国际化(118N)。各种语言信息被进一步规范为Locale信息。处理的底层字符集变成了几乎包含了所有字形的 Unicode。
现在大部分具有国际化特征的软件核心字符处理都是以Unicode为基础的，在软件运行时根据当时的ocale/Lang /Codepage设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中需要实现Unicode和本地字符集的相互转换，甚或以 Unicode为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容。
数据库中的字符集编码问题
流行的关系数据库系统都支持数据库字符集编码，也就是说在创建数据库时可以指定它自己的字符集设置，数据库的数据以指定的编码形式存储。当应用程序访问数据时，在入口和出口处都会有字符集编码的转换。对于中文数据，数据库字符编码的设置应当保证数据的完整性。GB2312、GBK、UTF-8等都是可选的数据库字符集编码;当然我们也可以选择ISO8859-1(8-bit)，只是我们得在应
用程序写数据之前先将16Bit的一个汉字或Unicode拆分成两个8-bit的字符，读数据之后也需要将两个字节合并起来，同时还要判别其中的SBCS 字符，因此我们并不推荐采用ISO8859-1作为数据库字符集编码。这样不但没有充分利用数据库自身的字符集编码支持，而且同时也增加了编程的复杂度。编程时，可以先用数据库管理系统提供的管理功能检查其中的中文数据是否正确。
PHP程序在查询数据库之前，首先执行 mysql_query("SETNAMESxxxx");其中xxxx是你网页的编码(charset=xxxx)，如果网页中 charset=utf8，则xxxx=utf8，如果网页中charset=gb2312，则xxxx=gb2312，几乎所有WEB程序，都有一段连接数据库的公共代码，放在一个文件里，在这文件里，加入mysql_query("SETNAMESxxxx")就可以了。
SETNAMES 显示客户端发送的SQL语句中使用什么字符集。因此，SETNAMES'utf-8'语句告诉服务器“将来从这个客户端传来的信息采用字符集utf- 8”。它还为服务器发送回客户端的结果指定了字符集(例如，如果你使用一个SELECT语句，它表示列值使用了什么字符集)。
定位问题时常用的技巧
定位中文编码问题通常采用最笨的也是最有效的办法―在你认为有嫌疑的程序处理后打印字符串的内码。通过打印字符串的内码，你可以发现什么时候中文字符被转换成Unicode，什么时候Unicode被转回中文内码，什么时候一个中文字成了两个Unicode字符，什么时候中文字符串被转成了一串问号，什么时候中文字符串的高位被截掉了……
取用合适的样本字符串也有助于区分问题的类型。如："aa啊aa?@aa"等中英相间，GB、GBK特征字符均有的字符串。一般来说，英文字符无论怎么转换或处理，都不会失真(如果遇到了，可以尝试着增加连续的英文字母长度)。
解决各种应用的乱码问题
1)使用标签设置页面编码
这个标签的作用是声明客户端的浏览器用什么字符集编码显示该页面，xxx可以为GB2312、GBK、UTF-8(和MySQL不同，MySQL是 UTF8)等等。因此，大部分页面可以采用这种方式来告诉浏览器显示这个页面的时候采用什么编码，这样才不会造成编码错误而产生乱码。但是有的时候我们会发现有了这句还是不行，不管xxx是哪一种，浏览器采用的始终都是一种编码，这个情况我后面会谈到。
请注意，是属于HTML信息的，仅仅是一个声明，仅表明服务器已经把HTML信息传到了浏览器。
2)header("content-type:text/html;charset=xxx");
这个函数header()的作用是把括号里面的信息发到http标头。如果括号里面的内容为文中所说那样，那作用和标签基本相同，大家对照第一个看发现字符都差不多的。但是不同的是如果有这段函数，浏览器就会永远采用你所要求的xxx编码，绝对不会不听话，因此这个函数是很有用的。为什么会这样呢?那就得说说http标头和HTML信息的差别了：
http标头是服务器以http协议传送HTML信息到浏览器前所送出的字串。而标签是属于 HTML信息的，所以header()发送的内容先到达浏览器，通俗点就是header()的优先级高于(不知道可不可以这样讲)。假如一个php页面既有header("content-type:text/html;charset=xxx")，又有，浏览器就只认前者http标头而不认meta了。当然这个函数只能在php页面内使用。
同样也留有一个问题，为什么前者就绝对起作用，而后者有时候就不行呢?这就是接下来要谈的Apache的原因了。
3)AddDefaultCharset
Apache根目录的conf文件夹里，有整个Apache的配置文档httpd.conf。
用文本编辑器打开httpd.conf，第708行(不同版本可能不同)有AddDefaultCharsetxxx，xxx为编码名称。这行代码的意思：设置整个服务器内的网页文件http标头里的字符集为你默认的xxx字符集。有这行，就相当于给每个文件都加了一行header("content- type:text/html;charset=xxx")。这下就明白为什么明明设置了是utf-8，可浏览器始终采用gb2312的原因。
如果网页里有header("content-type:text/html;charset=xxx")，就把默认的字符集改为你设置的字符集，所以这个函数永远有用。如果把AddDefaultCharsetxxx前面加个"#"，注释掉这句，而且页面里不含header("content- type…")，那这个时候就轮到meta标签起作用了。
下面列出以上的优先顺序：
..header("content-type:text/html;charset=xxx")
..AddDefaultCharsetxxx
..
如果你是web程序员，建议给你的每个页面都加个header("content-type:text/html;charset=xxx")，这样就可以保证它在任何服务器都能正确显示，可移植性也比较强。
4)php.ini中的default_charset配置：
php.ini中的default_charset="gb2312"定义了php的默认语言字符集。一般推荐注释掉此行，让浏览器根据网页头中的charset来自动选择语言而非做一个强制性的规定，这样就可以在同台服务器上提供多种语言的网页服务。
结束语 参考：
其实php开发中的中文编码并没有想像的那么复杂，虽然定位和解决问题没有定规，各种运行环境也各不尽然，但后面的原理是一样的。了解字符集的知识是解决字符问题的基础。不过，随着中文字符集的变化，不仅仅是php编程，中文信息处理中的问题还是会存在一段时间的。
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource
警告：mysql_fetch_array():支持的参数不是一个有效的 MySQL 结果资源。
从错误提示信息来看，应该是
$this-result = mysql_query($sql, $this-conn); // 执行查询语句
这一句执行的结果不正确导致的。
建议：
1. 查看下sql语句是不是正确。
2. 查看 数据库编码 与 html文件 、 html 显示编码三者是否一致。