最近对latin-1这个字符集产生了不少好感

【简介】

　　最近我要解析一个数据库中间件的日志、这个中间件会在日志中记录SQL发往的后台DB ,执行耗时，对应的SQL；中间件直接把SQL写到

　　了日志中去，并没有对SQL进行适当的编码转换；理想情况下这个也不会有什么问题，不幸的是我就面对着这种情况，client的发给中间件

　　的SQL有可能是"utf-8"，也有可能是"gbk",也有可能是"gb2132"；所以使用中间件的日志文件用任何一种编码方式都不成正确的解码它，

　　

　　幸运的是我要做的工作只要解决出日志中所涉及到的数据库名和表名就行，所以我并不一定要完全解码这个文件。

【复现一下那个中间件写日志的大致逻辑】

以下我会用python代码来描述上面的情况,可以看到对于同一个文件以不同的编码写入了内容

with open('proxy_backup_sql.log','bw') as user_log_hander:
    user_log_hander.write("192.186.100.10 | 0.012 | select id from tempdb.person where name='张三'; \n".encode('utf8'))
    user_log_hander.write("192.186.100.10 | 0.012 | select id from tempdb.person where name='杨白劳'; \n".encode('gbk'))

　　

　　对于上面的情况不管你是用utf-8 还是用gbk打开文件它们会乱码的、

【用什么编码都是不可能正常打开这个文件的】

 1、UTF8打开

with open('proxy_backup_sql.log','r',encoding='utf8') as proxy_backup_log_handler:
    for line in proxy_backup_log_handler:
        print(line,end='')

Traceback (most recent call last):
  File "main.py", line 22, in <module>
    for line in proxy_backup_log_handler:
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/codecs.py", line 321, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd1 in position 142: invalid continuation byte

2、用gbk打开

with open('proxy_backup_sql.log','r',encoding='gbk') as proxy_backup_log_handler:
    for line in proxy_backup_log_handler:
        print(line,end='')

192.186.100.10 | 0.012 | select id from tempdb.person where name='寮犱笁';
192.186.100.10 | 0.012 | select id from tempdb.person where name='杨白劳';

可以看到没有报异常、但是这个只是巧合、gbk刚好能解码utf8编码下的“张三”并把它解码成了“寮犱笁”

【latin-1 有的牛逼之处】

　　latin-1 这个字符集的牛逼之处

---