事情的起因是這樣的，這兩天正在做一個功能，考慮到數(shù)據(jù)的保密性和服務(wù)端商量后決定用DES加密數(shù)據(jù)。我手里目前有兩個3DES加密的源碼，一個是使用過且沒有問題，另一個是別處得來的，我打算修改為DES的版本來使用，抉擇后選擇了第二個，因?yàn)榈诙€代碼的看著整潔、干凈，功能實(shí)現(xiàn)的好像還不錯，然后就開始有問題了。
測試了一下，對同一字符串使用相同的key每次加密得到的結(jié)果不一樣，這肯定是錯誤的，直接就否定了第二段代碼，任務(wù)要緊，先用第一個吧。等把功能寫好之后，想探究一下第二段代碼的問題，當(dāng)然，第二段中有很多問題，就不一一說了。
在修改第二段代碼的過程中，發(fā)現(xiàn)在將一個NSString對象轉(zhuǎn)換為C字符串的過程中，兩段代碼使用了不同的方法。
NSString *key = @"1234abcd";
NSData *data =[key dataUsingEncoding:NSUTF8StringEncoding];
NSLog(@"%s %s", [key UTF8String], data.bytes);
我嘗試打印了一下兩者的值，竟然不是一樣的。。。
Paste_Image.png
而且使用
data.bytes得到的值每次都是不一樣的，有時正確，有時在尾部會多出來一些數(shù)據(jù)，就像上圖一樣。但不管怎么樣都是以key的值為開頭，這就解釋了為什么第二段代碼每次的值都會不一樣了，因?yàn)槊看蔚膋ey都是不相同的。為什么
data.bytes每次的值不一樣呢？點(diǎn)開bytes可以看到這么一句話。
The -bytes method returns a pointer to a contiguous region of memory managed by the receiver .
大意為：bytes方法指向接收者管理的一段連續(xù)的內(nèi)存。既然為連續(xù)的內(nèi)存，可能就會包含NSData的其他字段所占用的內(nèi)存，這樣后邊的總是有追加的莫名字符就可以解釋的通了。如何證明呢？
Paste_Image.png
在
NSLog下一行添加一個斷點(diǎn)，讓程序跑起來。
Paste_Image.png
此時看到已經(jīng)打印出了值，第二個后面多出來一個大寫的A。
在控制面板右擊data出現(xiàn)下面這個面板，然后點(diǎn)擊View Memory of "data"
屏幕快照 2016-03-08 下午4.08.45.png
進(jìn)入下圖：
Paste_Image.png
這些是程序運(yùn)行的產(chǎn)生的數(shù)據(jù)，在畫紅線的地方將
_bytes的十六進(jìn)制地址輸入進(jìn)去會看到_bytes內(nèi)存段的數(shù)據(jù)。我這里是0x1002008e0。
Paste_Image.png
可以看到最上面一行就是
_bytes的值了，正是1234abcsA的值。前面對應(yīng)的是內(nèi)存中的ascii值，由于是十六進(jìn)制，需要轉(zhuǎn)為十進(jìn)制查看。1234abcsA后面是一段空的內(nèi)存，正驗(yàn)證了官方文檔上說的：bytes方法指向接收者管理的一段連續(xù)的內(nèi)存。
