說(shuō)實(shí)話，第一眼看到這個(gè)問(wèn)題，我被震住了，心想到底是什么樣的勇氣能讓題主竟然用base64編碼來(lái)處理大文件，這豈不自尋煩惱，所以對(duì)于這個(gè)問(wèn)題，我的建議不是該如何解決base64編碼的大小問(wèn)題，而是要換一種方式來(lái)存儲(chǔ)文件，比如用文件系統(tǒng)。

問(wèn)題剖析

先來(lái)分析下這個(gè)問(wèn)題的原因，一般搞開(kāi)發(fā)的都知道base64編碼很大程度上是簡(jiǎn)化了我們傳輸文件的方式，特別是對(duì)于沒(méi)有文件系統(tǒng)的團(tuán)隊(duì)來(lái)說(shuō)，更是難得，但是這里的文件僅僅指的是小文件、小圖片（如：頭像、二維碼等）之類的，因?yàn)榇笪募D(zhuǎn)化出來(lái)的base64編碼真的很長(zhǎng)很長(zhǎng)，先說(shuō)這不利于網(wǎng)絡(luò)傳輸，就算勉強(qiáng)傳輸過(guò)去了，數(shù)據(jù)庫(kù)也不見(jiàn)得能存儲(chǔ)下來(lái)，就算勉強(qiáng)存儲(chǔ)下來(lái)了，重新再獲取的時(shí)候也一定會(huì)影響速度和效率。

至于題主說(shuō)的71M的問(wèn)題，其實(shí)base64編碼出來(lái)的長(zhǎng)度可能就不止71M了，因?yàn)閎ase64要求把每三個(gè)8Bit的字節(jié)轉(zhuǎn)換為四個(gè)6Bit的字節(jié)（3*8 = 4*6 = 24），然后把6Bit再添兩位高位0，組成四個(gè)8Bit的字節(jié)，也就是說(shuō)，轉(zhuǎn)換后的字符串理論上將要比原來(lái)的長(zhǎng)1/3，對(duì)此，我特意在線編碼了一個(gè)大于71M的文件，感覺(jué)還是可以編碼的，只是速度是真的很慢，網(wǎng)頁(yè)都卡死了好幾回，不知道題主用的是哪門(mén)語(yǔ)言，可能不同語(yǔ)言間也會(huì)有差距。

解決方法

1、采用文件系統(tǒng)

• 對(duì)于大文件的存儲(chǔ)我還是提倡用文件系統(tǒng)來(lái)進(jìn)行存儲(chǔ)，這樣的話就只要存儲(chǔ)文件路徑就好了，這樣不僅傳輸快，數(shù)據(jù)庫(kù)各方面也沒(méi)啥壓力，讀寫(xiě)文件也很方便。

• 可能有的團(tuán)隊(duì)覺(jué)得搭建文件系統(tǒng)很麻煩，并且也沒(méi)有多余的服務(wù)器來(lái)管理文件，如果是這樣的話，其實(shí)還可以考慮用云端的文件系統(tǒng)（如：阿里云OSS），這樣的話，我們存儲(chǔ)文件的時(shí)候就只要用它們接口將文件傳給云端，獲取文件的時(shí)候就只要調(diào)特定的接口獲取文件url即可。

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

如果仍然是不想用文件系統(tǒng)的話，那就只好從源頭出發(fā)，把大文件切割成小文件，然后依次用base64編碼，還原的時(shí)候就先將base64編碼轉(zhuǎn)成對(duì)應(yīng)的小文件， 然后不同的小文件再合成大文件。

• 切割的方式可以通過(guò)壓縮文件的方式，比如對(duì)一個(gè)31M的文件右擊 -> 添加到壓縮文件，下面會(huì)有一個(gè)分卷的地方，大小可以填小一點(diǎn)，如下圖所示：

然后點(diǎn)“確定”后就會(huì)生成3個(gè)小文件，如下圖所示：

• 合成文件就更簡(jiǎn)單了，將這三個(gè)小文件右擊 -> 解壓到當(dāng)前目錄或某一個(gè)目錄下就好了。

這種方法雖然也能達(dá)到目的，但是也看到了，這樣處理文件的代價(jià)是非常大的。

結(jié)束語(yǔ)

base64編碼雖然是個(gè)好東西，從一定程度上簡(jiǎn)化了開(kāi)發(fā)人員處理小文件的方式，但是卻不是通用的，所以我們?cè)谔幚硇∥募峡梢圆捎胋ase64編解碼的方式，但是對(duì)于大文件來(lái)說(shuō)還是建議使用文件系統(tǒng)的方式，這樣不僅對(duì)文件的管理更得體，也可以減少開(kāi)發(fā)中遇到的不少問(wèn)題。

base64只是一種二進(jìn)制轉(zhuǎn)換字符的編碼方式而已，并不存在什么位數(shù)限制。這多大的數(shù)據(jù)都能編碼，這是毫無(wú)疑問(wèn)的。

所以你編碼71M文件時(shí)出錯(cuò)，很明顯是你使用的轉(zhuǎn)換庫(kù)有問(wèn)題。

這個(gè)報(bào)錯(cuò)很明顯是這個(gè)庫(kù)編碼base64時(shí)，直接把輸出的base64編碼存到了一個(gè)字符串變量里去，導(dǎo)致字符串變量數(shù)據(jù)過(guò)大，從而益出報(bào)錯(cuò)。

所以解決方案很簡(jiǎn)單，不要直接去對(duì)71M的數(shù)據(jù)進(jìn)行轉(zhuǎn)換。

一 你可以在讀取圖片的時(shí)候，不要一次性把圖片全部加載到內(nèi)存里，而是寫(xiě)一個(gè)循環(huán)，按照固定的位數(shù)去讀區(qū)。絕大多數(shù)語(yǔ)言的read()方法都支持位讀取。

這樣一塊一塊的編碼就不會(huì)溢出了。

二 你也可以使用緩沖區(qū)而不是變量，先把圖片讀到緩沖區(qū)中，然后同上，按照位數(shù)分片轉(zhuǎn)換。

最后要注意，輸出結(jié)果的時(shí)候，千萬(wàn)不能把結(jié)果直接累加在一個(gè)變量中，這樣一樣會(huì)溢出。

你可以

一 分片轉(zhuǎn)換，然后分片直接打印

二 分片的把結(jié)果寫(xiě)入一個(gè)文件中

三 直接分片進(jìn)行網(wǎng)絡(luò)傳輸，客戶端在進(jìn)行組合。

四 用數(shù)組，堆，字典等等復(fù)雜數(shù)據(jù)結(jié)構(gòu)來(lái)儲(chǔ)存結(jié)果。

襪子不能當(dāng)避孕套用。東西要用對(duì)場(chǎng)合。

Base64是網(wǎng)絡(luò)上最常見(jiàn)的用于傳輸8Bit字節(jié)代碼的編碼方式之一，Base64編碼可用于在HTTP環(huán)境下傳遞較長(zhǎng)的標(biāo)識(shí)信息。

采用Base64編碼具有不可讀性，即所編碼的數(shù)據(jù)不會(huì)被人用肉眼所直接看到。(經(jīng)過(guò)編碼，人們肯定直接看不懂)

在MIME格式的電子郵件中，base64可以用來(lái)將binary的字節(jié)序列數(shù)據(jù)編碼成ASCII字符序列構(gòu)成的文本。

使用時(shí)，在傳輸編碼方式中指定base64。使用的字符包括大小寫(xiě)字母各26個(gè)，加上10個(gè)數(shù)字，和加號(hào)“+”，斜杠“/”，一共64個(gè)字符，等號(hào)“=”用來(lái)作為后綴用途。

Base64編碼要求把3個(gè)8位字節(jié)（38=24）轉(zhuǎn)化為4個(gè)6位的字節(jié)（46=24），之后在6位的前面補(bǔ)兩個(gè)0，形成8位一個(gè)字節(jié)的形式。

如果剩下的字符不足3個(gè)字節(jié)，則用0填充，輸出字符使用'='，因此編碼后輸出的文本末尾可能會(huì)出現(xiàn)1或2個(gè)'='。

為了保證所輸出的編碼位可讀字符，Base64制定了一個(gè)編碼表，以便進(jìn)行統(tǒng)一轉(zhuǎn)換。編碼表的大小為2^6=64，這也是Base64名稱的由來(lái)。

不評(píng)價(jià)為何需要這么大的base64，第一，base64是編碼方式并不存在71兆的限制

第二，如果你遇到的庫(kù)有這個(gè)限制，可能是實(shí)現(xiàn)的方式，或者你調(diào)用了簡(jiǎn)版的API，肯定是可以流式處理的。

明白了估計(jì)是想用base64過(guò)防火墻傳送文件，其實(shí)我建議還是切片方式最理想

比如按照1MB為一個(gè)緩沖區(qū)把byte[]讀取出來(lái)做base64編碼傳遞后再合并是最高效率的，另外可以查看一下網(wǎng)絡(luò)的mtu對(duì)數(shù)據(jù)包做調(diào)整，這樣可以提高文件切片的傳輸效率。

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

分段base64

剛才研究了一下，確實(shí)出現(xiàn)了內(nèi)存溢出情況。

這里有個(gè)小想法，不知可行不可行。

首先先將文件進(jìn)行分段，

之后將不同的段進(jìn)行生成base64編碼，

等全部生成完畢之后，進(jìn)行base64編碼合并。

base64只是一個(gè)常見(jiàn)的編碼手段，沒(méi)有容量的限制。我猜是你用的類庫(kù)有問(wèn)題，或者自己的代碼有問(wèn)題。以數(shù)據(jù)流的方式處理，是不存在任何限制的。

想起來(lái)以前計(jì)算md5，一開(kāi)始不懂，就是把整個(gè)文件讀到內(nèi)存里再計(jì)算，經(jīng)常發(fā)生內(nèi)存溢出。后來(lái)仔細(xì)看文檔，發(fā)現(xiàn)還有個(gè)方法，可以分段計(jì)算。

補(bǔ)充：剛注意到你用的是certutil ，這個(gè)本來(lái)是用來(lái)處理證書(shū)的，證書(shū)本身都很小，所以它沒(méi)提過(guò)流式處理也正常。

我們經(jīng)常說(shuō)“殺雞用宰牛刀”，你這算是“宰牛用殺雞刀”了。

程序打開(kāi)文件時(shí)，用二進(jìn)制模式再試試看。