在用文件加密读写的时候遇到Base64的2个问题：
1.文件创建失败
文件名是按照日期进行加密的，日期格式是20190101，但是加密后有一些字符如"+"，"/"，这样创建文件会失败的，所以修改了Base的源码，把"+"，"/"替换成了"*"，"_"，这样就解决了文件创建失败的问题，除了这里，解析的地方也得改。
其中有一个波折，网上说可以替换成"-"和"_"，我测试发现"-"出现在中间是没问题的，出现在文件头是无法创建的，一开始我认为文件头部出现"-"的概率不大，后来把"-"替换成""后打印1月的所有日期发现字符出现的概率都一样，以""开头的还是会有的。
测试文件是否可以创建既用到了手机直接创建文件夹，也用到了在mac命令行上创建，使用
touch *ncP_8BdsFSr17dYAxHggw== 创建成功
touch -ncP_8BdsFSr17dYAxHggw== 创建失败
2.Base64和按行读取的冲突问题
加密后一般会用Base64做一次转换，去除特殊字符，正常我们对整个文件进行加解密是不会有问题的，但是我的使用场景有点特殊，文件插入内容时是加密写入，然后增加"\r"作为换行符，以便可以整行读取，解密时是一行一行读取，然后对单行进行解密。使用Base64之后解密总是失败，查看源码发现他固定长度限制，到了一定长度就自动增加换行符。而它的换行符把我的一条内容拆分成了多条，导致解密失败。
解决问题先是定位问题点，是写文件问题，加解密问题还是Base64问题，并用文本读取软件查看格式发现确实换行了，定位到Base64问题后查看源码，找到自动增加的地方注释掉即可。
当然我也用了另外一种方式去解决这个问题，那就是不用换行符，而是用一个特殊字符作为结尾标志，比如"䦳"，每次写完一条数据就添加这么一个字段，那么读取的时候就不能按行读取了，只能把整个文件读出来，然后用它做分割，再对每条内容进行解密。这种方式的问题在于效率比较低，如果文件比较小没问题，但是文件大了一次性读取就会很慢。
写文件不加换行符的话它是作为一行内容存在的，只有手动添加了"\r"才算是换行，所以这样写出来的就是一大行，而我们平时用的文本编辑器是它自动到了一定长度做了一个显示上的分割，其实程序上还是一行。
这2个问题都比较隐蔽，第1个问题是随机性的，失败的几率很小，如果不是偶然测出来真的是不会感知的，因为只有2%的概率复现。第2个问题如果加密字符足够短的话也无法复现，因为代码中是超过76个才换行，而我测试写了足够长的字符串测出了这个问题。因此测试还是要尽可能的全面，尽量做到覆盖广，各种能想到的异常情况都测一下。
