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>

对！我早就预料到了，不过我单位用正版！<img src="images/post/smile/dvbbs/em05.gif" />

<b><FONT color=#000066>To LRA 你的问题我们已在别的地方讨论过了，我不想在这里谈论更多的细节。</FONT></b>

不全是这样的啊。我看过，它们前面好多字节的内容都被改了，所有有个程序也好。省得手动弄得好慢。呵呵。。。

所有图元参数都改了，所以只改两个字节是没用的。

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

<P>“非本系统文件”分两类：一类整个文件的后半部分的图元数据完全丢失，这时我看用你的那个小程序，也挽救不了“非本系统文件”文件。另一类图元数据完好，只是多了个别字节及地图参数、图元物理数、逻辑数等数据的改变，该类文件只要按我说的去做，完全可以修复的。</P><P>我分析过MAPGIS的文件格式，也知道文件内部的数据函意，向第一类情况，就是种地的人也没办法。第二种情况，因不同的版本出现问题的现象也不一样，我遇到的情况大多是图元参数受到破坏，不知其它人是否有这样的经历。用其它的方法就不好使了</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>

<P>To LRA </P>
<P>我们最好用“朋友”的称呼，你说的问题我没有遇到过，但听说过，我也想看一看，你那如果有现成的数据可发给我。我们共同学习！</P>QQ: 414773326

<img src="images/post/smile/dvbbs/em01.gif" />