https://github.com/redisson/redisson/wiki/2.-Configuration#

Redis data codec. Used during read and write Redis data. Several implementations are available:

Codec class name
			
Description
		
org.redisson.codec.FstCodec
			
FST up to 10x faster than JDK Serialization codec. Default codec
		
org.redisson.codec.JsonJacksonCodec
			
Jackson JSON codec
		
org.redisson.codec.MarshallingCodec
			
JBoss Marshalling binary codec
		
org.redisson.codec.AvroJacksonCodec
			
Avro binary json codec
		
org.redisson.codec.SmileJacksonCodec
			
Smile binary json codec
		
org.redisson.codec.CborJacksonCodec
			
CBOR binary json codec
		
org.redisson.codec.MsgPackJacksonCodec
			
MsgPack binary json codec
		
org.redisson.codec.IonJacksonCodec
			
Amazon Ion codec
		
org.redisson.codec.KryoCodec
			
Kryo binary codec
		
org.redisson.codec.SerializationCodec
			
JDK Serialization codec
		
org.redisson.codec.LZ4Codec
			
LZ4 compression codec
		
org.redisson.codec.SnappyCodec
			
Netty's implementation of Snappy compression codec
		
org.redisson.codec.SnappyCodecV2
			
Snappy compression codec based on snappy-javaproject
		
org.redisson.codec.TypedJsonJacksonCodec
			
Jackson JSON codec which doesn't store type id (@class field) during encoding and doesn't require it for decoding
		
org.redisson.client.codec.StringCodec
			
String codec
		
org.redisson.client.codec.LongCodec
			
Long codec
		
org.redisson.client.codec.ByteArrayCodec
			
Byte array codec
		
org.redisson.codec.CompositeCodec
			
Used to mix different codecs as one
		
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

    hello~大家新年好，已经好久没有更博了，刚刚在运行python文件的时候竟然报SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 2-3: tr这个错误，其实引起这个错误的原因就是转义的问题。

    举个例子，在文件中我传入的文件路径是这样的

sys.path.append('c:\Users\mshacxiang\VScode_project\web_ddt')

    原因分析：在windows系统当中读取文件路径可以使用\,但是在python字符串中\有转义的含义，如\t可代表TAB，\n代表换行，所以我们需要采取一些方式使得\不被解读为转义字符。目前有3个解决方案

1、在路径前面加r，即保持字符原始值的意思。

sys.path.append(r'c:\Users\mshacxiang\VScode_project\web_ddt')

2、替换为双反斜杠

sys.path.append('c:\\Users\\mshacxiang\\VScode_project\\web_ddt')

3、替换为正斜杠

sys.path.append('c:/Users/mshacxiang/VScode_project/web_ddt')

 

0x00 问题引出：

 

最近在做一个买房自动化分析Python脚本，需要爬取网页。 

在使用urllib获取reqest的response的时候，还要进行解码。 

见语句：

result = res.decode('utf-8')

当执行该语句的时候，会造成异常：







UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe5 in position 103339: invalid continuation byte






0x01 问题分析

该情况是由于出现了无法进行转换的 二进制数据 造成的，可以写一个小的脚本来判断下，是整体的字符集参数选择上出现了问题，还是出现了部分的无法转换的二进制块：

#python3
#以读入文件为例：
f = open("data.txt","rb")#二进制格式读文件
while True:
    line = f.readline()
    if not line:
        break
    else:
        try:
            #print(line.decode('utf8'))
            line.decode('utf8')
            #为了暴露出错误，最好此处不print
        except:
            print(str(line))

手写了一段代码，可以通过这段代码的输出来判断哪里出现了问题。

1.如果输出的代码都是hex形式的，可能就是你选择的解码字符集出现了错误。 对于python2.7版本的来说，网上有使用这样一种看上去很霸气，其实很low的方式，来处理：
#coding=utf8
import sys
reload(sys)
sys.setdefaultxxxx("utf8")

其实，这可以看作是python2系列版本的小bug,需要自行重新设置一下默认的编码字符集，如果还要这么设置的话，decode()的参数还拿来干嘛。 

所以，在python3版本中，就已经取消了这个方法。

2.如果是字符集出现错误，建议多选择几种字符集测试一下： 选择的经验是： 如果是爬取到的网页文件，可以查看网页文件的meta标签下的charset属性值。
例如：

<meta charset="UTF-8">

也可以使用notepad++打开，查看下右下角的部位，会指示该文件是那种编码。

3.有的情况，是这样的，整个文件是好的，如果用notepad++打开后，能够看到文件是可以打开的，似乎什么问题都没有发生过，但是，用python进行解码的时候，却会出现错误。
我们运行上面的测试脚本，可以看到出现这样的情况：

    <li id="J_menuHistory" data-page="J_pageHistory">
                                    <a><i class="icon-history"></i>播放历史     \0xe5 </a>

当然，这段代码是我随手写的一个例子，这里，可以注意看到这个0xe5,这是无法转换出来的部分，这是不属于编码字符集中的部分。所以，在进行编码转换的时候，会报错。

0x03 解决方法

修改字符集参数，一般这种情况出现得较多是在国标码(GBK)和utf8之间选择出现了问题。
出现异常报错是由于设置了decode()方法的第二个参数errors为严格（strict）形式造成的，因为默认就是这个参数，将其更改为ignore等即可。例如:
line.decode("utf8","ignore")

‘utf-8’ codec can’t decode byte 0xff in position 0: invalid start byte
觉得有用的话,欢迎一起讨论相互学习~


今天使用语句
image_raw_data_jpg = tf.gfile.FastGFile('../test_images/test_1.jpg', 'r').read()

读取图片文件的时候遇到了以下问题:
'utf-8' codec can't decode byte 0xff in position 0: invalid start byte

原因:
0x92 即 10010010，UTF8 中编码一个字符的第一个字节（start byte）只可能是 0xxxxxxx、110xxxxx、1110xxx、11110xxx……而后面的字节只可能是 10xxxxxx。也就是说 0x92 只能作为后面的字节，却出现在了第一个字节的位置。
出现这种问题绝大部分情况是因为文件不是 UTF8 编码的（例如，可能是 GBK 编码的），而系统默认采用 UTF8 解码。解决方法是改为对应的解码方式。
极少数情况是因为文件损坏了或者和一部分非 UTF8 编码混在一起，可以修复文件或采用 replace 等方式解码。
解决方案
将’r’改为’rb’的形式,即:
image_raw_data_jpg = tf.gfile.FastGFile('../test_images/test_1.jpg', 'rb').read()

参考文献:

https://segmentfault.com/q/1010000004268196