問題場景：
在使用luacurl進行http post請求的時候，post的內容是一串json串。json傳裡面的某個字段帶上了base64加密的串。
如post的內容如下：
******
傳輸到對方後，對方接收到的報文裡面的post的內容變成了：
******
遠端和負責伺服器端的小夥伴調了大半天，發現+號變成了空格！這是什麼詭異情況？！
1. base64編碼裡面有乙個 「+」 號，在urlecode編碼中 「+」 會被解碼成空格，urlencode時，"+" 號肯定是由空格編碼出來的，但是base64編碼的結果中 "+" 不是空格編碼出來的，如果將base64編碼作為安全的url編碼使用，則 「+」 將被解碼成空格，這是我們不願看到的； 所以不要base64編碼作為url編碼來使用.
2. 我們知道http頭裡面可能會用base64編碼來傳輸一些資訊，因為這些資訊不會被web伺服器預設做url解碼的，我們可以得到原始的編碼資訊，所以http頭裡面使用base64編碼是可以接受的。
用base64編碼後再進行url編碼，再傳輸可能會避免此類問題。
base64編碼將二進位制資料按照每三個位元組轉換成四個位元組可讀字元，編碼後的字元長度大約為136.1%。字元範圍為 a-z
a-z
0-9
\ +。但編碼後的字串不太適合使用url傳輸，中文加密後的亂碼也多是因為這個原因引起：放在url中傳輸時+號會被替換成空格；並且每76個字元都會新增乙個換行"\n"，這個換行符合會丟失。
在實際的測試過程中，確實發現+號被替換成空格了，但是，\n換行符並未丟失!
解決方案如下：
接收方如果發現收到的json加密串中包含空格，將其替換為+號後，再進行base64的解密工作.
問題場景：
在使用luacurl進行http post請求的時候，post的內容是一串json串。json傳裡面的某個字段帶上了base64加密的串。
如post的內容如下：
******
傳輸到對方後，對方接收到的報文裡面的post的內容變成了：
******
遠端和負責伺服器端的小夥伴調了大半天，發現+號變成了空格！這是什麼詭異情況？！
1. base64編碼裡面有乙個 「+」 號，在urlecode編碼中 「+」 會被解碼成空格，urlencode時，"+" 號肯定是由空格編碼出來的，但是base64編碼的結果中 "+" 不是空格編碼出來的，如果將base64編碼作為安全的url編碼使用，則 「+」 將被解碼成空格，這是我們不願看到的； 所以不要base64編碼作為url編碼來使用.
2. 我們知道http頭裡面可能會用base64編碼來傳輸一些資訊，因為這些資訊不會被web伺服器預設做url解碼的，我們可以得到原始的編碼資訊，所以http頭裡面使用base64編碼是可以接受的。
用base64編碼後再進行url編碼，再傳輸可能會避免此類問題。
base64編碼將二進位制資料按照每三個位元組轉換成四個位元組可讀字元，編碼後的字元長度大約為136.1%。字元範圍為 a-z
a-z
0-9
\ +。但編碼後的字串不太適合使用url傳輸，中文加密後的亂碼也多是因為這個原因引起：放在url中傳輸時+號會被替換成空格；並且每76個字元都會新增乙個換行"\n"，這個換行符合會丟失。
在實際的測試過程中，確實發現+號被替換成空格了，但是，\n換行符並未丟失!
解決方案如下：
接收方如果發現收到的json加密串中包含空格，將其替換為+號後，再進行base64的解密工作.
關於base64編碼
今天和同事聊到在給前端傳輸 驗證碼的時候，涉及到了這個關於base64編碼的問題。可以通過編碼的格式來獲取 至於好處可以參考以下 string a 123412312sfwefwefwefw string b new string codecmanager.getcodecclient codecc...
javascript實現base64加解密
1.瀏覽器自帶方法 加密 124 mti0 btoa 124 解密 mti0 124 atob 124 瀏覽器自帶的方法只支援拉丁文 2.呼叫開源的base64.js 1.加密解密方法使用 1.加密 var str 124中文內容 var base new base64 var result bas...
關於Base64編碼 解碼
用數字證書簽名或者生成md5摘要結果都是byte陣列，為了方便對簽名結果放在xml中進行傳輸，一般先用base64進行編碼，生成一串可見的ascii字元。接收方收到後在用base64進行decoder生成byte陣列。可進行base64編碼 解碼處理的類有 org.apache.commons.co...