字符编码

create database {database name} CHARACTER SET utf8 COLLATE utf8_general_ci CHARACTER : 字符集（多数情况下要选择一个支持中文的字符集） COLLATE : 排序规则，一般来说每种CHARSET都有多种它所支持的COLLATE，并且每种CHARSET都指定一种COLLATE为默认值。例如Latin1编码的默认COLLATE为latin1_swedish_ci，GBK编码的默认COLLATE为gbk_chinese_ci，utf8mb4编码的默认值为utf8mb4_general_ci Case Insensitive 来源： https://www.cnblogs.com/yxfcnbg/p/12657345.html

1.先查服务端的字符集 或者 2.再查客户端的字符集 两个字符集（不是语言）一致的话就不会乱码了 CONVERT(c1,set1,set2) 【功能】将源字符串c1 从一个语言字符集set2转换到另一个目的set1字符集 【参数】c1,字符串，set1,set2为字符型参数 【返回】字符串 convert(utl_raw. cast_to_raw(str_1), 'ZHS16GBK', 'US7ASCII') 参考资料：1. Oracle 服务器 客户端 US7ASCII、 UTF8字符编码问题 详细资料 一、 什么是Oracle字符集 Oracle字符集是一个字节数据的解释的符号集合,有大小之分,有相互的包容关系。ORACLE 支持国家语言的体系结构允许你使用本地化语言来存储，处理，检索数据。它使 数据库 工具，错误消息，排序次序，日期，时间，货币，数字，和日历自动适应本地化语言和平台 影响Oracle数据库字符集最重要的参数是NLS_LANG参数。 它的格式如下: NLS_LANG = language_territory.charset 它有三个组成部分(语言、地域和字符集)，每个成分控制了NLS子集的特性。 其中: Language： 指定服务器消息的语言， 影响提示信息是中文还是英文 Territory： 指定服务器的日期和数字格式， Charset： 指定字符集。 如

一、什么是 Oracle 字符集 Oracle字符集是一个字节数据的解释的符号集合,有大小之分,有相互的包容关系。ORACLE 支持国家语言的体系结构允许你使用本地化语言来存储，处理，检索数据。它使数据库工具，错误消息，排序次序，日期，时间，货币，数字，和日历自动适应本地化语言和平台。 影响Oracle数据库字符集最重要的参数是NLS_LANG参数。 它的格式如下: NLS_LANG = language_territory.charset 它有三个组成部分(语言、地域和字符集)，每个成分控制了NLS子集的特性。 其中: Language： 指定服务器消息的语言， 影响提示信息是中文还是英文 Territory： 指定服务器的日期和数字格式， Charset： 指定字符集。 如:AMERICAN _ AMERICA. ZHS16GBK 从NLS_LANG的组成我们可以看出，真正影响数据库字符集的其实是第三部分。 所以两个数据库之间的字符集只要第三部分一样就可以相互导入导出数据，前面影响的只是提示信息是中文还是英文。 二．字符集的相关知识： 2.1 字符集 实质就是按照一定的字符编码方案，对一组特定的符号，分别赋予不同数值编码的集合。Oracle数据库最早支持的编码方案是US7ASCII。 Oracle的字符集命名遵循以下命名规则: <Language><bit size>

一、电脑字符集的历史 　　1、电脑是如何将二进制与字符对应起来的？ 　　　　我们知道，电脑底层只认识0和1的二进制数据，为了让电脑可以跟人类互动， 我们使用8个二进制位（即1个字节）来对应一个更复杂的数字， 　　　　比如：使用二进制“01000001”来指代十进制“65”，也就是大写字母A 　　　　实际使用场景中，人类利用键盘打字符“A”时，实际上是打65这个数字，电脑再到表中寻找65所代表的二进制数据“01000001”，实际处理的是这个二进制数据，这样就对应起来了， 　　　　这种对应关系表就是最早的字符编码集ASCII码表，如下图： 　　 　 　　2、字符集是如何发展成一个庞大家族的？ 　　　　电脑最初是西方人发明的，欧美国家的字符比较少，他们仅占用了前面127个位置就已经够用了，而8位的二进制数据最多可以表示255个不同的字符，剩下的128个字符就留给了别的国家，那么别国肯定是不够用的，怎么办？ 　　　　于是聪明的中国人在ASCII码中规定几个位置，默认当电脑要寻找这几个位置的字符时就映射到另外一张表格中，而这张表格中存储了完整的中文字符，中文字符的发展历史如下： 　　　　a、GB2312：支持7000个汉字 　　　　b、GBK1.0：支持20000+个中文字符 　　　　c、GB18030：支持27000+个中文字符 　　　　d、Unicode

一、了解字符编码的知识储备 　　1. 文本编辑器存取文件的原理（nodepad++，pycharm，word） 　　　　 打开编辑器就打开了启动了一个进程，是在内存中的，所以在编辑器编写的内容也都是存放与内存中的，断电后数据丢失，因而需要保存到硬盘上，点击保存按钮，就从内存中把数据刷到了硬盘上。在这一点上，我们编写一个py文件（没有执行），跟编写其他文件没有任何区别，都只是在编写一堆字符而已。 　　　　即:在没有点击保存时,我们所写的内容都是写入内存。注意这一点，很重要！！当我们点击保存，内容才被刷到硬盘。 　　　　上面做了两件事：写内容到内存,从内存将内存刷到硬盘。这是两个过程。 2. python解释器执行py文件的原理 ，例如python test.py 　　　　第一阶段：python解释器启动，此时就相当于启动了一个文本编辑器 　　　　第二阶段：python解释器相当于文本编辑器，去打开test.py文件，从硬盘上将test.py的文件内容读入到内存中 　　　　第三阶段：python解释器解释执行刚刚加载到内存中test.py的代码 　　　　python解释器执行py文件分为两个步骤:1.将文件读到内存,2.解释执行内容。 二、字符编码简介 　　要搞清楚字符编码，首先要解决的问题是： 什么是字符编码 ？ 　　我们都知道，计算机要想工作必须通电,也就是说‘电’驱使计算机干活

ASCII，Unicode和UTF-8终于找到一个能完全搞清楚的文章了 转载:Deft_MKJing宓珂璟 https://blog.csdn.net/Deft_MKJing/article/details/79460485 平时喜欢写东西，看博客，一直对编码有些懵，今天下午也不知道看到了什么，突然想了解下，就找到了这个文章，看完真的豁然开朗，这个必须留下来做纪念。 1.ASCII 我们知道，计算机内部，所有信息最终都是一个二进制值。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从00000000到11111111。 上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为 ASCII 码，一直沿用至今。 ASCII 码一共规定了128个字符的编码，比如空格SPACE是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的一位统一规定为0。 2.非ASCII编码 英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。比如，在法语中，字母上方有注音符号

在开发微信开放平台, 接入微信公众号的数据时, 关于用户的nickname和文本消息是,大量出现emoji的文本信息, 超时了utf-8字符集的存储范围 在存储数据时, 出现部分特殊字符存储字符串失败. 服务端解决方案 查阅MySQL官方文档时,给出如下支持utf8转utf8mb4的官方处理办法 https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-conversion.html 上述的步骤只是针对server端的配置. 对于客户端需要额外特殊的处理 因为我目前的项目, 使用的是JAVA编写, 使用JDBC连接操作数据库, 如下针对的JDBC操作的解决方案 JDBC的URL之前的配置方式 String url = "jdbc:mysql://HOST:PORT/DATABASE?useUnicode=true&characterEncoding=UTF-8"; 在连接配置中,声明UTF-8的字符编码,在目前的存储需求上来讲,在存储emoji字符串时会报错. 就算服务端的数据库设置了utf8mb4字符集类型 客户端修改成如下配置 String url = "jdbc:mysql://HOST:PORT/DATABASE?useUnicode=true&characterEncoding=utf8mb4"; 客户端连接时报错

一般的，vim打开中文文件时会出现乱码，原因比较复杂，不罗嗦了。直接讲解决办法 set fileencoding=gb18030 set fileencodings=utf-8,gb18030,utf-16,big5 想看这样设置的原因吗？请继续。下文在网络中广泛流传 vim里面的编码主要跟三个参数有关：enc(encoding), fenc(fileencoding)和fencs(fileencodings) 其中fenc是当前文件的编码，也就是说，一个在vim里面已经正确显示了的文件(前提是你的系统环境跟你的enc设置匹配)，你可以通过改变 fenc后再w来将此文件存成不同的编码。比如说，我:set fenc=utf-8然后:w就把文件存成utf-8的了，:set fenc=gb18030再:w就把文件存成gb18030的了。这个值对于打开文件的时候是否能够正确地解码没有任何关系。 fencs就是用来在打开文件的时候进行解码的猜测列表。文件编码没有百分百正确的判断方法，所以vim只能猜测文件编码。比如我的vimrc里面这个的设置是 set fileencodings=utf-8,gb18030,utf-16,big5 所以我的vim每打开一个文件，先尝试用utf-8进行解码，如果用utf-8解码到了一半出错(所谓出错的意思是某个地方无法用utf-8正确地 解码)

　　 使用CentOS中的Vim 文本编辑器出现中文乱码的问题。 　 凡是字符乱码的问题，都是字符集不匹配的问题引起的。这里的字符集不匹配只的是文件的编码和解码方式不匹配，同时可能涉及到不只一次的解码过程。 　　计算机中的所有文件都是以二进制格式存储的（计算机可识别内容）。我们在读取文件内容时，均是通过不同的软件读取的，软件在读取文件内容时，需要使用不同的字符集来识别文件中的人类可识别内容。字符集就是一个数值与人类可识别基础字符的对照表。 　　一个文件 有自己的编码字符集，编辑器在读取文件时有自己的字符集，在linux系统中还会涉及到终端的显示字符集。 　在Xshell终端中使用Vim打开文件时，中文出现乱码。分析原因时要考虑：1.文件的原始编码方式 2.vim打开文件的编码方式 3. xshell 终端的编码方式。 在 Vim 中主要有三个和字符集相关的变量: encoding(enc) , fileencoding(fenc) , fileencodings(fencs). fileencodings：打开文件的时候进行解码的猜测列表。 fileencoding ：用于设置保存文件时使用的字符集。 encoding：用于设置编辑文件时使用的字符集。　　　 例如：可以使用下面的命令 1. :edit ++enc=<encoding> [filename]

1. ASCII码 我们知道，在计算机内部，所有的信息最终都表示为一个二进制的字符串。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从0000000到11111111。 上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为ASCII码，一直沿用至今。 ASCII码一共规定了128个字符的编码，比如空格“SPACE”是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的1位统一规定为0。 2、非ASCII编码 英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。比如，在法语中，字母上方有注音符号，它就无法用ASCII码表示。于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。比如，法语中的é的编码为130（二进制10000010）。这样一来，这些欧洲国家使用的编码体系，可以表示最多256个符号。 但是，这里又出现了新的问题。不同的国家有不同的字母，因此，哪怕它们都使用256个符号的编码方式，代表的字母却不一样。比如