解决python3 整数数组转bytes的效率问题
昨天在做一道CTF题的时候碰到了一个图片异或的问题，操作大概如下：
将一个图片读入，然后每字节进行异或操作，核心代码可简化为以下：
#coding:utf-8
'''
@DateTime:2017-11-2513:51:33
@Version:1.0
@Author:Unname_Bao
'''
importsix
key=b'\xdcd~\xb6^g\x11\xe1U7R\x18!+9d\xdcd~\xb6^g\x11\xe1U7R\x18!+9d'
withopen('flag.encrypted','rb')asf:
c=f.read()
flag=b''
foriinrange(32):
flag+=six.int2byte(key[i%32]^c[i])
withopen('flag.png','wb')asf:
f.write(flag)
然后就碰到了一个效率问题，跑了十几分钟都没有跑出结果，起初以为是类型转换的问题，因为比较急，于是换了成了C++的代码去解决，后来一直没多想。
今天闲下来的时候才发现代码之前的代码中存在一个非常大的问题：
内存申请问题
由于flag.encrypted文件大小为6.47MB之大，由于我的脚本思路是不断在byte数组后添加，但忽略了其本质。
就是在内存申请过程中，由于数组长度最终为600+W大小，期间存在多次数组内存不够，需要重新申请内存的问题，而python中的内存申请显然没有C++的vector的push_back有效率。
而且python中，无论是list、string还是byte，也没有reserve这种函数，不能预留内存空间（这时候真的要吐槽一下python设计者对速度优化的考量了）。
于是只能用另一种方法进行优化，就是先用list申请一个需求大小的内存空间，然后再转为bytes使用，
代码如下：
#coding:utf-8
'''
@DateTime:2017-11-2614:09:29
@Version:2.0
@Author:Unname_Bao
'''
key=b'\xdcd~\xb6^g\x11\xe1U7R\x18!+9d\xdcd~\xb6^g\x11\xe1U7R\x18!+9d'
withopen('flag.encrypted','rb')asf:
c=f.read()
flag=list('1'*len(c))
foriinrange(len(c)):
flag[i]=key[i%32]^c[i]
flag=bytes(flag)
withopen('flag.png','wb')asf:
f.write(flag)
这样写的话几乎是瞬间完成任务了，但还是比C++慢很多，这是不可避免的。
补充：python2与python3的bytes问题
>>>s='编程' >>>prints 编程 >>>s '\xe7\xbc\x96\xe7\xa8\x8b' >>>
在python2中直接调用字符串的变量的话，会打印其bytes(可以理解成用16进制表示字符串的内存地址，本质还是二进制）。在python2中，bytes和str是一回事。
为什么要有个bytes呢？因为所有数据本质都是用二进制进行储存的，当传输数据的时候，要把这些数据先转换成二进制(bytes)在进行传输。除此之外，python2里还有个单独的数据类型，把字符串解码后，就会变成unicode。
>>>s
'\xe8\xb7\xaf\xe9\xa3\x9e'#utf-8
>>>s.decode('utf-8')
u'\u8def\u98de'#unicode在unicode编码表里对应的位置
>>>print(s.decode('utf-8'))
路飞#unicode格式的字符
原因是python2的默认编码是ASCII,后来为了支持多国语言，就想弄个unicode。但是直接把ASCII转成unicode是很费劲的，所以龟叔直接搞了一个新的字符类型，就叫unicode,说白了就是你得在内存里先把字符串存成unicode类型
2008年python3出世，来了个大变革：
1、把字符串的编码变成了unicode,文件默认编码变成了utf-8。
2、把str和bytes做了明确区分，str就是unicode格式的字符，bytes就是单纯二进制还有一个很重要的是，在python3中，只有unicode给你展示字形，其他的编码一律用bytes展示，也就是说要你强制使用unicode。
最后再提示一下，Python只要出现各种编码问题，无非是哪里的编码设置出错了
常见编码错误的原因有：
Python解释器的默认编码
Python源文件文件编码
Terminal使用的编码
操作系统的语言设置
以上为个人经验，希望能给大家一个参考，也希望大家多多支持毛票票。如有错误或未考虑完全的地方，望不吝赐教。
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。