TO YFLK：

<P>TO YFLK：其实没必要编小程序，关键是“非本系统文件”与正常文件的区别在于二进制的第10、11两个字节上，用任何一款Hex、ASCII 码编辑器(最简单的如：<a href="http://member.netease.com/~long/book/ultraedit.htm" target="_blank" ><FONT color=#e10900>UltraEdit</FONT><FONT color=#000000> </FONT></A>)打开，将上述的两个字节改为00 00后保存即可。</P>
<P>我说的应该对吧？</P>

<P>TO　4楼：“不全是这样的啊。我看过，它们前面好多字节的内容都被改了，所有有个程序也好。省得手动弄得好慢。呵呵。。。 ”</P>
<P>你分析过MAPGIS的文件格式吗？</P>
<P>另：TO　“YFLK”：</P>
<P>“非本系统文件”分两类：一类整个文件的后半部分的图元数据完全丢失，这时我看用你的那个小程序，也挽救不了“非本系统文件”文件。另一类图元数据完好，只是多了个别字节及地图参数、图元物理数、逻辑数等数据的改变，该类文件只要按我说的去做，完全可以修复的。</P>
<P>你也别说其他的，因为我做过，已经修复了N个如此之类的文件。也就懒的动手用VC去编一个什么克星之类的二进制的读写小程序。</P>
<P>YFLK,，本人在此说一下，只是想就问题进行探讨，并无其他任何意思。要是有什么不是之处，本人在此郑重的向你道歉，说一声：对不起了，刘工。</P>

<P>刘工，你好！我相信你很仔细的分析过MAPGIS的文件结构，以你的很高的编程水平与MAPGIS二次开发的水平来说，这点不是大问题，应该是毛毛雨的事。这点我丝毫也没有什么怀疑。</P><P>我问有没有分析过MAPGIS的文件格式，是指4楼的朋友hanyu_gis，并没有针对你，千万别误会。</P><P>你说的没错：“第二种情况，因不同的版本出现问题的现象也不一样，”。我遇到的情况大多数也仅是图元参数受到破坏，只有极少数出现第一种情况。因我也比较的懒，所以也就采用我自己的方法去解决了，所幸的是改后经压缩存盘后基本上可解决问题。当然这只是我个人的做法，不值的一提。</P><P>另有个问题要在此请教：不知你注意到了没有，用6.5虚拟狗生成的标准图框与用6.1生成的在Y轴上有一定的偏差（差距还不小），这是没有什么好说的了，但我用6.5正版狗生成的标准图框与用6.1生成的在Y轴上也有一定的偏差（类似于用虚拟狗）。而用6.5虚拟狗+6.6PJ补丁生成的标准图框与用6.1生成的则一模一样。我想这应该是“种地公司”搞的鬼，现在搞升级和维护的人员与当初搞开发的应该是换了好几拨人，不知是不是算法有问题（算法的改进？算法的失误？）。我想这个问题应该好好的问问“种地公司”的那班人才是。你的看法如何？</P>