在本文中，我们将详细介绍MySQL字符集GBK、GB2312、UTF8区别解决MYSQL中文乱码问题的各个方面，并为您提供关于mysql字符集编码的相关解答，同时，我们也将为您带来关于GB2312ph
在本文中，我们将详细介绍MySQL字符集 GBK、GB2312、UTF8区别 解决MYSQL中文乱码问题的各个方面，并为您提供关于mysql字符集编码的相关解答，同时，我们也将为您带来关于GB2312 php smarty截取中文字符乱码问题?gb2312/utf-8、GB2312、GBK、GB18030 这几种字符集的主要区别、GB2312、GBK与UTF-8的区别、kettle gbk 数据到 utf8 mysql 乱码问题解决的有用知识。
本文目录一览：- MySQL字符集 GBK、GB2312、UTF8区别 解决MYSQL中文乱码问题（mysql字符集编码）
- GB2312 php smarty截取中文字符乱码问题?gb2312/utf-8
- GB2312、GBK、GB18030 这几种字符集的主要区别
- GB2312、GBK与UTF-8的区别
- kettle gbk 数据到 utf8 mysql 乱码问题解决
MySQL字符集 GBK、GB2312、UTF8区别 解决MYSQL中文乱码问题（mysql字符集编码）
MysqL中涉及的几个字符集character-set-server/default-character-set：服务器字符集，默认情况下所采用的。
character-set-database：数据库字符集。
character-set-table：数据库表字符集。
优先级依次增加。所以一般情况下只需要设置character-set-server，而在创建数据库和表时不特别指定字符集，这样统一采用character-set-server字符集。
character-set-client：客户端的字符集。客户端默认字符集。当客户端向服务器发送请求时，请求以该字符集进行编码。
character-set-results：结果字符集。服务器向客户端返回结果或者信息时，结果以该字符集进行编码。
在客户端，如果没有定义character-set-results，则采用character-set-client字符集作为默认的字符集。所以只需要设置character-set-client字符集。
要处理中文，则可以将character-set-server和character-set-client均设置为GB2312，如果要同时处理多国语言，则设置为UTF8。
关于MysqL的中文问题
解决乱码的方法是，在执行sql语句之前，将MysqL以下三个系统参数设置为与服务器字符集character-set-server相同的字符集。
character_set_client：客户端的字符集。
character_set_results：结果字符集。
character_set_connection：连接字符集。
设置这三个系统参数通过向MysqL发送语句：set names gb2312
关于GBK、GB2312、UTF8
UTF-8：Unicode Transformation Format-8bit，允许含BOM，但通常不含BOM。是用以解决国际上字符的一种多字节编码，它对英文使用8位（即一个字节），中文使用24为（三个字节）来编码。UTF-8包含全世界所有国家需要用到的字符，是国际编码，通用性强。UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显示。如，如果是UTF8编码，则在外国人的英文IE上也能显示中文，他们无需下载IE的中文语言支持包。
GBK是国家标准GB2312基础上扩容后兼容GB2312的标准。GBK的文字编码是用双字节来表示的，即不论中、英文字符均使用双字节来表示，为了区分中文，将其最高位都设定成1。GBK包含全部中文字符，是国家编码，通用性比UTF8差，不过UTF8占用的数据库比GBD大。
GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换：
GBK、GB2312－－Unicode－－UTF8
UTF8－－Unicode－－GBK、GB2312
对于一个网站、论坛来说，如果英文字符较多，则建议使用UTF－8节省空间。不过现在很多论坛的插件一般只支持GBK。
GB2312是GBK的子集，GBK是GB18030的子集
GBK是包括中日韩字符的大字符集合
如果是中文的网站 推荐GB2312 GBK有时还是有点问题
为了避免所有乱码问题，应该采用UTF-8，将来要支持国际化也非常方便
UTF-8可以看作是大字符集，它包含了大部分文字的编码。
使用UTF-8的一个好处是其他地区的用户（如香港台湾）无需安装简体中文支持就能正常观看你的文字而不会出现乱码。
gb2312是简体中文的码
gbk支持简体中文及繁体中文
big5支持繁体中文
utf-8支持几乎所有字符
首先分析乱码的情况
1.写入数据库时作为乱码写入
2.查询结果以乱码返回
究竟在发生乱码时是哪一种情况呢？
我们先在MysqL 命令行下输入
show variables like '%char%';
查看MysqL 字符集设置情况:
MysqL> show variables like '%char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | gbk |
| character_set_connection | gbk |
| character_set_database | gbk |
| character_set_filesystem | binary |
| character_set_results | gbk |
| character_set_server | gbk |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/MysqL/share/MysqL/charsets/ |
+--------------------------+----------------------------------------+
在查询结果中可以看到MysqL 数据库系统中客户端、数据库连接、数据库、文件系统、查询
结果、服务器、系统的字符集设置
在这里，文件系统字符集是固定的，系统、服务器的字符集在安装时确定，与乱码问题无关
乱码的问题与客户端、数据库连接、数据库、查询结果的字符集设置有关
*注：客户端是看访问MysqL 数据库的方式，通过命令行访问，命令行窗口就是客户端，通
过JDBC 等连接访问，程序就是客户端
我们在向MysqL 写入中文数据时，在客户端、数据库连接、写入数据库时分别要进行编码转
换
在执行查询时，在返回结果、数据库连接、客户端分别进行编码转换
现在我们应该清楚，乱码发生在数据库、客户端、查询结果以及数据库连接这其中一个或多
个环节
接下来我们来解决这个问题
在登录数据库时，我们用MysqL --default-character-set=字符集-u root -p 进行连接，这时我们
再用show variables like '%char%';命令查看字符集设置情况，可以发现客户端、数据库连接、
查询结果的字符集已经设置成登录时选择的字符集了
如果是已经登录了，可以使用set names 字符集;命令来实现上述效果，等同于下面的命令：
set character_set_client = 字符集
set character_set_connection = 字符集
set character_set_results = 字符集
如果是通过JDBC 连接数据库，可以这样写URL：
URL=jdbc:MysqL://localhost:3306/abs?useUnicode=true&characterEncoding=字符集
JSP 页面等终端也要设置相应的字符集
数据库的字符集可以修改MysqL 的启动配置来指定字符集，也可以在create database 时加上
default character set 字符集来强制设置database 的字符集
通过这样的设置，整个数据写入读出流程中都统一了字符集，就不会出现乱码了
为什么从命令行直接写入中文不设置也不会出现乱码？
可以明确的是从命令行下，客户端、数据库连接、查询结果的字符集设置没有变化
输入的中文经过一系列转码又转回初始的字符集，我们查看到的当然不是乱码
但这并不代表中文在数据库里被正确作为中文字符存储
举例来说，现在有一个utf8 编码数据库，客户端连接使用GBK 编码，connection 使用默认
的ISO8859-1（也就是MysqL 中的latin1），我们在客户端发送“中文”这个字符串，客户端
将发送一串GBK 格式的二进制码给connection 层，connection 层以ISO8859-1 格式将这段
二进制码发送给数据库，数据库将这段编码以utf8 格式存储下来，我们将这个字段以utf8
格式读取出来，肯定是得到乱码，也就是说中文数据在写入数据库时是以乱码形式存储的，
在同一个客户端进行查询操作时，做了一套和写入时相反的操作，错误的utf8 格式二进制
码又被转换成正确的GBK 码并正确显示出来。
GB2312 php smarty截取中文字符乱码问题?gb2312/utf-8
一般网站页面的显示都不可避免的会涉及子字符串的截取，这个时候truncate就派上用场了，但是它只适合英文用户，对与中文用户来说，使用 truncate会出现乱码，而且对于中文英文混合串来说，截取同样个数的字符串，实际显示长度上却不同，视觉上会显得参差不齐，影像美观。这是因为一个中文的长度大致相当与两个英文的长度。此外，truncate也不能同时兼容GB2312, UTF-8等编码。
改良的smartTruncate： 文件名：modifier.smartTruncate.php
复制代码 代码如下:
function smartDetectUTF8($string)
{
static $result = array();
if(! array_key_exists($key = md5($string), $result))
{
$utf8 = "
/^(?:
[\x09\x0A\x0D\x20-\x7E] # ASCII
| [\xC2-\xDF][\x80-\xBF] # non-overlong 2-byte
| \xE0[\xA0-\xBF][\x80-\xBF] # excluding overlongs
| [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2} # straight 3-byte
| \xED[\x80-\x9F][\x80-\xBF] # excluding surrogates
| \xF0[\x90-\xBF][\x80-\xBF]{2} # planes 1-3
| [\xF1-\xF3][\x80-\xBF]{3} # planes 4-15
| \xF4[\x80-\x8F][\x80-\xBF]{2} # plane 16
)+$/xs
";
$result[$key] = preg_match(trim($utf8), $string);
}
return $result[$key];
}
function smartStrlen($string)
{
$result = 0;
$number = smartDetectUTF8($string) ? 3 : 2;
for($i = 0; $i {
$bytes = ord(substr($string, $i, 1)) > 127 ? $number : 1;
$result += $bytes > 1 ? 1.0 : 0.5;
}
return $result;
}
function smartSubstr($string, $start, $length = null)
{
$result = '''';
$number = smartDetectUTF8($string) ? 3 : 2;
if($start {
$start = max(smartStrlen($string) + $start, 0);
}
for($i = 0; $i {
if($start {
break;
}
$bytes = ord(substr($string, $i, 1)) > 127 ? $number : 1;
$start -= $bytes > 1 ? 1.0 : 0.5;
}
if(is_null($length))
{
$result = substr($string, $i);
}
else
{
for($j = $i; $j {
if($length {
break;
}
if(($bytes = ord(substr($string, $j, 1)) > 127 ? $number : 1) > 1)
{
if($length {
break;
}
$result .= substr($string, $j, $bytes);
$length -= 1.0;
}
else
{
$result .= substr($string, $j, 1);
$length -= 0.5;
}
}
}
return $result;
}
function smarty_modifier_smartTruncate($string, $length = 80, $etc = ''...'',
$break_words = false, $middle = false)
{
if ($length == 0)
return '''';
if (smartStrlen($string) > $length) {
$length -= smartStrlen($etc);
if (!$break_words && !$middle) {
$string = preg_replace(''/\s+?(\S+)?$/'', '''', smartSubstr($string, 0, $length+1));
}
if(!$middle) {
return smartSubstr($string, 0, $length).$etc;
} else {
return smartSubstr($string, 0, $length/2) . $etc . smartSubstr($string, -$length/2);
}
} else {
return $string;
}
}
?>
以上代码完整实现了truncate的原有功能，而且可以同时兼容GB2312和UTF-8编码，在判断字符长度的时候，一个中文字符算1.0，一个英文字符算0.5，所以在截取子字符串的时候不会出现参差不齐的情况.
插件的使用方式没有特别之处，这里简单测试一下：
{$content|smartTruncate:5:".."}（$content等于"A中B华C人D民E共F和G国H"）
显示：A中B华C.. （中文符号长度算1.0，英文符号长度算0.5，并且考虑省略符号的长度）
不管你是使用GB2312编码还是UTF-8编码，你会发现结果都正确，这也是为什么我在插件名字里加上smart字样的原因之一。
以上就介绍了GB2312 php smarty截取中文字符乱码问题?gb2312/utf-8，包括了GB2312方面的内容，希望对PHP教程有兴趣的朋友有所帮助。
GB2312、GBK、GB18030 这几种字符集的主要区别
1 GB2312-80
GB 2312 或 GB 2312-80 是中国国家标准简体中文字符集，全称《信息交换用汉字编码字符集·基本集》，又称 GB 0，由中国国家标准总局发布，1981 年 5 月 1 日实施。GB 2312 编码通行于中国大陆；新加坡等地也采用此编码。中国大陆几乎所有的中文系统和国际化的软件都支持 GB 2312。
GB 2312 标准共收录 6763 个汉字，其中一级汉字 3755 个，二级汉字 3008 个；同时收录了包括拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母在内的 682 个字符。
- GB 2312 的出现，基本满足了汉字的计算机处理需要，它所收录的汉字已经覆盖中国大陆99.75% 的使用频率。
- 对于人名、古汉语等方面出现的罕用字，GB 2312 不能处理，这导致了后来 GBK 及 GB 18030 汉字字符集的出现。
GB 2312 对任意一个图形字符都采用两个字节表示，并对所收汉字进行了“分区”处理，每区含有 94 个汉字／符号，分别对应第一字节和第二字节。这种表示方式也称为区位码。
- 01-09 区为特殊符号。
- 16-55 区为一级汉字，按拼音排序。
- 56-87 区为二级汉字，按部首／笔画排序。
10-15 区及 88-94 区则未有编码。
GB 2312 的编码范围为 2121H-777EH，与 ASCII 有重叠，通行方法是将 GB 码两个字节的最高位置 1 以示区别。
2 GBK
GBK 即汉字内码扩展规范，K 为汉语拼音 Kuo Zhan（扩展）中“扩”字的声母。英文全称 Chinese Internal Code Specification。
GBK 共收入 21886 个汉字和图形符号，包括：
- GB 2312 中的全部汉字、非汉字符号。
- BIG5 中的全部汉字。
- 与 ISO 10646 相应的国家标准 GB 13000 中的其它 CJK 汉字，以上合计 20902 个汉字。
- 其它汉字、部首、符号，共计 984 个。
GBK 向下与 GB 2312 完全兼容，向上支持 ISO 10646 国际标准，在前者向后者过渡过程中起到的承上启下的作用。
GBK 采用双字节表示，总体编码范围为 8140-FEFE 之间，首字节在 81-FE 之间，尾字节在 40-FE 之间，剔除 XX7F 一条线。GBK 编码区分三部分：
- 汉字区 包括
GBK/2：OXBOA1-F7FE, 收录 GB 2312 汉字 6763 个，按原序排列；
GBK/3：OX8140-AOFE，收录 CJK 汉字 6080 个；
GBK/4：OXAA40-FEAO，收录 CJK 汉字和增补的汉字 8160 个。
- 图形符号区 包括
GBK/1：OXA1A1-A9FE，除 GB 2312 的符号外，还增补了其它符号
GBK/5：OXA840-A9AO，扩除非汉字区。
- 用户自定义区
GBK 区域中的空白区，用户可以自己定义字符。
3 GB18030
GB 18030，全称：国家标准 GB 18030-2005《信息技术中文编码字符集》，是中华人民共和国现时最新的内码字集，是 GB 18030-2000《信息技术信息交换用汉字编码字符集基本集的扩充》的修订版。
GB 18030 与 GB 2312-1980 和 GBK 兼容，共收录汉字70244个。
- 与 UTF-8 相同，采用多字节编码，每个字可以由 1 个、2 个或 4 个字节组成。
- 编码空间庞大，最多可定义 161 万个字符。
- 支持中国国内少数民族的文字，不需要动用造字区。
- 汉字收录范围包含繁体汉字以及日韩汉字
GB 18030 编码是一二四字节变长编码。
- 单字节，其值从 0 到 0x7F，与 ASCII 编码兼容。
- 双字节，第一个字节的值从 0x81 到 0xFE，第二个字节的值从 0x40 到 0xFE（不包括0x7F），与 GBK 标准兼容。
- 四字节，第一个字节的值从 0x81 到 0xFE，第二个字节的值从 0x30 到 0x39，第三个字节从0x81 到 0xFE，第四个字节从 0x30 到 0x39。
GB2312、GBK与UTF-8的区别
这是一个异常经典的问题，有无数的新手站长每天都在百度这个问题，而我，作为一个“伪老手”站长，在明白这个这个问题的基础上，有必要详细的解答一下。
首先，我们要明白，GB2312、GBK和UTF-8都是一种字符编码，除此之外，还有好多字符编码。只是对于我们中国人的网站来说，用这三种编码 比较多。简单的说一下，为什么要用编码，在计算机内，储存文本信息用ASC II码，每一个字符对应着唯一的ASCII码。最初计算机是由美国发明的，他们也用的是键盘和上面的字母，所以他们的字符ASCII好解决。但是我们中国 的就不同了，每个汉字要对应唯一的ASCII码。这样，就出来了国家制定的字符编码标准：GB2312、GBK等。其他国家，其他语言也有他们对应的编码 标准。
GB 就是国标的意思，GB2312和GBK主要用于汉字的编码，而UTF-8是全世界通用的。意思就是说，如果你的网页主要面对使用汉语的中国人的话，使用 GB2312和GBK非常好，文字储存体积要小，有一些优点。如果你的网页要面向世界的话，你再用GB2312和GBK作为网页编码的话，有些电脑上的浏 览器没有这种编码，你的网页汉字内容就会变成无法识别的乱码。
它们通常用在网页的meta标签内，例如：<meta http-equiv=”Content-Type” content=”text/html; charset=gb2312″ />，表示这个页面使用的是GB2312编码。这个信息是给浏览器看的，浏览器会优先考虑使用从网页头部提取出来的编码信息对网页进行解码。当然， 我们也可以强制浏览器使用某种编码解释网页，这样我们就看到了传说中的乱码。请看下图IE浏览器：
百度首页使用的是GB2312编码，我们可以看到现在是正常的。我们右击页面，选择“编码”->“其他”->“Unicode（UTF-8)”，意思就是强制浏览器使用UTF-8的编码方式解析页面，我们可以看到奇迹发生了：
百度页面上所有的汉字都变成了乱码。如果你的网页使用了GB2312编码，却被一台没有GB2312编码的电脑访问了，里面所有的汉字都成了乱码。如果你使用UTF-8编码，在没有汉字的电脑里，仍然可以正常显示，因为UTF-8是通用的编码，所有电脑都有。
所以，在编写网页时，尽量使用UTF-8编码。
UTF-8：Unicode Transformation Format-8bit，允许含BOM，但通常不含BOM。是用以解决国际上字符的一种多字节编码，它对英文使用8位（即一个字节），中文使用24为（三个字节）来编码。UTF-8包含全世界所有国家需要用到的字符，是国际编码，通用性强。UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显示。如，如果是UTF8编码，则在外国人的英文IE上也能显示中文，他们无需下载IE的中文语言支持包。
GBK是国家标准GB2312基础上扩容后兼容GB2312的标准。GBK的文字编码是用双字节来表示的，即不论中、英文字符均使用双字节来表示，为了区分中文，将其最高位都设定成1。GBK包含全部中文字符，是国家编码，通用性比UTF8差，不过UTF8占用的数据库比GBD大。
GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换：
GBK、GB2312－－Unicode－－UTF8
UTF8－－Unicode－－GBK、GB2312
对于一个网站、论坛来说，如果英文字符较多，则建议使用UTF－8节省空间。不过现在很多论坛的插件一般只支持GBK。
GB2312是GBK的子集，GBK是GB18030的子集
GBK是包括中日韩字符的大字符集合
如果是中文的网站 推荐GB2312 GBK有时还是有点问题
为了避免所有乱码问题，应该采用UTF-8，将来要支持国际化也非常方便
UTF-8可以看作是大字符集，它包含了大部分文字的编码。
使用UTF-8的一个好处是其他地区的用户（如香港台湾）无需安装简体中文支持就能正常观看你的文字而不会出现乱码。
gb2312是简体中文的码
gbk支持简体中文及繁体中文
big5支持繁体中文
utf-8支持几乎所有字符
中国大陆最常用的就是GBK18030编码，除此之外还有GBK，GB2312，这几个编码的关系是这样的。
最早制定的汉字编码是GB2312，包括6763个汉字和682个其它符号
95年重新修订了编码，命名GBK1.0，共收录了21886个符号。
之后又推出了GBK18030编码，共收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字，现在WINDOWS平台必需要支持GBK18030编码。
按照GBK18030、GBK、GB2312的顺序，３种编码是向下兼容，同一个汉字在三个编码方案中是相同的编码。
GB2312编码大约包含6000多汉字（不包括特殊字符）,编码范围为第一位b0-f7,第二位编码范围为a1-fe(第一位为cf时,第二位为a1-d3),计算一下汉字个数为6762个汉字。当然还有其他的字符。包括控制键和其他字符大约7573个字符编码
gbk编码是对G B2312编码的扩充，容纳的汉字更多，但仅仅是扩充，没有质的变化。保留了所有G B2312编码,在此基础上进行编码范围的扩充.容纳(包含特殊字符)共22014个字符编码.
gb18030编码是在gbk编码基础上的扩充，因为汉字更多，仅仅使用两位编码已经不能
容纳要求的汉字，所以采用了2\4位混和的办法，可以支持更多的汉字编码。并且保留了原有的gbk 2字节编码兼容G B2312和gbk编码的文件。大概容纳55657个编码(包含特殊字符)
unicode编码(也就是UTF编码)：俗称万国码，致力于使用统一的编码准则表达各国的文字。
为表达更多的文字，utf-8采用2/3混编的方式。目前容纳的汉字范围小于gbk编码。并且以
3字节的方式处理中文，带来了兼容性的问题，原有的gbk,G B2312,gb18030编码文件都不能正常的处理,还有很长的路要走。
kettle gbk 数据到 utf8 mysql 乱码问题解决
源文件是 csv，字符集是 gbk 的，目标 mysql 是 utf8 的字符集，按照网上说的，设置 characterEncoding 为 gbk 时，能正常导入到 mysql，而且没有乱码。但是在做主从库时，出现 Slave SQL: Error ''Incorrect string value Error_code: 1366 的错误。
仔细追查原因，发现是由于设置 characterEncoding 为 gbk 造成的，需要设置 characterEncoding 为 utf8。但这样导入到 mysql 的数据中午都是乱码。如何解决呢？
1. 设置 characterEncoding 为 utf8。
2. 使用 select value setp，将中文字段设置为 GBK。
关于MySQL字符集 GBK、GB2312、UTF8区别 解决MYSQL中文乱码问题和mysql字符集编码的问题就给大家分享到这里，感谢你花时间阅读本站内容，更多关于GB2312 php smarty截取中文字符乱码问题?gb2312/utf-8、GB2312、GBK、GB18030 这几种字符集的主要区别、GB2312、GBK与UTF-8的区别、kettle gbk 数据到 utf8 mysql 乱码问题解决等相关知识的信息别忘了在本站进行查找喔。
本文标签：
