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包含所有1字节的值，其他所有码流均可视为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、保证选择返回与程序代码匹配，即character_set_results与程序代码匹配；
d、保证程序代码与浏览器、终端代码一致
3 .为简化起见，确保每个字符集一致，写入mysql配置文件，在客户端设置字符集(set names 'xxx )，并确保字节流编码正确，然后写入和读取