编码转换

在mysql中，对应的表字段编码通常默认为lartin1编码,在本地客户端显示的时候看着是乱码,但是通过mysql -u -p -h命令登录后,select查询到数据是正常的,通过jdbc或者php等去取回来的中文是乱码； 也就是中文在mysql中是lartin1，到我们自己本地或者用navicat等select却是乱码,使用mysql内置函数来转换一下 SELECT convert(unhex(hex(convert(name using latin1))) using utf8) as name FROM test 上面语句意思为,在表test中,字段name编码为lartin1查询后结果转换为utf8编码结果 ps(吐槽一下!!!):看到很多人还要通过jdbc查询的时候又要set names lartin1，还要new String(rs.getString("SampleColumnName").getBytes("ISO-8859-1"), "UTF-8")，扯了一大堆,最后结果还是乱码,有毛用,一个mysql内置函数就搞定了,理解起来也简单 来源： https://www.cnblogs.com/xjh713/p/8933523.html

mysql移植含有中文的数据时，很容易出现乱码问题。很多是在从mysql4.x向mysql5.x移植的时候出现。mysql的缺省字符集是 latin1，在使用mysql4.x的时候，很多人都是用的latin1字符集。而当使用mysql5时往往愿意使用utf8。那么我们的任务是不是要 把数据中的字符从latin1转为utf8呢？ 　　不是的。 　　用一句不大准确，但又比较形象的说法是，在之前的系 统中，我们是用latin1保存了使用gb系列字符集（gbk、gb2312等）的汉字。怎么这样说呢？ 　　mysql> show create table test\G 　　*************************** 1. row *************************** 　　Table: test 　　Create Table: CREATE TABLE `test` 　　`a` varchar(100) default NULL 　 　) ENGINE=InnoDB DEFAULT CHARSET=utf8 　　1 row in set (0.00 sec) 　 　mysql> show create table testlatin1\G 　　 *************************** 1. row *************************

数字签名原理简介（附数字证书） 首先要了解什么叫对称加密和非对称加密，消息摘要这些知识。 1. 非对称加密 在通信双方，如果使用非对称加密，一般遵从这样的原则：公钥加密，私钥解密。同时，一般一个密钥加密，另一个密钥就可以解密。 因为公钥是公开的，如果用来解密，那么就很容易被不必要的人解密消息。因此， 私钥也可以认为是个人身份的证明。 如果通信双方需要互发消息，那么应该建立两套非对称加密的机制（即两对公私钥密钥对），发消息的一方使用对方的公钥进行加密，接收消息的一方使用自己的私钥解密。 2.消息摘要 消息摘要可以将消息哈希转换成一个固定长度的值唯一的字符串。值唯一的意思是不同的消息转换的摘要是不同的，并且能够确保唯一。 该过程不可逆 ，即不能通过摘要反推明文（似乎SHA1已经可以被破解了，SHA2还没有。一般认为不可破解，或者破解需要耗费太多时间，性价比低）。 利用这一特性， 可以验证消息的完整性。 消息摘要通常用在数字签名中，下面介绍用法。 了解基础知识之后，就可以看一下数字签名和数字证书了。 3.数字签名 假设现在有通信双方A和B，两者之间使用两套非对称加密机制。 现在A向B发消息。 那么，如果在发送过程中，有人修改了里面密文消息，B拿到的密文，解密之后得到明文，并非A所发送的，信息不正确。 要解决两个问题：1. A的身份认证 2. A发送的消息完整性

unicode 是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。每个字符都对应一个编号，编号的范围是0-0x10FFFF来。Unicode 是为了解决 传统的字符编码方案 的局限而产生的，它为每种语言中的每个字符设定了统一并且唯一的 二进制 编码 UTF是“Unicode Transformation Format”的缩写，可以翻译成Unicode字符集转换格式，即怎样将Unicode定义的数字转换成程序数据。 在Unicode中：汉字“字”对应的数字是23383（十进制），十六进制表示为5B57。在Unicode中，我们有很多方式将数字23383表示成程序中的数据，包括： UTF-8 、 UTF-16 、 UTF-32 。 UTF-8以字节为单位对Unicode进行编码。并且是变长的，节省补0空间（总长 = 1字节+补0空间，比如对于 英文字符只用1个字节表示，不用补0）。而 Unicode 总是需要固定长的空间（总是要 补0）。 Unicode编码(十六进制)　 UTF-8 字节流(二进制) 000000-00007F 0xxxxxxx 000080-0007FF 110xxxxx 10xxxxxx 000800-00FFFF 1110xxxx 10xxxxxx 10xxxxxx 010000-10FFFF

目录 1.概述 2.ASCII编码 3.历史问题 4.Unicode 4-1.Unicode 编码方案 4-2.关于bom 5.UTF-8 6.UTF-16 1.概述 对于ASCII编码，相信同学们都比较了解，那么对于Unicode、UTF-8和UTF-16，它们是怎么编码的呢？以及它们之间的关系是什么呢？它们与ASCII之间又有什么关系？ 本文就来回答这两个问题。 2.ASCII编码 在学校学 C 语言的时候，了解到一些计算机内部的机制，知道所有的信息最终都表示为一个二进制的字符串，每一个二进制位有 0 和 1 两种状态，通过不同的排列组合，使用 0 和 1 就可以表示世界上所有的东西，感觉有点中国“太极”的感觉——“太极生两仪，两仪生四象，四象生八卦”。 在计算机种中，1 字节对应 8 位二进制数，而每位二进制数有 0、1 两种状态，因此 1 字节可以组合出 256 种状态。如果这 256 中状态每一个都对应一个符号，就能通过 1 字节的数据表示 256 个字符。美国人于是就制定了一套编码（其实就是个字典），描述英语中的字符和这 8 位二进制数的对应关系，这被称为 ASCII 码。 ASCII 码一共定义了 128 个字符，例如大写的字母 A 是 65（这是十进制数，对应二进制是0100 0001）。这 128 个字符只使用了 8 位二进制数中的后面 7 位

一、来历 为了统一编码，各大龙头企业就决定坐下来对全世界的字符进行编码，并且尽量兼容现有字符集，这就有了unicode编码。Unicode用了21个二进制位，能够编码一百多万个字符，但实际上并没有编码这么多。U+XXXX中XXXX就是码点，就是字符在unicode的数字表示。 编码空间被分成 17 个平面（plane），每个平面有 65,536 个字符。0 号平面叫做「基本多文种平面」（Basic Multilingual Plane, BMP），涵盖了几乎所有你能遇到的字符，除了 emoji。其它平面叫做补充平面，大多是空的。 二、UTF-32、UTF-16、UTF-8 什么字符被表示成什么样子的规定有了，就要考虑怎么存起来了，这就分成了UTF-32、UTF-16、UTF-8三种了。所以UTF-32、UTF-16、UTF-8只是unicode的三种实现方式。 三、UTF-32 unicode用了21位，那我就用4个字节存，准错不了，这就是UTF-32，由于它的极度浪费，所以基本上没人用。 四、UTF-16 UTF-16编码介于UTF-32与UTF-8之间，同时结合了定长和变长两种编码方法的特点。UTF-16把字符存储成2个字节或者4个字节。 具体如下： 基本平面的字符占用2个字节，辅助平面的字符占用4个字节。也就是说，UTF-16的编码长度要么是2个字节（U+0000到U

1.下列正确的是（A） A.形式参数可被视为local variable B.形式参数可被所有的字段修饰符修饰 C.形式参数为方法被调用时，真正被传递的参数。 D.形式参数不可以是对象 注： A：形式参数可被视为local variable。形参和局部变量一样都不能离开方法。都只有在方法内才会发生作用，也只有在方法中使用，不会在方法外可见。 B： 对于形式参数只能用final修饰符，其它任何修饰符都会引起编译器错误。但是用这个修饰符也有一定的限制，就是在方法中不能对参数做任何修改。 不过一般情况下，一个方法的形参不用final修饰。只有在特殊情况下，那就是：方法内部类。 一个方法内的内部类如果使用了这个方法的参数或者局部变量的话，这个参数或局部变量应该是final。 C：形参的值在调用时根据调用者更改，实参则用自身的值更改形参的值（指针、引用皆在此列），也就是说真正被传递的是实参。 D：方法的参数列表指定要传递给方法什么样的信息，采用的都是对象的形式。因此，在参数列表中必须指定每个所传递对象的类型及名字。想JAVA中任何传递对象的场合一样，这里传递的实际上也是引用，并且引用的类型必须正确 2.Which keyword can protect a class in a package from accessibility by the classes outside the

很多人都把Unicode编码挂在嘴边，其实咱们现实生活中遇到的编码基本都是Unicode的 因为Unicode兼容了大多数老版本的编码规范例如 ASCII Unicode编码定义了这个世界上几乎所有字符（就是你眼睛看到的长那个样子的符号）的数字表示 也就是说Unicode为每个字符发了一张身份证，这张身份证上有一串唯一的数字ID确定了这个字符 在这个纷乱世界上存在的唯一性。Unicode给这串数字ID起了个名字叫［码点］（Code Point） 而很多人说的编码其实是想表达［Unicode转换格式］（即UTF，Unicode Transformation Formats） 有没有觉得眼前一亮豁然开朗？没错 这就是我们看到的UTF-8/UTF-16/UTF-32的前缀来源 这个［Unicode转换格式］的存在是为了解决［码点］在计算机中的二进制表现形式而设计的 毕竟我们的机内表示涉及存储位宽，兼容古老编码格式，码点是数值过大的罕见字符等问题 ［码点］经过映射后得到的二进制串的转换格式单位称之为［码元］（Code Unit）。也就是说如果有一种UTF的码点二进制表示有n字节，其码元为8位（1个byte），那么其拥有码元n个。每种UTF的码元都不同，其宽度被作为区分写在了UTF的后缀——这就是UTF-8/UTF-16/UTF-32的由来。UTF-8的码元是8位的，UTF

1. 字符编码简介 1.1. ASCII ASCII (American Standard Code for Information Interchange)，是一种单字节的编码。计算机世界里一开始只有英文，而单字节可以表示256个不同的字符，可以表示所有的英文字符和许多的控制符号。不过ASCII只用到了其中的一半（\x80以下），这也是MBCS得以实现的基础。 1.2. MBCS 然而计算机世界里很快就有了其他语言，单字节的ASCII已无法满足需求。后来每个语言就制定了一套自己的编码，由于单字节能表示的字符太少，而且同时也需要与ASCII编码保持兼容，所以这些编码纷纷使用了多字节来表示字符，如 GBxxx 、 BIGxxx 等等，他们的规则是，如果第一个字节是\x80以下，则仍然表示ASCII字符；而如果是\x80以上，则跟下一个字节一起（共两个字节）表示一个字符，然后跳过下一个字节，继续往下判断。 这里，IBM发明了一个叫Code Page的概念，将这些编码都收入囊中并分配页码，GBK是第936页，也就是 CP936 。所以，也可以使用CP936表示GBK。 MBCS (Multi-Byte Character Set)是这些编码的统称。目前为止大家都是用了双字节，所以有时候也叫做 DBCS (Double-Byte Character Set)。必须明确的是

Python常用字符编码 http://www.cnblogs.com/schut/p/8406897.html Python常见字符编码间的转换 在字符串写入文件时，有时会因编码问题导致无法写入，可在open方法中指定encoding参数 chfile = open(filename, 'w', encoding='utf-8') open()默认新建的是系统文件的编码格式，比如创建了一个txt文件，则该文件在macOS中是ascii格式字符串，但是写入时write()要求使用utf-8格式字符串所以要报错 encode decode 来源： https://www.cnblogs.com/TomBombadil/p/10979575.html