应用程序中的IO

来源：互联网发布：淘宝只能用手机注册吗编辑：程序博客网时间：2024/06/03 15:53

前记：

昨天是元宵节，外面在放烟花，炒得人很烦，本来打算加加班把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;