mysql latin1 支持中文吗
发布网友
发布时间：2022-04-23 20:32
共2个回答
热心网友
时间：2022-04-08 03:18
mysqllatin1数据库支持中文编码。
ISO－8859－1编码是单字节编码，向下兼容ASCII，其编码范围是0x00－0xFF，0x00－0x7F之间完全和ASCII一致，0x80－0x9F之间是控制字符，0xA0－0xFF之间是文字符号。
ISO－8859－1收录的字符除ASCII收录的字符外，还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。欧元符号出现的比较晚，没有被收录在ISO－8859－1当中。
因为ISO－8859－1编码范围使用了单字节内的所有空间，在支持ISO－8859－1的系统中传输和存储其他任何编码的字节流都不会被抛弃。
换言之，把其他任何编码的字节流当作ISO－8859－1编码看待都没有问题。这是个很重要的特性，MySQL数据库默认编码是Latin1就是利用了这个特性。ASCII编码是一个7位的容器，ISO－8859－1编码是一个8位的容器。
如果数据库内表的字符集是latin1，那么默认情况下中文也可被支持，latin1覆盖了所有单字节的值，任何其他的码流都可以被看做latin1。
把一个gbk编码的串写入latin1的表，不会有任何问题，保存的是原封不动的字节流，从表中读取已写入的串也不会有任何问题，且读出的字节流就和当初写入的完全一致。
读取出来以后，如果在终端下，就会理解成locale类型（如果locale系gbk，当时写入的gbk中文串可正常回显）
读取出来以后，如果要写入文件，则文件编码方式即当时写入的字节流编码，如gbk写入的，读出存入文件后，文件编码也是gbk！但是如果混着写（utf－8＋gbk），那编辑器就犯蒙了，就可能会显示会有乱码。
纯文本文件大多无文件头，编辑器是通过字节流自己识别编码方式和字符集的
总结，建DB和访问DB时如果都采用默认的latin1，那就不仅仅支持中文，而是支持任意的编码方式。
扩展资料：
数据库中文编码的注意事项：
1．基于可维护的角度，虽然latin1可用，但是还是尽量换成utf8或者gb系列；
2．出现乱码时：
SHOWVARIABLESLIKE＇character％＇SHOWVARIABLESLIKE＇collation＿％＇；
要保证数据库中存的数据与数据库编码一致，即数据编码与character＿set＿database一致；要保证通讯的字符集与数据库的字符集一致，即character＿set＿client，character＿set＿connection与character＿set＿database一致；
要保证SELECT的返回与程序的编码一致，即character＿set＿results与程序编码一致；要保证程序编码与浏览器、终端编码一致
要想简单一点，将各个字符集都设为一致的，写入mysql的配置文件，每次用客户端都设置一下字符集（setnames＇xxx＇），写入和读取时要记得确保字节流的编码是正确的。
参考资料：百度百科-数据库
热心网友
时间：2022-04-08 04:36
初学者往往会犯糊涂，mysql 的默认字符集 latin1 是否支持中文？
初步分析表明，是的，确实支持中文！(是初步的结论，只做了初步的分析)
1. 先来看看latin1 (参考百度百科)
Latin1是ISO-8859-1的别名，有些环境下写作Latin-1。
ISO-8859-1编码是单字节编码，向下兼容ASCII，其编码范围是0x00-0xFF，0x00-0x7F之间完全和ASCII一致，0x80-0x9F之间是控制字符，0xA0-0xFF之间是文字符号。
ISO-8859-1收录的字符除ASCII收录的字符外，还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。欧元符号出现的比较晚，没有被收录在ISO-8859-1当中。
因为ISO-8859-1编码范围使用了单字节内的所有空间，在支持ISO-8859-1的系统中传输和存储其他任何编码的字节流都不会被抛弃。换言之，把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题。这是个很重要的特性，MySQL数据库默认编码是Latin1就是利用了这个特性。ASCII编码是一个7位的容器，ISO-8859-1编码是一个8位的容器。
2. 稍微再想想字符集
是的，不用纠结太多了，如果数据库内表的字符集是latin1，那么默认情况下中文也可被支持！
· latin1覆盖了所有单字节的值，任何其他的码流都可以被看做latin1
·把一个gbk编码的串写入latin1的表，不会有任何问题，保存的是原封不动的字节流
·从表中读取已写入的串也不会有任何问题，且读出的字节流就和当初写入的完全一致
读取出来以后，如果在终端下，就会理解成locale类型（如果locale系gbk，当时写入的gbk中文串可正常回显）
读取出来以后，如果要写入文件，则文件编码方式即当时写入的字节流编码，如gbk写入的，读出存入文件后，文件编码也是gbk！但是如果混着写（utf-8 + gbk），那编辑器就犯蒙了，就可能会显示会有乱码。
注: 纯文本文件大多无文件头，编辑器是通过字节流自己识别编码方式和字符集的
3. 综上，建DB和访问DB时如果都采用默认的latin1，那就不仅仅支持中文，而是支持任意的编码方式！
附送几个数据库中文编码的经验教训：
1. 基于可维护的角度，虽然latin1没什么问题，但是还是尽量换成utf8或者gb系列
2. 出现乱码时：
SHOW VARIABLES LIKE 'character%'
SHOW VARIABLES LIKE 'collation_%';
a、要保证数据库中存的数据与数据库编码一致，即数据编码与character_set_database一致；
b、要保证通讯的字符集与数据库的字符集一致，即character_set_client, character_set_connection与character_set_database一致；
c、要保证SELECT的返回与程序的编码一致，即character_set_results与程序编码一致；
d、要保证程序编码与浏览器、终端编码一致
3. 要想简单一点的话，就将各个字符集都设为一致的，写入mysql的配置文件，每次用客户端都设置一下字符集(set names 'xxx')，写入和读取时要记得确保字节流的编码是ok的
