节选自 《Netkiller MySQL 手札》 MySQL 数据库将latin1 转换为 UTF-8有几种方案。...转换 latin1 到 UTF-8 UPDATE category SET name=convert(cast(convert(name using latin1) as binary) using...utf8), description=convert(cast(convert(description using latin1) as binary) using utf8)
问题背景 我司某客户最近在检查一批新安装的 MySQL 数据库时，发现了下面的现象： 该批次的 MySQL 客户端字符集全部为 Latin1 ； 而之前使用同样参数模板部署的 MySQL ，客户端字符集却为...，而原先的为 en_US.UTF-8 [qinguangfei0511-4.png] 好像找到了问题出在哪里，测试环境验证下，果然当服务器字符集设置为 en_US 后，MySQL 客户端字符集变为了 Latin1...翻译下来，大致有两点含义： mysql, mysqladmin, mysqlcheck, mysqlimport, and mysqlshow 这些客户端工具都有一个默认的字符集，MySQL 5.7 是 latin1...MySQL支持操作系统的字符集，就会使用操作系统的（这里支持包括不完全精确匹配时，OS字符集将映射到最接近的MySQL字符集）；如果不支持，就使用客户端默认字符集； 我们知道en_US最接近的字符集就是Latin1...，所以回到我们的问题，当服务器的字符集为en_US后，我们看到MySQL客户端字符集为Latin1 ，是不是可以理解了 而使用MySQL 8.0的客户端，能进一步验证当不能精确匹配时，就使用MySQL最接近的字符集
问题背景 我司某客户最近在检查一批新安装的 MySQL 数据库时，发现了下面的现象： 该批次的 MySQL 客户端字符集全部为 latin1 ； 而之前使用同样参数模板部署的 MySQL ，客户端字符集却为...又查看了服务器上操作系统的字符集，发现有问题的为 en_US ，而原先的为 en_US.UTF-8 好像找到了问题出在哪里，测试环境验证下，果然当服务器字符集设置为 en_US 后，MySQL 客户端字符集变为了 latin1...翻译下来，大致有两点含义： mysql ，mysqladmin ，mysqlcheck ，mysqlimport ，and mysqlshow 这些客户端工具都有一个默认的字符集，MySQL 5.7 是 latin1...支持操作系统的字符集，就会使用操作系统的（这里支持包括不完全精确匹配时，OS 字符集将映射到最接近的 MySQL 字符集）；如果不支持，就使用客户端默认字符集； 我们知道 en_US 最接近的字符集就是 latin1...，所以回到我们的问题，当服务器的字符集为 en_US 后，我们看到 MySQL 客户端字符集为 latin1 ，是不是可以理解了 而使用 MySQL 8.0 的客户端，能进一步验证当不能精确匹配时，就使用
english_ci | 1 | | koi8r | KOI8-R Relcom Russian | koi8r_general_ci | 1 | | latin1...例如，要想查看latin1（“西欧ISO-8859-1”）字符集的 校对规则，使用下面的语句查找那些名字以latin1开头的 校对规则： mysql> SHOW COLLATION LIKE 'latin1%...1 | | latin1_danish_ci | latin1 | 15 | | | 0 | | latin1_german2_ci | latin1...1 | | latin1_general_ci | latin1 | 48 | | | 0 | | latin1_general_cs | latin1...例如，latin1默认校对规则是latin1_swedish_ci。
事实上这个值代表的就是你当前数据库的编码而已，比方使用"use test"，而test数据库的编码为latin1的话，这个值就是latin1。...| | latin1 | ????–?...| | latin1 | ?????...CONVERT(utf8 USING latin1) utf8,BINARY CONVERT(latin1 USING latin1) latin1 FROM test WHERE set_names...| | latin1 | ?????
作者：龙述兵 问题描述 假设有三个表test_gbk,test_utf8,test_latin1，创建的时候字符集分别为gbk,utf8,latin1。...'latin1'。...>latin1 -> latin1 -> latin1， 编码完全一致，数据没有做任何转换，所以输入是0xD6 D0，最后的输出也还原为0xD6 D0。...-> gbk， 其中gbk-> latin1的时候，因为'中'这个字符在latin1字符集里找不到，就会转换成'?'...'latin1'。
1.查询自身MYSQL编码方式 MySQL默认编码是latin1 mysql> show variables like 'character%'; +-----------------------...| +--------------------------+--------------------------+ | character_set_client | latin1...| | character_set_connection | latin1 | | character_set_database...| latin1 | | character_set_filesystem | binary | | character_set_results...| latin1 | | character_set_server | latin1 | | character_set_system
整个细节可以参见我写的这篇文章的处理过程： 力荐：一条update语句引发的“血案” 当时有一个地方没有想明白，那就是里面的字段APNS_PUSH_ID为什么字符集会是latin1，而表的字符集却妥妥的是...创建一张表test_charset,设置字符集为latin1 mysql> create table test_charset(id int primary key,name varchar(30),...memo varchar(30)) charset=latin1; Query OK, 0 rows affected (0.12 sec) 查看表结构，可以清晰的看到，字段是共享了表的默认字符集，没有显式显示出来...字符集现在显式显示出来了，表的字符集是utf8,但是字符类型的字段字符集依然是latin1 mysql> show create table test_charset\G **************...DEFAULT NULL, `memo` varchar(30) CHARACTER SET latin1 DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=
192.168.100.101 | 3306 | 34828 | 3127 | 804 | 2338 | false | false | 0 | my3 | latin1...192.168.100.101 | 3306 | 35206 | 2609 | 678 | 2038 | false | false | 0 | my3 | latin1...192.168.100.101 | 3306 | 34416 | 3867 | 984 | 2657 | false | false | 0 | my3 | latin1...192.168.100.101 | 3306 | 34422 | 463 | 156 | 2657 | false | false | 0 | my1 | latin1...192.168.100.101 | 3306 | 34425 | 463 | 156 | 2657 | false | false | 0 | my1 | latin1
// pt-osc改表过程中的中文乱码问题 // 下午使用pt-osc工具对线上表进行变更的时候，发现了一个问题，在对latin1字符集进行变更的时候，变更完毕之后的表的中文注释都变成了'？'...name` varchar(10) DEFAULT NULL COMMENT '任务名称', PRIMARY KEY (`id`), ) ENGINE=InnoDB DEFAULT CHARSET=latin1...--execute 首先创建一张字符集为latin1的表，它包含id和name两个字段，然后对这个表的name字段添加索引，变更的pt指令如上文，其中： --charset=latin1 当我们变更完成之后..., PRIMARY KEY (`id`), KEY `idx_name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 1 row in set...如果我们使用latin1这个字符集，则说明pt-osc工具和mysql交互的字符集是latin1，而这个字符集是无法保存汉字的，所以结果中就出现了????的字眼。
Variable_name | Value | ±-------------------------±---------------------------+ | character_set_client | latin1...| | character_set_connection | latin1 | | character_set_database | latin1 | | character_set_filesystem...| binary | | character_set_results | latin1 | | character_set_server | latin1 | | character_set_system
CREATE TABLE `COLUMNS_V2` ( `CD_ID` bigint(20) NOT NULL, `COMMENT` varchar(256) CHARACTER SET latin1... COLLATE latin1_bin DEFAULT NULL, `COLUMN_NAME` varchar(767) CHARACTER SET latin1 COLLATE latin1_bin... `COLUMNS_V2_FK1` FOREIGN KEY (`CD_ID`) REFERENCES `CDS` (`CD_ID`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1... 1 row in set (0.00 sec) 可以看出，由于表使用的是默认的latin1字符集，所以中文显示不出来，应该使用utf8； 但是很奇怪，我整个MySQL都是使用... utf8; 所以第二种方法就是修改hive默认的SQL语句来实现； 1、通过关键字查找文件 find /home/otouser/software/hive |xargs grep -ri "latin1
字符集规则 默认的配置包括以下: 1)编译，指定了一个默认的字符集，默认字符集是latin1。...查看默认字符集默认情况下，mysql的字符集是 latin1。...| | character_set_connection | latin1 | | character_set_database...| latin1 | | character_set_server | latin1 | | character_set_system...init.d/mysqld restart 参考文章 《mysql编译安装脚本》 《Redmine Garbled》 小结 ---- 最后来总结下文章中的知识点 默认情况下，mysql的字符集是 latin1
实际是不一定，比如：gbk->unicode->latin1 不可以utf8->unicode->latin1 不可以上面2种转换不可以是因为latin1字符集只能表示256个字符，绝大部分GBK和...UTF8的字符在latin1字符集里面根本没有对应编码。...latin1) using latin1));E695B0E68DAEE5BA93这一种就是利用了latin1是万能字符集，覆盖了00-FF的所有区间，将UTF8和GBK视为单字节字节流，用Latin1...3.4 转为unicode后再转为latin1 无法表示，转为3F (latin1 中的?...上面的转换实际都失败了，因为latin1字符集只有256个字符，绝大多数的GBK和UTF8字符都无法用Latin1字符集表示。
CHARACTER SET latin2 COLLATE latin2_bin; 在这里我们有一个列使用latin1字符集和latin1_german1_ci校对规则。...需要注意的是，在一个latin2表中存储一个latin1列不会存在问题。...示例2：表和列定义 CREATE TABLE t1 ( c1 CHAR(10) CHARACTER SET latin1 ) DEFAULT CHARACTER SET latin1 COLLATE...latin1_danish_ci; 这次我们有一个列使用latin1字符集和一个默认校对规则。...因此，列c1的字符集是latin1，它的 校对规则是latin1_danish_ci。
--------------------------+-------------------------------------------+ | character_set_client | latin1...| | character_set_connection | latin1 | | character_set_database | latin1 | | character_set_filesystem...| binary | | character_set_results | latin1 | | character_set_server | latin1 | | character_set_system...1，方案一：在插入数据之前，先执行一条指令：set names latin1，但是我们如果断开连接，退出数据库之后，在连接进来以后，插入数据时如果不执行set names latin1，还是会乱码，说明这句指令没有让字符集永久生效... 2，方案二:在配置文件里面修改客户端和服务端参数，可以实现set names latin1；的效果，并且永久生效 首先在mysql文件夹下加入一个my.ini配置文件 ?
mysql> create database testdb charset Latin1; Query OK, 1 row affected (0.00 sec) mysql> use testdb;...Database changed mysql> create table student (id int , name varchar(20)) charset Latin1; Query OK, 0...) NOT NULL, `name` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1...DEFAULT NULL, #字段仍然是latin1编码 PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 1 row in set...40100 DEFAULT CHARACTER SET latin1 */ | +------+-----------------------------------------------------
这是因为创建的 mysql容器默认使用 latin1字符集，为了修正乱码问题需要设置 utf8 字符集。 环境描述 ---- 1....| +--------------------------+----------------------------+ | character_set_client | latin1...| | character_set_connection | latin1 | | character_set_database...| latin1 | | character_set_filesystem | binary | | character_set_results...| latin1 | | character_set_server | latin1 | | character_set_system
+| character_set_client | utf8mb4 || character_set_connection | utf8mb4 || character_set_database | latin1...|| character_set_filesystem | binary || character_set_results | utf8mb4 || character_set_server | latin1...------------------±---------------------------+8 rows in set (0.01 sec)你会看到| character_set_server | latin1...|就是这个character_set_server等于latin1导致的错误，需要手动改文件2、进入my.cnfvim /etc/my.cnf编辑my.cnf在[mysqld]下面character-set-client-handshake
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
