前记:
昨天是元宵节,外面在放烟花,炒得人很烦,本来打算加加班把kmz模型的保存搞定,但是后来也懒了,困了(前天早上7点就起来去给宝宝拍体检的号了),就早早睡了。
collada模型的渲染问题基本解决了,就剩下数据的保存问题
表面上这个保存过程一点技术含量的都没有,不就是写文件吗。
可事实上,牵扯到资源“路径”问题的,没有一个容易的。以前解决kmz内图标加载和保存的时候费半天劲,现在发现模型纹理的加载和保存更麻烦,因为模型纹理的路径是相对模型的。
所以这两天一直再想是不是自己实现一个路径操作的库,那windows的api实在难用,经常出错而且不可控。在犹豫中这个kmz的保存问题就被耽搁下来了。
数据是应用程序的基础,没有数据,再好的算法也没有啥效果,这就是巧妇难为无米之炊。
但是数据的来源是五花八门的,基本有几种,1) 本地文件,2)网络数据,3)数据库
本地文件实际上还可以分:单个文件 和 压缩文件
来源一般是通过路径字符串来标志的,但是这个路径有相对,有绝对,有网络 有URI风格的,有windows风格的,反正是会搞得你头晕脑涨。
数据的"input”问题需要一个良好的框架来封装,单纯的以路径来访问这些数据会有些问题,比如访问压缩文件内的文件
但是这个问题毕竟还是可以解决的,当前我实现的ResourceManager基本能做到这一点。
数据的"output"问题实际更复杂,不是说把数据写的硬盘就ok了,关键是要根据需要更改数据之间的链接关系,是相对的还是绝对的。
是压缩的,还是非压缩的。如果是相对的,那么相对于哪个路径? 还需要考虑http数据如何处理(可以保存到本地,也可以不处理)。这一切都是为了这个数据下次能正确的input。
现在内部的实现这里不是很好,有点混乱的,搞得有些逻辑很复杂,而且牵扯到路径之间的转换,经常会出现各种小BUG。
昨天碰到一个路径问题,记下来
路径中出现类似这样的字符串 %E9%A1%B9 ,这个很显然是中文路径引起的。参考了一些网上资料
中文的gbk(GB2312)编码
如果是中文的gbk(GB2312)编码,那么它的形式应该是这样的,即一个汉字对应两组%xx,即%xx%xx,比如http://www.baidu.com/baidu?tn=baidu&word=%D6%D0%B9%FA 这个网页地址是百度的,百度是使用GB2312编码的,这个网址中我们可以看到的特殊代码是“%D6%D0%B9%FA”,其中前面的“%D6%D0”就对应中文汉字“中”字,后面的“%B9%FA”就对应中国汉字“国”字。
中文的UTF-8编码
如果是中文的UTF-8编码,那么它的形式应该是这样的,即一个汉字对应三组%xx,即%xx%xx%xx,比如http://www.icpoline.com/tag/%e7%bd%91%e6%b0%91 ,这个网址是本站IcpOline.com的网页,IcpOline使用的是UTF-8编码,这个网址中的”%e7%bd%91%e6%b0%91″对应着中文汉字“网民”,即“%e7%bd%91”对应汉字“网”,“%e6%b0%91”对应中文汉字“民”。
本来不想处理,后来试了google earth,人家加载都正常的,这可不行,山寨版的google earth怎么能比google earth差,所以又写了一些代码来转换它。
转换算法也简单,无非把%后面的转为16进制数字,然后再调用MultiByteToWideChar(CP_UTF8....
这其中碰到一个小问题,就折腾了半天,这种问题太隐蔽了,贴出来避免犯错
char t1 = 0x0e;
char t2 = 0x09;
我现在想得到一个0xe9的结果,所以写了如下代码
char c = t1 << 4 + t2;
一眼看去,这有啥问题啊,
出人意料调试后 c 竟然等于0
修改代码如下
char t1 = 0x0e;
char t2 = 0x09;
t1 = t1 << 4;
char c = t1 + t2;
这会调试,结果正常
呵呵,发现了吧,操作符优先级搞得鬼
我一直想着移位操作符 的优先级 高于 加法,没想到竟然错了,以后要注意