說實話，第一眼看到這個問題，我被震住了，心想到底是什么樣的勇氣能讓題主竟然用base64編碼來處理大文件，這豈不自尋煩惱，所以對于這個問題，我的建議不是該如何解決base64編碼的大小問題，而是要換一種方式來存儲文件，比如用文件系統。

問題剖析

先來分析下這個問題的原因，一般搞開發的都知道base64編碼很大程度上是簡化了我們傳輸文件的方式，特別是對于沒有文件系統的團隊來說，更是難得，但是這里的文件僅僅指的是小文件、小圖片（如：頭像、二維碼等）之類的，因為大文件轉化出來的base64編碼真的很長很長，先說這不利于網絡傳輸，就算勉強傳輸過去了，數據庫也不見得能存儲下來，就算勉強存儲下來了，重新再獲取的時候也一定會影響速度和效率。

至于題主說的71M的問題，其實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編解碼的方式，但是對于大文件來說還是建議使用文件系統的方式，這樣不僅對文件的管理更得體，也可以減少開發中遇到的不少問題。

base64只是一種二進制轉換字符的編碼方式而已，并不存在什么位數限制。這多大的數據都能編碼，這是毫無疑問的。

所以你編碼71M文件時出錯，很明顯是你使用的轉換庫有問題。

這個報錯很明顯是這個庫編碼base64時，直接把輸出的base64編碼存到了一個字符串變量里去，導致字符串變量數據過大，從而益出報錯。

所以解決方案很簡單，不要直接去對71M的數據進行轉換。

一 你可以在讀取圖片的時候，不要一次性把圖片全部加載到內存里，而是寫一個循環，按照固定的位數去讀區。絕大多數語言的read()方法都支持位讀取。

這樣一塊一塊的編碼就不會溢出了。

二 你也可以使用緩沖區而不是變量，先把圖片讀到緩沖區中，然后同上，按照位數分片轉換。

最后要注意，輸出結果的時候，千萬不能把結果直接累加在一個變量中，這樣一樣會溢出。

你可以

一 分片轉換，然后分片直接打印

二 分片的把結果寫入一個文件中

三 直接分片進行網絡傳輸，客戶端在進行組合。

四 用數組，堆，字典等等復雜數據結構來儲存結果。

襪子不能當避孕套用。東西要用對場合。

Base64是網絡上最常見的用于傳輸8Bit字節代碼的編碼方式之一，Base64編碼可用于在HTTP環境下傳遞較長的標識信息。

采用Base64編碼具有不可讀性，即所編碼的數據不會被人用肉眼所直接看到。(經過編碼，人們肯定直接看不懂)

在MIME格式的電子郵件中，base64可以用來將binary的字節序列數據編碼成ASCII字符序列構成的文本。

使用時，在傳輸編碼方式中指定base64。使用的字符包括大小寫字母各26個，加上10個數字，和加號“+”，斜杠“/”，一共64個字符，等號“=”用來作為后綴用途。

Base64編碼要求把3個8位字節（38=24）轉化為4個6位的字節（46=24），之后在6位的前面補兩個0，形成8位一個字節的形式。

如果剩下的字符不足3個字節，則用0填充，輸出字符使用'='，因此編碼后輸出的文本末尾可能會出現1或2個'='。

為了保證所輸出的編碼位可讀字符，Base64制定了一個編碼表，以便進行統一轉換。編碼表的大小為2^6=64，這也是Base64名稱的由來。

不評價為何需要這么大的base64，第一，base64是編碼方式并不存在71兆的限制

第二，如果你遇到的庫有這個限制，可能是實現的方式，或者你調用了簡版的API，肯定是可以流式處理的。

明白了估計是想用base64過防火墻傳送文件，其實我建議還是切片方式最理想

比如按照1MB為一個緩沖區把byte[]讀取出來做base64編碼傳遞后再合并是最高效率的，另外可以查看一下網絡的mtu對數據包做調整，這樣可以提高文件切片的傳輸效率。

另外base64可以用opencl提高編碼和解碼速度

分段base64

剛才研究了一下，確實出現了內存溢出情況。

這里有個小想法，不知可行不可行。

首先先將文件進行分段，

之后將不同的段進行生成base64編碼，

等全部生成完畢之后，進行base64編碼合并。

base64只是一個常見的編碼手段，沒有容量的限制。我猜是你用的類庫有問題，或者自己的代碼有問題。以數據流的方式處理，是不存在任何限制的。

想起來以前計算md5，一開始不懂，就是把整個文件讀到內存里再計算，經常發生內存溢出。后來仔細看文檔，發現還有個方法，可以分段計算。

補充：剛注意到你用的是certutil ，這個本來是用來處理證書的，證書本身都很小，所以它沒提過流式處理也正常。

我們經常說“殺雞用宰牛刀”，你這算是“宰牛用殺雞刀”了。

程序打開文件時，用二進制模式再試試看。