先吐槽一下！你妹java核心技术卷2第八版，说是在卷一12章有字符编码的教程，书没买，那就下呗，找了半天下了个卷一，一看，12章哪来的字符编码？？？网上找了下，也没有改良utf-8的信息！好吧，最后，抱着试一试的心态，下了个卷一第七版，果然啊，在这里头，不带这样的吧。。。没事搞什么穿越啊。。。以上各位亲如果有兴趣，可以了解一下，各种坑啊，别和我一样悲剧找半天。
好！今天呢，就给大家科普一下！讲得好，有钱的捧个钱场!没钱的转发一下！- -
在很早以前，大家知道有一个叫ASCII码的东西，他使用7位表达128种字符，英语，当然没有问题，但是，不支持我们的汉字肿么可以，于是，我们的领导表示了强烈的不满并深感遗憾。又于是，科学家们就开发出了unicode，没错，多一字节嘛，就能很轻松的兼容问题了啊。但是，科学家们表示，那我如果经常使用英语，高字节的经常性全0会白白浪费了一倍的资源，这样是不可取的，领导于是说，你要再这样说，我就，深感遗憾。
科学家嘛，并不是都是木讷的，怎么能让领导遗憾呢？万一哪天突然走丢了呢，是吧。于是，他呕心沥血，开发出了UTF-8编码。
UTF-8的设计有以下的多字符组序列的特质：
*单字节字符的最高有效位元永远为0。
*多字节序列中的首个字符组的几个最高有效位元决定了序列的长度。最高有效位为110的是2字节序列，而1110的是三字节序列，如此类推。
*多字节序列中其余的字节中的首两个最高有效位元为10。
如：U+00000000 – U+0000007F： 0xxxxxxx
U+00000080 – U+000007FF： 110xxxxx 10xxxxxx
U+00000800 – U+0000FFFF： 1110xxxx 10xxxxxx 10xxxxxx
可变长了，有木有？领导高兴了，有木有？想感谢郭嘉了，有木有？
其实呢，在java内部，是使用utf-8的形式存储字符的，这样是很简单的。
但是呢，根据上节所说，在jni下面，有两种编码：“改良的UTF-8”和UTF16。UTF16就是双字节的unicode很好懂了，不需要解释。
那改良的UTF-8呢？根据该死的第七版的卷一12章所说，我们在需要向文件写数据时，会使用DataOutput的方法，如writeInt，会写入一个4字节的二进制数。不过，其中有一个方法writeUTF，比较特殊，此方法使用“改良的UTF-8”来写入字符串数据，与标准的UTF-8不同，字符组成的字符串先用utf-8表示，随后的结果采用UTF-8规则编码。对于高于0xffff的字符来说，改进的编码是不同的。这是为了能够同Unicode代码还没有增长到16位时的虚拟机向后兼容。
由于没有人使用改进的UTF-8代码，所以只能使用writeUTF方法来写字符串以供给java虚拟机使用，例如，要写一个产生字节码的程序。使用writeChars方法用于其他目的。
ok，插曲完毕，后面的文章，会继续jni的内容。
转自：http://longtimenoc.com/archives/objective-c-delegate的那点事儿
事情源于，网络请求中（未返回数据）退回到上一级，网络请求结束后，程序crash掉了，
if (delegate && [delegate respondsToSelector:didFailSelector]) {
EXC_BAD_ACCESS
----------------------------------------
Delegate算是Objective-C的一大特性, 关于Delegate的基础就不多介绍了, 有兴趣的请参看文档.
这里仅对Delegate使用中的一些问题做点讨论
我们用Delegate很多情况下是基于多线程的,比如我们有一个ViewController在这个Controller里面进行了一个下载图片的操作,下载成功后需要通过protocol来现实下载成功, 但是当ViewController已经被release,而下载工作才结束, 那么下载工作的[delegate didFinishDownload] (暂且就这么命名吧) 就会产生一个异常,因为你给一个deallocated的对象发送了一个消息.
那么,如何解决这个问题呢,首先我们可能想到用if (delegate == nil) 来判断delegate是否存在,但其实这是不行的,因为已经dealloc的对象并不是nil.要知道Objective-C中给nil发送消息是可以的,所以如果这种方法可行,其实我们就根本不需要if这句,[delegate didFinishDownload] 给nil发送了一个消息也不会出现异常,因此这种方法只是重复了上面的错误.
还有一个叫[delegate respondsToSelector:SEL]来判断delegate是否响应一个Selector, 根据上一段的描述,我们也可以判断出这个也是不行的.这里额外提一点关于respondsToSelector的东西,要使用这个方法,必须有@protocol MyProtocol <NSObject>,因为respondsToSelector是NSObject的一个protocol方法.
既然要防止delegate被release,那么retain这个delegate是否可行呢?这么做虽然避免错误的发生,但是也产生了另一个问题,这就关系到Objective-C内存管理中的Retain Circle, 即:有A,B两个Object, A中有一个B的实例变量,B中又有一个A的实例变量,要release A就必须releaseA中的B,而要release B有必须release B中的A,这样就产生了一个Retain Circle,A B都不能被dealloc.解决Retain Circle的方法就是使用弱引用(weak reference),弱引用没有被引用的那个Object的所有权,也就不需要release它,从而解决了Retain Circle问题.为了防止Retain Circle的发生, delegate通常都是弱引用的, 因此我们一般不应该retain一个delegate.但是似乎有一个例外:NSURLConnection, 网上对其的讨论结果是:NSURLConnection会retain它的delegate,详细可以参考StackOverflow上的这个问题
似乎没有简单可行的方法来解决这个问题(至少在本文发表时我还没有找到),那么我们只能在通过程序结构的设计来解决这一问题了,对应不同的程序自然也就有不同的解决方法,我想到的一种就是在这个ViewConrtoller被release的时候,把下载方法中的delegate设置成nil即可(目前测试可行, 如有错误还请指正).
/**
* 创建.nomedia目录,避免被图库扫描
*
* @param path
* 文件夹父目录
*/
public static void makeNomedia(File path) {
File dir = new File(path, ".nomedia");
if (!dir.exists())
dir.mkdir();
}