base64加密原理
public class Base64
{
/**//// <summary>
/// 將字元串使用base64演算法加密
/// </summary>
/// <param name="SourceString">待加密的字元串</param>
/// <param name="Ens">System.Text.Encoding 對象，如創建中文編碼集對象：
/// System.Text.Encoding.GetEncoding("gb2312")</param>
/// <returns>編碼後的文本字元串</returns>
public static string EncodingString(string SourceString,System.Text.Encoding Ens)
{
return Convert.ToBase64String(Ens.GetBytes(SourceString));
}
㈡ base64加密比原來的數據長度增加多少
首先Base64不是一種加密方式，只是一種編碼。。然後長度呢，就是原來長度 * (4 / 3)，不計最後一個或兩個等於號的話。
㈢ 漢字加密後的字元數會改變嗎
會的
漢字加密之後會有新的字元，字元數是會隨著改變的。
base64加密原理：
①將每三個位元組作為一組，一共是24個二進制位。
②將這24個二進制位分為四小組，每個小組有6個二進制位。
③在每小組前面加兩個00，擴展成32個二進制位，即四個位元組。
④根據base64基礎表，得到擴展後的每個位元組的對應的base64符號。
㈣ iOS Base64編碼
Base64編碼是一種數據編碼方式，目的是讓數據符合傳輸協議的要求。能夠將任何二進制數據，轉換成只有64 +1（「=」等號）個字元組成的文本文件。
提示：Base64不是加密演算法，只是一種編碼演算法，對數據內容進行編碼不以明文來傳輸。
標准Base64編碼使用的64個字元：
早期的傳輸協議，如郵件傳輸SMTP協議，只能傳輸ASCII編碼中 可列印字元 ，導致原本8bit位元組碼（0-255）超出了可用范圍。所以Base64將原本ASCII碼的控制字元甚至是ASCII編碼之外的字元都轉換成可列印的6bit字元。
提示：ASCII編碼的范圍是0-127，其中0-31和127位共33個字元屬於 控制字元 ，剩下的32-126屬於 可列印字元 。
編碼過程：
1、按字元串長度，以每3個8bit的字元為一組
2、對每組獲取每個字元的ASCII編碼（去ASCII編碼表找每個字元的碼位）
3、將ASCII編碼轉換成8bit的二進制，得到一組3*8=24bit的位元組
4、再將這24bit劃分為4個6bit的位元組，並在每個6bit的位元組前面都填兩個高位0，得到4個8bit的位元組
5、將這4個8bit的位元組轉換成10進制，對照Base64編碼表 （下表），得到對應編碼後的字元。
注意：
示例：對 Hello! 進行Base64編碼，按照ASCII表，其轉換過程如下圖所示：
Hello! 的Base64編碼結果為 SGVsbG8h 。
原始字元串長度為6個字元，編碼後長度為8個字元，每3個原始字元經Base64編碼成4個字元，編碼前後長度比4/3。
這個長度比很重要 。比原始字元串長度短，則需要使用更大的編碼字元集，長度比越大，則需要傳輸越多的字元，傳輸時間越長。
注意：Base64編碼是每3個原始字元編碼成4個字元，如果原始字元串長度不能被3整除，那怎麼辦？使用0值來補充原始字元串。
示例：對 Hello!! 進行Base64編碼：
註：圖中藍色背景的二進制0值是額外補充的。
Hello!! 的Base64編碼的結果為 SGVsbG8hIQAA 。
最後2個零值只是為了Base64編碼而補充的，在原始字元中並沒有對應的字元，那麼Base64編碼結果中的最後兩個字元 AA 實際不帶有效信息，所以需要特殊處理，以免解碼錯誤。
標准Base64編碼通常用 = 字元來替換最後的 A，即編碼結果為 SGVsbG8hIQ==。
因為 = 字元並不在Base64編碼索引表中，其意義在於結束符號，在Base64解碼時遇到 = 時即可知道一個Base64編碼字元串結束。
如果Base64編碼字元串不會相互拼接再傳輸，那麼最後的 = 可以省略，解碼時如果發現Base64編碼字元串長度不能被4整除，則先補充 = 字元，再解碼即可。
解碼是對編碼的逆向操作，但注意一點：對於最後的兩個 = 字元，轉換成兩個 A 字元，再轉成對應的兩個6比特二進制0值，接著轉成原始字元之前，需要將最後的兩個6比特二進制0值丟棄，因為它們實際上不攜帶有效信息。
UTF-8是Unicode字元集的編碼規則，用於網路傳輸。
Base64是用來支持某些只支持傳輸ASCII編碼可列印字元的協議，將ASCII編碼中的控制字元與ASCII之外的字元轉換為ASCII可列印字元來用於傳輸。
漫畫：什麼是 Base64 演算法？
iOS開發探索-Base64編碼
關於base64編碼的原理及實現
ASCII碼對照表
㈤ 何謂Base64 加密演算法及原理，如何使用 php 實現一個 Base64
就是可以解的加密方式
base64_encode(); base64_decode();
因為一些字元，如鏈接get方式， 瀏覽器不可以帶很多特殊字元，導致php獲取不到正確的信息，用加密一下就好多了， 不過注意大小寫。
㈥ base64的原理
轉碼過程例子：
3*8=4*6
內存1個字元佔8位
轉前： s 1 3
先轉成ascii：對應 115 49 51
2進制： 01110011 00110001 00110011
6個一組（4組） 011100110011000100110011
然後才有後面的 011100 110011 000100 110011
然後計算機是8位8位的存數 6不夠，自動就補兩個高位0了
所有有了 高位補0
科學計算器輸入 00011100 00110011 00000100 00110011
得到 28 51 4 51
查對下照表 c z E z
先以「迅雷下載」為例： 很多下載類網站都提供「迅雷下載」的鏈接，其地址通常是加密的迅雷專用下載地址。
其實迅雷的「專用地址」也是用Base64加密的，其過程如下：
一、在地址的前後分別添加AA和ZZ
二、對新的字元串進行Base64編碼
另：Flashget的與迅雷類似，只不過在第一步時加的「料」不同罷了，Flashget在地址前後加的「料」是[FLASHGET]
而QQ旋風的乾脆不加料，直接就對地址進行Base64編碼了
㈦ 詳述圖片base64加密的原理，告訴你什麼是"/9j/"
在日常的生活中，我們肯定都經歷過類似這樣的場景：報名考試上傳圖片，網站要求的是上傳的照片不能大於多少，而且要求是「.jpg」的格式。
於是你高高興興地把自己最漂亮的照片上傳上去了，但是網站卻提示你照片格式不正確，讓你重新上傳。這個時候內心不知道有多少疑惑湧上心頭（其實是奔騰）我的照片明明就是「.jpg」結尾的，而且大小也符合規范，為啥就不行呢？
我們通常的會認為（Windows電腦情況下，Mac不知道，畢竟我沒有圖片）「.jpg」圖片結尾的就一定是符合規范的「JPG」文件類型。其實一開始我也是這樣認為的，直到前幾天，我在對接項目的時候踩了一個大坑，很大的坑！
我對接的項目要求的是圖片是「JPG」類型的文件，並且經過base64進行編碼之後要以"/9j"開頭的文件。於是我就把我電腦上保存的看似符合規范的圖片上傳上去了，結果就是一堆報錯信息。於是我再次嘗試，換一些其他的圖片進行測試，發現有的就好使，有的就不好使。說實話，我的內心崩潰了！那種感覺你懂得圖片
回到家之後我思來想去就是不知道為什麼要求什麼"/9j"開頭的？我打開了網路，輸入了關鍵詞「/9j」之後，呵呵！我笑了，都是些什麼？完全跟我的問題不著邊！
什麼玩意？這到底是什麼玩意？竟然連強大的網路都沒有給出結果！就這樣，我搜索到了凌晨12點......
扛不住了，我就去睡覺了。但是躺在床上我輾轉難眠，打開手機繼續各種搜索著......突然！我看了一個關於電腦圖片文件頭信息解析的文章！一道靈光從我腦門上閃過。於是我起床，默默打開了電腦，打開了網路......
原來電腦在存儲的時候是存儲了圖片的基本信息的，比如圖片是什麼類型的，圖片的寬高等基本信息，這些個基本信息叫做圖片頭信息。好吧！原諒我的無知，曾經的我天真的以為是按照文件後綴名區分的呢。
我們應知道，圖片在計算機中存儲是一個一個的像素點，最底層也是二進制文件，所以需要文件頭來保存文件信息。經查找資料，我找到如下對圖片不同格式的文件頭標識信息（16進制標識）：
於是我在電腦上保存了一個為「.jpg」後綴結尾的圖片，然後使用UE這個強大的工具打開，果然不出我所料，看看這個文件的內容信息。
不出意外的話，你肯定看不懂這些東西，因為這些是16進制文件。但是重要的我已經給你標注出來了，那就是「FF D8」。
在這里我給大家稍微簡單科普下base64的編碼規則：假如我們有個「hello」這樣的關鍵字進行base64編碼，需要先把「hello」轉換成二進制，也就是"110100011001011101100110 11001101111"。我這里給了一個ASCII表，這里對應的是10進制的，需要把十進制轉化成2進制的。
關於base64 有個規定就是，一個字元轉換之後如果位數不為8位，需要在高位補0，然後再6位截取，最後不夠6位的，低位補0。然後把分割後的2進制轉換成10進制並對照base64編碼表進行解析。那麼上述的「hello」的解析過程就如下：
所以「hello」base64編碼之後的最終結果就是「aGVsbG8=」。也許你會疑惑，為什麼多了個「=」 這個其實是base64的規定，編碼完畢之後自動添加一個或兩個「=」。
那麼再回到「FF D8」，jpg文件的標識頭，他經過base64轉碼之後是什麼呢？
謝天謝地，可算搞明白為什麼是「/9j」開頭的了。其實還有另外一種方式快速查看是不是jpg格式文件。我們可以使用記事本的方式打開一個jpg文件。
打開之後，你肯定還是看不懂這些東西，但是重要的我已經給你標注出來了，那就是「JFIF」，這個是一個很重要的標識，所謂的「JFIF」就是"JPEG File Interchonge Format"即JPEG文件交換格式。
為了還原我之前明明是「.jpg」後綴的文件，但是識別失敗的問題。我們把一個格式為「.png」圖片，通過改後綴名的方式，改成「.jpg」。然後也用記事本打開查看文件的內容。
可以看到，並不是「JFIF」，因此這並不是一個jpg文件，所以上傳無法識別。
帶著問題去睡覺，果然是睡不著的！通過這次的經歷，我知道了base64的編碼原理，明白了文件在電腦中存儲並不是靠簡簡單單的後綴名來區分的，而是有文件頭信息的。文件到底是一個什麼文件，還是要靠文件頭信息來決定的。所以，你以後的程序判斷文件類型千萬不要僅僅判斷後綴名就完事了哦！
㈧ Base64編碼是加密演算法嗎
大家好，我是阿薩。昨天和開發同學一起開會的時候。開發同學說到了用Base64編碼，我立即說 不能使用Base64加密。然後開發來了一句Base64不是加密演算法。當時懵了。默默記下這個知識點，回來學習下。
先給大家講解下我為什麼會有不能使用Base64加密的意識。很多年前，我遇到的第一個安全問題，就是敏感數據用Base64加密了。 事情起因是，我們接到一個bug，說有個敏感欄位使用Base64在前端加密了，然後傳給後端了。
基於之前的小故事，對於使用了Base64編碼的地方就覺得不安全。這也是為什麼會對開發說不能用Base64加密了，
今天我們就來學習下Base64編碼。
一，Base64編碼的由來。
傳說，最開始互聯網電子郵件都是英文的，後來互聯網傳到中國後，互聯網電子郵件漢字就不認識了。所以就有了Base64編碼，把中文變成可識別的英文。然後Base64編碼被廣泛用到各行各業。
以上只是傳說。真實的由來，就不得而知了。
下面我們從計算機的底層傳輸過程中。它分為可見字元和不可見字元。可見字元比如我們熟知的ASCII碼。
還有一些不可見的控制字元（0~31以及127），比如回車，換行等以及一些二進制數據都是不可見字元。
這些不可見字元在一些硬體，比如交換機，路由器以及網關等識別或者解析錯誤，導致錯誤發生，所以就有了Base64編碼的市場。因此Base64產生了。
二，Base64 編碼的原理
Base64編碼就是要把不可見的字元轉換成常見的64個字元的過程。
這64個字元是哪些呢？
那麼它工作原理是啥呢？
1） 首先把整段傳輸內容全部劃分成三個位元組一組。這里就有了24bit了.
2） 然後把24bit 分成四組。每一組就有6bit
3）在6bit的最前面添加2個0，這樣就有了8bit
4）把這8bit 轉換成一個位元組。查找上表中對應字元。所有其他分組內容按照這樣的處理邏輯處理下。就得到了Base64的編碼後字元。
注意，如果不夠三位元組，用0填到三位元組，同時補充了多少個位元組的0，末尾就添加就幾個=。
分別圖示下以上過程：
三個A
2個A，補充一個0
1個A，補充2個0
三，總結
Base64編碼不是用來加密的，也不是加密演算法。它只是用來編碼的。切記不可用於加密。如果敏感信息用Base64編碼加密了，趕緊提bug。
經過今天的學習，希望大家有所收獲。
如果你喜歡今天的內容，歡迎點贊，關注。
㈨ 什麼是BASE64編碼
Base64是網路上最常見的用於傳輸8Bit位元組代碼的編碼方式之一，在發送電子郵件時，伺服器認證的用戶名和密碼需要用Base64編碼，附件也需要用Base64編碼。
下面簡單介紹Base64演算法的原理，由於代碼太長就不在此貼出
Base64要求把每三個8Bit的位元組轉換為四個6Bit的位元組（3*8 = 4*6 = 24），然後把6Bit再添兩位高位0，組成四個8Bit的位元組，也就是說，轉換後的字元串理論上將要比原來的長1/3。
轉換後，我們用一個碼表來得到我們想要的字元串（也就是最終的Base64編碼），這個表是這樣的：
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
原文的位元組最後不夠3個的地方用0來補足，轉換時Base64編碼用=號來代替。這就是為什麼有些Base64編碼會以一個或兩個等號結束的原因，但等號最多隻有兩個。
舉一個例子，abc經過Base64編碼以後的結果是YWJj.
發郵件的時候所寫的信息自動在後台轉換然後傳輸...
參考資料： http://www.luocong.com/articles/show_article.asp?Article_ID=17