基本上又是一个周六，为了保存kmz这么“简单“的问题，竟然耗费了好几天的时间
达到下面的功能：
1，绝对路径转为相对路径链接，并保存资源
2，数据可以保存在kmz文件中
3，不同模型引用的文件名可以避免重命名
为什么模型引用的纹理复杂，因为要考虑到以下几个方面：
1，路径的utf-8编码问题
经过测试google earth 输出的kmz模型里的编码都是utf-8字符串，如果有中文文件名，就会出现乱码，所以必须把utf-8字符串转为GB2312的。但是open collada的3dmax插件输出的dae模型中，文件路径使用的是utf-8字符串，但是把中文字符都变成%+字符的16进制。上一篇也提到，这里先要把这种转换后的字符串转为utf8字符串，最后再转换为gb2312字符串。
2，绝对路径和相对路径问题
这个问题是异常复杂，需要注意，纹理的相对路径是性对于模型位置的。
需要注意文件路径的 “file：”开头
注意路径分隔符 "/" 和 "/"
这次最后放弃了windows api的路径转换，完全自己实现了一些路径转换函数，也许效率不是很高的，但是能保证算法正确
而且自己的实现能够处理，一个文件相对另一个文件的路径，如c:/1.txt 相对 c:/2.txt s而windows api对于这种调用会失败。
3，模型中纹理引用和kml中模型的resourcemap
resourcemap里的target属性内的路径，实际上也是相对于模型文件来说的。
所以不仅仅要输出数据，而且要保存正确的resourcemap，否则下次打开依然出错。
4，文件重名问题，比如有两个模型分别引用了不同路径下的 1.jpg，当把这两个模型保存到一个kml中，那就必须处理1.jpg问题，幸好
有resourcemap，我的处理方式很简单，当发现冲突的时候会把第二个文件名修改为 _1.jpg
