说实话base64解码，第一眼看到这个问题，我被震住了，心想到底是什么样的勇气能让题主竟然用base64编码来处理大文件，这岂不自寻烦恼，所以对于这个问题，我的建议不是该如何解决base64编码的大小问题，而是要换一种方式来存储文件，比如用文件系统。

问题剖析先来分析下这个问题的原因，一般搞开发的都知道base64编码很大程度上是简化了我们传输文件的方式，特别是对于没有文件系统的团队来说，更是难得，但是这里的文件仅仅指的是小文件base64解码、小图片（如：头像、二维码等）之类的，因为大文件转化出来的base64编码真的很长很长，先说这不利于网络传输，就算勉强传输过去了，数据库也不见得能存储下来，就算勉强存储下来了，重新再获取的时候也一定会影响速度和效率。

至于题主说的71M的问题base64解码，其实base64编码出来的长度可能就不止71M了，因为base64要求把每三个8Bit的字节转换为四个6Bit的字节（3*8 = 4*6 = 24），然后把6Bit再添两位高位0，组成四个8Bit的字节，也就是说，转换后的字符串理论上将要比原来的长1/3，对此，我特意在线编码了一个大于71M的文件，感觉还是可以编码的，只是速度是真的很慢，网页都卡死了好几回，不知道题主用的是哪门语言，可能不同语言间也会有差距。

解决方法1、采用文件系统

对于大文件的存储我还是提倡用文件系统来进行存储，这样的话就只要存储文件路径就好了，这样不仅传输快，数据库各方面也没啥压力，读写文件也很方便。

可能有的团队觉得搭建文件系统很麻烦，并且也没有多余的服务器来管理文件，如果是这样的话，其实还可以考虑用云端的文件系统（如：阿里云OSS），这样的话，我们存储文件的时候就只要用它们接口将文件传给云端，获取文件的时候就只要调特定的接口获取文件url即可。

2、将大文件切割成小文件

如果仍然是不想用文件系统的话，那就只好从源头出发，把大文件切割成小文件，然后依次用base64编码，还原的时候就先将base64编码转成对应的小文件， 然后不同的小文件再合成大文件。

切割的方式可以通过压缩文件的方式，比如对一个31M的文件右击 -> 添加到压缩文件，下面会有一个分卷的地方，大小可以填小一点，如下图所示：

然后点“确定”后就会生成3个小文件，如下图所示：

合成文件就更简单了，将这三个小文件右击 -> 解压到当前目录或某一个目录下就好了。

这种方法虽然也能达到目的，但是也看到了，这样处理文件的代价是非常大的。

结束语base64编码虽然是个好东西，从一定程度上简化了开发人员处理小文件的方式，但是却不是通用的，所以我们在处理小文件上可以采用base64编解码的方式，但是对于大文件来说还是建议使用文件系统的方式，这样不仅对文件的管理更得体，也可以减少开发中遇到的不少问题。