文本检测的bug原因是我把icu整个都端了，自然icu里检测编码的好用接口也废弃了。不过我扣了一部分出来，用于检测UTF8和GBK编码。剩下的编码，经海绵宝宝
的提醒，用了微软的
IMultiLanguage2::DetectInputCodepage
接口，发现还挺好用的，感谢海绵宝宝。接口用法：http://www.codeproject.com/KB/recipes/DetectEncoding.aspx?display=Print
需要注意的是，这个IMultiLanguage2::DetectInputCodepage接口返回S_FALSE的话，其实也是成功的，但msdn里显然写错了。害的我调试了一天，一直以为哪个地方没写对，汗···
内存泄漏的问题，花了比较久。这里需要隆重推荐下blink里的olipan项目，这货居然实现了C++的自动垃圾回收！而且是可以检测循环引用的。据说V8也把这货集成进去了。
有时间我要把这个组件从blink里扣出来，目前来看依赖不大，但是需要实现一些thread相关的接口。
看这段介绍：
在Oilpan项目之前，Blink和Chromium都采用引用计数技术（referencecounting）来管理内存，每个对象内部都一个引用计数，表明当前对象被引用了多少次，当引用技术归零时，对象就会被自动释放掉，这种方式一直以来都存在一个缺陷就是循环引用问题，就A引用了，B又引用了A，最后导致A和B都没有机会释放，此外，C++中启用引用计数还存在其他几个方面的问题：
- 引用计数器的增减开销问题；
- C++中可以通过Raw指针轻易地绕开RefPtr的管理，一旦使用不当，将导致use-after-free内存错误，存在安全问题；
尽管引用计数存在上述一些问题，但它很轻量级，仍然是C++程序中广泛使用的自动内存管理计数。Blink项目并不满足这种轻量级的内存管理方法，于是Oilpan项目提上日程，要实现对Blink对象的自动回收机制。比起引用计数技术，Oilpan垃圾回收器确实是个庞然大物，它实现了一个一般只有虚拟机才需要的高级特性，然而Blink项目力求精益求精，追求最好！
Oilpan实现了一种跟踪式的垃圾回收机制，具有如下特点：
- Blink中所有的对象都将分配在一个受托管的堆中，每个对象都提供了一个trace的方法，用来建立与堆中其他对象的可达关系，因此，从根节点（一般DOMWindow）出发，Blink的对象在托管堆中形成了一个对象图，那些由根节点不可达的对象将会被GC掉，这样就避免了循环引用问题。
- Oilpan的GC并不会随时都发生，它会被推迟到消息循环中执行，因为当消息循环执行完任务队列中最后一个任务时，此时Blink的栈为空，没有在栈中分配的对象了。
- 一旦需要执行GC时，Blink首先要确保所有运行的线程到达了一个“安全点”，不会再分配新的对象，然后从根节点出发，计算堆中所有对象的传递可达性，并标记(mark)所有可达的对象，最后每个线程开始清理（sweep）属于自己的那部分堆空间，回收所有未被标记的对象，将其插入到空间列表中。
- 与V8引擎的GC相比，Oilpan的GC会牵扯到Blink所有的线程，Database线程，File线程等等，所有的线程都共享一个Oilpan的堆空间。
- Oilpan提供了两个超类GarbageCollected和GarbageCollectedFinalized，来保证它们的子类都分配在由Oilpan管理的堆中。
截止到目前，Oilpan基础框架已经比较稳定，modules/中所有对象默认都启用了Oilpan，但Node层次结构还未正式启用。
另外还有：http://chinagdg.org/2016/01/smarter-garbage-collection-for-smoother/
感觉简直屌炸天。
回到正题，目前只需要调用blink::shutdown 即可。但我实验下发现还需要手段调用v8::Isolate::GetCurrent()->LowMemoryNotification();才能把v8的内存给回收了，
否则一些dom node一直被v8给占着。这点需要记录一下。可能是我哪个地方调用不对吧。以后再关注。