❶ python 什么是magic string
无论是python还是其它的编程语言，都有magic string这类东西存在。它并不是phtyon专有的东西。类似的还有magic number这样的。
前两年有关linux一个版本的更新就有个关于魔法数字的小插曲：
linux一个版本更新出来后，对某个类型的显卡的驱动支持出现了问题，然后相关代码被修复，其中在代码中就直接对一个地址加了一个偏移量，类似python中addr_offset += 123这样的操作，这里，这个123就是一个魔法数：它为什么是123？为什么不可以是124或者别的什么值？没有说明，没有理由，它就这么神奇的出现，然后问题就神奇的被解决了。
为此，linux项目负责人员很恼火，在项目中都说了脏话。
无论是magic string还是magic number，统称为magic value，即，魔法值。
它们在代码中突然出现，直接使用，没有说明，无从追溯。
这对代码的可读性，可维护性都带来了负面效应。
拿个简单的例子来说，在python中，我们有时会使用zipfile来处理压缩文件，比如这样：
z_file.writestr(z_name,data,zipfile.ZIP_DEFLATED)
但如果写成：
z_file.writestr(z_name,data,8)
那么，这个8就是一个魔法值：它是什么？它哪里来的？为什么是8而不是9？除非你去读zlip的文档或源代码，否则不知道这个8是什么。而使用`zipfile.ZIP_DEFLATED`的话，即使你不了解zlip，看到这个常量名，也知道它是压缩(deflated)的zip选择了。
魔法值让我们需要了解相关很多内容时才能读懂一句代码，并且修改它的功能或修正它的bug需要同样多的精力。
再拿一个例子来说：
defgetfileencode(file):
"""测试得到文本类型文件可能使用的编码格式
它不一定就是正确的
>>>getfileencode('errorlog.txt')
'utf_8_sig'
>>>getfileencode('星.txt')
'gb18030'
>>>getfileencode(r'D:/Python/baseweb\app.py')
'utf_8'
"""
codes=['utf_8','utf_16','gb18030','big5']
withopen(file,'rb')asf:
b=f.read()
forcodeincodes:
try:
b.decode(code)
ifcode=='utf_8'andb.startswith(b'xefxbbxbf'):
code='utf_8_sig'
break
except(Exception,):
continue
returncode
第17行中的b'xefxbbxbf'就是一个魔法值,为什么是这个值?你只有了解到windows（MS）自作主张的在utf-8编码的文本文件最开始加了这么一段作为这种编码的标识时，才能理解为什么这么写。如果我们将它命名为一个常量:
UTF8_BOM=b'xefxbbxbf'
然后在代码中的if这样写：
ifcode=='utf_8'andb.startswith(UTF8_BOM）
你无需了解关于微软在utf-8文件前加了什么，就能知道这个判断的意思：如果它是utf-8编码，并且以BOM开始……
这是避免代码中出现魔法值的最常见的办法。
❷ ASCII、Unicode、UTF-8、UTF-8（without BOM）傻傻分不清
前言
Github上下载了一份代码打算学习，源工程是在linux上开发的，我在Windows上编译通过不了，很多莫名奇妙的错误，最后发现源代码文件是UTF-8（without BOM）编码的，Notepad++修改编码格式为UTF-8编译通过。
ASCII
毕竟在电子系混过四年，这个词不陌生，用一个字节的低7位来表示128个英文字符（0xxxxxxx），可是地球上的文字又不是只有英文，光汉字就好几万个，所以每个国家和地区又做了一套符合自身情况的编码规范，比如简体中文编码标准GB2312，使用两个字节来表示一个汉字，可以表示65536个中文字符。但是如果每个国家都这么搞那不就乱套了嘛，于是Unicode就应运而生了。
Unicode
Unicode是个符号集，与ASCII类似，只不过容量要大得多，可以理解成一张表，为世界上的每一个字符指定了一个惟一的二进制代码，但是它并没有规定这个二进制代码如何存储，于是乎UTF-8、UTF-8（without bom）、UTF-16、UTF-32应运而生。
UTF-8
UTF-8是Unicode的实现方式之一，最大特点就是根据符号自动变化字节长度，即可变长编码，编码方式如下图所示：
UTF-8（without BOM）
BOM（Byte Order Mark）字节顺序标记，即可以用来标记是大端还是小端。在Unicode里面定义了一个叫做”ZERO WITH NO-BREAK SPACE“的不可见字符，对应的Unicode编码是FEFF，有BOM的文件即文件开头有”ZERO WITH NO-BREAK SPACE“不可见字符，反之则没有。若是大端编码，则文件开头是FEFF，小端则是FFFE。BOM是为了配合UTF-16和UTF-32使用，因为它们编码编码单元包含多个字节，涉及字节序的问题。
UTF-8以单字节为编码单元，不存在字节序的问题，但是可以使用BOM来表明所使用的编码方式，字符”ZERO WITH NO-BREAK SPACE“在UTF-8中的编码是EF BB BF，所以当解码文件时发现开头的单个字节是EF BB BF即说明是UTF-8编码，Windows就是使用BOM来标记文本的编码方式的。
怎样区分UTF-8、UTF-16和UTF-32
打开文本时根据BOM来区分当前文件的编码类型