前几天群里说到百度云莫名的关键词屏蔽有何解，试着摸了一个脚本。
显然打包加密再上传是可解的，但这样代价有点大……，如果真的仅仅是文件名的屏蔽，那么把文件名改掉不就行了么？
那么现在有两个选项，一个是让文件名在修改后依然保持其原来文件名的信息，以某种编码将之混淆。另一个是直接按序编号，再生成一张表以供恢复。
我想着着再生成一张表有点慌，丢了咋办，生成失败了咋办……，于是选择了对文件名进行编码的方案。
用什么编码方案呢？很容易联想到常见的base64，但并不可以，编码表里存在着不能作为文件名的符号，虽然改表也行，但好没新意啊，然后突然回想到之前star了一个用千字文作为编码表的repo。那么来看看吧。
def convert(i):
li = []
while i > 0:
li.append(chars[i & 0x1F])
i >>= 5
return ''.join(reversed(li))
很糟，这个实现似乎……有点问题，i & 0x1F这个值，永远小于32好吧，真的有用到后面的字么？还要1024个字干嘛，叫base32得了。
没有现成的轮子，那么，来自己造吧。
base64说到底就是一个将一长串二进制重新分割的操作，以utf-8为例，原来的最小单位均为8bit，而base64只要6bit，于是就按6bit一组重新划分即可，但是这样一定要是前后两种位长都能除得尽的数据长度才能处理，怎么办呢？不够的话，就当后面都是0，并在编码结果后添加相应个数的等号，这也就是为什么base64编码后，最短也有4个字符的原因。
知道了原理（喂，你不早就写过base64了么，怕不是忘了吧），就能开始写base1024了。但是这个加等号的过程并不能很好的融合到转换里面，不怎么好看，于是决定将加到后面的0也当作数据存储，反正字符串不能以0结尾，转换回来的时候再抹掉就好了（bug）。
经过一波位运算，编码和解码函数就都写好了，效果喜人，再一波疯狂的搜索，命令行的参数也写好了。可是问题也浮现出来了，这个base1024，也是越编码越长的玩意，到时候分分钟戳爆Windows的最长路径限制。
次日，我突然灵机一动，我能先把字符串压缩一下啊，再喂给base1024岂不美哉。稍作测试，选择了zlib来进行压缩，效果看着似乎挺好的，导致短字符串变长的副作用也不是不能接受。
本以为这样就可以完全收工了，但是上面插的旗子不还没折么。很遗憾的是，zlib输出的结果，比如remotes压缩之后是存在以0作为结尾的数据的，然后在解码的时候被我当作自己加的填充位给删掉，于是就解码失败了……，果然有些东西还是不能偷懒的。但是但是，这里还是能够偷懒解决的，现在通过不断往后加空格直到压缩出的结果尾部不含0。等到什么时候变得完全不可调和了再重新写吧。
