加密base

㈠ 01加密方式-Base64編碼

說明
HTTP將Base64編碼用於基本的認證和摘要認證。
其可以方便的將用戶的任何輸入轉換成只包含特定字元的安全格式，服務於網路通信過程。
特點
1）可以將任意的二進制數據進行Base64編碼。
2）所有的數據都能被編碼為並只用65個字元就能表示的文本文件。
3）編碼後的65個字元包括A _Z,a z,0~9,+,/,=
4）對文件或字元串進行Base64編碼後將比 原始大小增加33% 。
5)能夠逆運算
6）不夠安全，但卻被很多加密演算法作為編碼方式

1）將所有字元轉化為ASCII碼；
2）將ASCII碼轉化為8位二進制；
3）將二進制3個歸成一組(不足3個在後邊補0)共24位，再拆分成4組，每組6位；
4）統一在6位二進制前補兩個0湊足8位；
5）將補0後的二進制轉為十進制；
6）從Base64編碼表獲取十進制對應的Base64編碼；

a.轉換的時候，將三個byte的數據，先後放入一個24bit的緩沖區中，先來的byte占高位。
b.數據不足3byte的話，則剩下的bit用0補足。每次取出6個bit，按照其值選擇查表選擇對應的字元作為編碼後的輸出。
c.不斷進行，直到全部輸入數據轉換完成。
d.如果最後剩下兩個輸入數據，在編碼結果後加1個「=」；
e.如果最後剩下一個輸入數據，編碼結果後加2個「=」；
f.如果沒有剩下任何數據，就什麼都不要加，這樣才可以保證資料還原的正確性。

運行效果圖

㈡ iOS加密2——Base64（蘋果支持）

1、由於某些系統中只能使用ASCII字元。Base64就是用來將非ASCII字元的數據轉換成ASCII字元的一種方法。

Base64編碼使用和urlencode比較
base64:
1、包含A-Z a-z 0-9 和加號「+」，斜杠「/」 用來作為開始的64個數字. 等號「=」用來作為後綴用途。
2、2進制的.
3、要比源數據多33%。
4、常用於郵件。

urlencode：將除了 -_. 之外的所有非字母數字字元都將被替換成百分號（%）後跟兩位十六進制數，空格則編碼為加號（+）

請求參數傳輸使用base64，而不是使用urlencode，為什麼？
1、部分因為base64編碼後參數就不可讀，而url編碼英文部分是不變的
2、為了兼容網路上的一些很古老的設備, 這些古董設備只能識別 base64編碼的字元
3、因為 urlencode 對二進制數據的效率不高，base64 會有效降低 %xx 的出現次數。
注釋 ：
1、url請求中，只對參數進行base64編碼，不是對整個url進行base64編碼。
2、在url請求時，會對url整體進行urlencode編碼。

NSString *str = @"hello world"; NSData *data = [str dataUsingEncoding:NSUTF8StringEncoding]; NSData *base64Data = [data base64EncodedDataWithOptions:0];

NSString *path = @"/Users/apple/Desktop/1.png"; NSData *data = [NSData dataWithContentsOfFile:path]; NSData *base64Data = [data base64EncodedDataWithOptions:0]; [base64Data writeToFile:@"/Users/apple/Desktop/base64" atomically:YES];

NSString *base64Str = [data :0]; NSLog(@"base64Str: %@",base64Str); NSLog(@"%@ %ld base64Data: %@ %ld",data,data.length,base64Data,base64Data.length);

NSData *endata = [[NSData alloc] initWithBase64EncodedData:base64Data options:0]; [endata writeToFile:@"/Users/apple/Desktop/123.png2" atomically:YES]; UIImage *image = [UIImage imageWithData:endata]; NSLog(@"%@",image);

和MD5一樣我們採取封裝的辦法將base64封裝進了MySecurities這個類中
MySecurities.h 文件
#import <Foundation/Foundation.h> @interface MySecurities : NSObject +(NSString *)base64EncodingWithData:(NSData *)sourceData;//base64加密 +(id)base64EncodingWithString:(NSString *)sourceString;//base64解密 @end
base64加密
@implementation MySecurities +(NSString *)base64EncodingWithData:(NSData *)sourceData{ if (!sourceData) { //如果sourceData則返回nil，不進行加密。 return nil; } NSString *resultString = [sourceData : ]; return resultString; } ***base64解密*** +(id)base64EncodingWithString:(NSString *)sourceString{ if (!sourceString) { return nil;//如果sourceString則返回nil，不進行解密。 } NSData *resultData = [[NSData alloc]initWithBase64EncodedString:sourceString options:]; return resultData; } @end

㈢ 詳述圖片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

做過網路通信的iOSer對Base64都不會很陌生，涉及加密的數據通常會在傳輸之前做一次Base64轉換，一般形式如下 Base64(DES/AES(Data)) ，所以有些iOSer就把Base64當作加密演算法的一種，甚至一些在線工具也直接稱呼Base64為加密/解密，實際上這誤會可大了，本篇回答以下三個問題：

要回答第一個問題，首先來看看Base64的編碼過程，這里以字元串 「1234」 為例，經過Base64編碼後，結果為 "MTIzNA==" ，也是一個字元串，過程如下：

看到這里，你會疑問，這樣的編碼有什麼用？
Base64真正的作用不是將字元串轉換為另一個字元串，而是將任意二進制轉換為字元串，這個字元串的范圍還很小，只有64個，這就為那些只能傳輸字元串的協議傳輸數據帶來方便，比如http，通過一些字元的替換，還可以避免特殊字元的沖突。

蘋果已經提供了原生的API，用Swift做Base64編碼：

NSData.Base64EncodingOptions 有四個可選值：

可以組合使用：

編碼結果按76個字元換行，換行符為\r。

解碼方法如下：

思考題：
編碼過程中，6位補8位的規則是什麼，是高位補0還是低位，為什麼？經過深入思考的結果才是自己的哦，歡迎你的留言👏

㈤ base64是一種高強度的加密演算法是不可破解的對嗎

Base64不是加密演算法，它僅僅是一種編碼方式，演算法也是公開的，所以不能依賴兄桐它進行加密。Base64是一種編悄賀碼羨運坦方式，不是加密演算法，它是沒有可讀性的，但不代表這個編碼就是加密的。加密需要保證沒有秘鑰的人無法解密信息，更無法從密文中破解任務明文信息，但Base64可以很輕松的反編碼。另外它沒有用到秘鑰 不具有加密演算法的安全性。

㈥ BASE64加密原理

1. Base64使用A--Z,a--z,0--9,+,/ 這64個字元.
2. 編碼原理:將3個位元組轉換成4個位元組( (3 X 8) = 24 = (4 X 6) )先讀入3個位元組,每讀一個位元組,左移8位,再右移四次,每次6位,這樣就有4個位元組了.
3. 解碼原理:將4個位元組轉換成3個位元組.先讀入4個6位(用或運算),每次左移6位,再右移3次,每次8位.這樣就還原了.

㈦ windows操作系統在dos下操作base64加密文件

總的來說是使用certutil

打開dos窗口，輸入dir查看當前目錄下的所有文件，如果目標文件在瞎消桌面直接輸入cd Desktop，這樣就進入了桌面。

然後再輸入dir查看當前目錄下的是否有這個目標文件（要操作文件的名字）在有目標文件的目錄下進行如下操作。

加密文件：certutil -encode 文件名  加密後的名

例如：certutil -encode pack.txt 1.py

就會在當前目錄下生成加密之後的文件

解密文件：certutil -decode 加密文件名  文件名

！！！注意：此處文件名可以自己重新起，但是後面的後綴一定要明確加密前是什麼格式，否則會出現亂源察碼

例如：雹神茄certutil -decode 1.py demo.txt

㈧ base64編解碼與hash加密

利用base64可以將二進制數據編碼為64個字元組成的字元串，64個字元為a-z，A-Z，0-9，+，/。base64編碼是將三個位元組的二進制數據編碼為四個位元組的字元數據，如果位元組數不為3的倍數base64會將 \x00 補在末尾，所以會常在base64字元串的末尾見到一個或者兩個的 = 號。
base64編碼

base64解碼

小技巧：遇到base64編碼的二進制文件可以直接解碼用io位元組流接收再用其他模塊載入，無需在本地保存文件再使用其他模塊載入。

哈希加密是對字元串進行加密，其加密後的散列值不可逆，即hash加密是單向加密不可解。python內置的hashlib庫提供了md5， SHA1, SHA224, SHA256, SHA384, SHA512 加密演算法的支持

㈨ base32加密後有多長

Base32 是一種基於 32 個字元的字元集（A-Z 和 2-7）來表示二進制數據的編碼方案。Base32 編碼後的數據長度取決於原始數據的長度，和具體的實現方法有關。

一般來說，Base32 編碼後的數據長度比原始數據長度要長。具體的計算公式如下：

- 假設原始數據長度為 bytes，那麼 Base32 編碼的數據長度為衫慶御 ceil(bytes * 8 / 5)，其中 ceil 表示向上取整。

例如，如果要對長度為 10 位元組的數據進行 Base32 編碼，則編碼後的數據長度為 ceil(10 * 8 / 5) = ceil(16) = 16 個字元。

需要注意的是，不同實現方法的計算方式可能有所不同，差握具體的實現方案可以查看或岩相關的文檔或者源代碼如果您需要更加精確的計算Base32編碼後的數據長度，建議參考具體的實現方案並根據需要進行計算。

㈩ 2.哈希加密 & base64加密

一、哈希HASH

哈希(散列)函數  MD5 SHA1/256/512 HMAC

Hash的特點：

     1.演算法是公開的

     2.對相同數據運算，得到的結果是一樣的

     3.對不同數據運算，如MD5得到的結果是128位，32個字元的十六進製表示，沒法逆運算

1.MD5加密

MD5加密的特點：

    不可逆運算

    對不同的數據加密的結果是定長的32位字元（不管文件多大都一樣）

    對相同的數據加密，得到的結果是一樣的（也就是復制）。

    抗修改性 : 信息「指紋」，對原數據進行任何改動,哪怕只修改一個位元組,所得到的 MD5 值都有很大區別.

    弱抗碰撞 : 已知原數據和其 MD5 值,想找到一個具有相同 MD5 值的數據(即偽造數據)是非常困難的.

    強抗碰撞: 想找到兩個不同數據,使他們具有相同的 MD5 值,是非常困難的

MD5 應用:

一致性驗證：MD5將整個文件當做一個大文本信息，通過不可逆的字元串變換演算法，產生一個唯一的MD5信息摘要，就像每個人都有自己獨一無二的指紋,MD5對任何文件產生一個獨一無二的數字指紋。

那麼問題來了，你覺得這個MD5加密安全嗎？其實是不安全的，不信的話可以到這個網站試試：md5破解網站。可以說嗖地一下就破解了你的MD5加密！

2.SHA加密

    安全哈希演算法（Secure Hash Algorithm）主要適用於數字簽名標准（Digital Signature Standard DSS）裡面定義的數字簽名演算法（Digital Signature Algorithm DSA）。對於長度小於2^64位的消息，SHA1會產生一個160位的消息摘要。當接收到消息的時候，這個消息摘要可以用來驗證數據的完整性。在傳輸的過程中，數據很可能會發生變化，那麼這時候就會產生不同的消息摘要。當讓除了SHA1還有SHA256以及SHA512等。

二、base64加密

1.Base64說明

    描述：Base64可以成為密碼學的基石，非常重要。

    特點：可以將任意的二進制數據進行Base64編碼

    結果：所有的數據都能被編碼為並只用65個字元就能表示的文本文件。

    65字元：A~Z a~z 0~9 + / =

    對文件進行base64編碼後文件數據的變化：編碼後的數據~=編碼前數據的4/3，會大1/3左右。

2.命令行進行Base64編碼和解碼

    編碼：base64 123.png -o 123.txt

    解碼：base64 123.txt -o test.png -D

2.Base64編碼原理

    1)將所有字元轉化為ASCII碼；

    2)將ASCII碼轉化為8位二進制；

    3)將二進制3個歸成一組(不足3個在後邊補0)共24位，再拆分成4組，每組6位；

    4)統一在6位二進制前補兩個0湊足8位；

    5)將補0後的二進制轉為十進制；

    6)從Base64編碼表獲取十進制對應的Base64編碼；

處理過程說明：

    a.轉換的時候，將三個byte的數據，先後放入一個24bit的緩沖區中，先來的byte占高位。

    b.數據不足3byte的話，於緩沖區中剩下的bit用0補足。然後，每次取出6個bit，按照其值選擇查表選擇對應的字元作為編碼後的輸出。

    c.不斷進行，直到全部輸入數據轉換完成。