16进制编码（编码问题随理解深入持续更新中）

Posted 2020-10-21 neozheng

16进制：

# 十进制转换成8进制： 
oct ( 数字)
# 十进制转换成16进制：  
hex( 数字）

进制转换：https://blog.csdn.net/u012063703/article/details/42609833

 

CPU、内存、硬盘我们看到都是采用的16进制计算。

一个字节（byte）能够用2个16进制的数来表示。4个2进制对应1个16进制。

 

编码：

所有的系统、编程语言都默认支持Unicode。

编码和解码：

# 解码：decode()
UTF-8/GBK... --> decode 解码 --> Unicode
# 编码：encode()
Unicode --> encode 编码 --> GBK / UTF-8 ..

假设某Python文件是以UTF-8保存的，现在Python2上运行，解释器读取该文件： 先从硬盘上按照声明的UTF-8格式读取到内存里， 但此时，Python2不会将读取的UTF-8格式的文本自动转换成Unicode的格式，也就是说解释器把该文件读取到内存时 该文件还是UTF-8的格式，  此时你在Windows上打印，由于Windows中文版默认的终端是GBK，而打印的结果是以UTF-8的格式输出，这个时候显示结果就会出现乱码。

以下程序在Python2上运行：

s = \'哈哈哈\'
print s     # 这个输出结果会出现乱码，原因如上所说

s1 = s.decode(\'utf-8\')   # 对 s进行解码（就是解码成Unicode），括号内要写明对哪种格式的编码进行解码（如本例中的对UTF-8解码）
print s1       #  这个打印结果就不会出现乱码， 因为经过解码s1已经变成了Unicode的格式， 而Unicode和GBK又有一个映射关系、能够互相兼容，所以显示结果不会出现乱码
print type（s1）   #利用这种方法能显示出s1的格式是Unicode

s2 = s1.encode（‘GBK’）  #对s1再进行编码（就是把Unicode转换成其他类型的编码。例如本句中的转换成GBK），把s1转换成GBK格式并赋值给s2（括号内要写明编码成的格式，例如本句中的GBK）
print s2     #这个打印结果不会出现乱码， 因为s2是GBK格式的，而系统默认的也是GBK， 所以能正常显示出来。

s3 = s1.encode（‘utf-8’）   # 对s1进行编码，再把s1转换成utf-8的格式并赋值给s3
print s3     # 这个打印结果也会出现乱码， 因为s3也是utf-8格式的，在系统默认的GBK终端中显示会出现乱码

总结：

Python3中：
文件的默认编码是utf-8，
读取到内存里的字符串的编码是：Unicode  （Python3读取到内存时都会自动转成Unicode）

Python2中：
文件默认编码是：ASCII
读取到内存里的字符串的编码： 默认是ASCII，但是，如果文件头声明了何种编码，那读取到内存里的字符串就是该种编码（如： 假如文件开头声明了是GBK，那读取到内存的字符串就是GBK格式）。
在Python2里面， Unicode是一个  单独类型。

 

转编码是不可逆的。转编码的过程中要是出现乱码就得重新写，所以，不要转编码。

终端（terminal）是继承操作系统的编码

 

Python bytes类型：

# Python2： 
Python2中的字符串其实更应该称为字节串；
在Python2中， bytes == str
另外， Python2中还有个单独的类型是Unicode，把字符串解码后就会变成Unicode

# Python3：
PY3除了把字符串的编码改成了Unicode，还把str和bytes做了明确的区分： str就是Unicode格式的字符，bytes是单纯的二进制

 

最后再提示一下，Python只要出现各种编码问题，无非是哪里的编码设置出错了
常见编码错误的原因有：

• Python解释器的默认编码
• Python源文件文件编码
• Terminal使用的编码
• 操作系统的语言设置

编码问题参考这篇文章：   http://www.cnblogs.com/alex3714/articles/7550940.html