事情的起因是这样的，这两天正在做一个功能，考虑到数据的保密性和服务端商量后决定用DES加密数据。我手里目前有两个3DES加密的源码，一个是使用过且没有问题，另一个是别处得来的，我打算修改为DES的版本来使用，抉择后选择了第二个，因为第二个代码的看着整洁、干净，功能实现的好像还不错，然后就开始有问题了。
测试了一下，对同一字符串使用相同的key每次加密得到的结果不一样，这肯定是错误的，直接就否定了第二段代码，任务要紧，先用第一个吧。等把功能写好之后，想探究一下第二段代码的问题，当然，第二段中有很多问题，就不一一说了。
在修改第二段代码的过程中，发现在将一个NSString对象转换为C字符串的过程中，两段代码使用了不同的方法。
NSString *key = @"1234abcd";
NSData *data =[key dataUsingEncoding:NSUTF8StringEncoding];
NSLog(@"%s %s", [key UTF8String], data.bytes);
我尝试打印了一下两者的值，竟然不是一样的。。。
Paste_Image.png
而且使用
data.bytes得到的值每次都是不一样的，有时正确，有时在尾部会多出来一些数据，就像上图一样。但不管怎么样都是以key的值为开头，这就解释了为什么第二段代码每次的值都会不一样了，因为每次的key都是不相同的。为什么
data.bytes每次的值不一样呢？点开bytes可以看到这么一句话。
The -bytes method returns a pointer to a contiguous region of memory managed by the receiver .
大意为：bytes方法指向接收者管理的一段连续的内存。既然为连续的内存，可能就会包含NSData的其他字段所占用的内存，这样后边的总是有追加的莫名字符就可以解释的通了。如何证明呢？
Paste_Image.png
在
NSLog下一行添加一个断点，让程序跑起来。
Paste_Image.png
此时看到已经打印出了值，第二个后面多出来一个大写的A。
在控制面板右击data出现下面这个面板，然后点击View Memory of "data"
屏幕快照 2016-03-08 下午4.08.45.png
进入下图：
Paste_Image.png
这些是程序运行的产生的数据，在画红线的地方将
_bytes的十六进制地址输入进去会看到_bytes内存段的数据。我这里是0x1002008e0。
Paste_Image.png
可以看到最上面一行就是
_bytes的值了，正是1234abcsA的值。前面对应的是内存中的ascii值，由于是十六进制，需要转为十进制查看。1234abcsA后面是一段空的内存，正验证了官方文档上说的：bytes方法指向接收者管理的一段连续的内存。
