为什么提取时要加特殊参数或索引文件，直接指定源文件/目录不行吗
从设计一开始，crass就想避免ws出现的那种情况：不管如何 你都必须指定你要提取的游戏
实际上这可能是一种聪明的做法 因为这可以避免误识别和误提取：即本来是提取别的游戏的插件却被用来提取不支持的游戏
而且也给使用者带来惯性 习惯之后自然也不觉得不方便 但是 如果使用者打算批量提取多个游戏 ws就相形见绌了 当然也许这种情况并不多 但是crass既然已经如此设计 我们就不提这个了
crass是怎么设计的呢？
无论你是提取一个文件也好 还是提取一个目录下包括子目录中的所有文件也好 只要不指定任何参数 crass会尝试使用每一个插件进行匹配 如果匹配成功 那么crass就用这个匹配的插件去提取了 但是 有的文件格式特殊 插件没法判定当前要提取的文件，是否与插件支持的文件格式相匹配 如果硬去提取 可能会出现：
1）分配巨大的内存 这是因为插件会为索引段分配内存 而索引项的个数可能是错的（一个非常大的正数） 这将导致分配的内存远远超过实际的内存 或者即使没超过也有几十上百M 而如果插件和文件是完全匹配的 那么索引数一定是一个正确且合适的数值 自然不会有问题
2）程序崩溃
这个就不用说了
所以 当碰到这种没法100％进行匹配的文件的时候 crass的做法就是不提取这种文件 这比起潜在的可能遇到的上述糟糕结果要好的多
但是使用者不知道到底发生了什么 他们看到的就是没法提取而已
因此如何guide好用户 让他们知道如何指定特殊参数来正确提取这些特殊的／没法自动识别的文件 就是crass文档的任务 当然 不看文档的人大有人在
我曾经谈过这件事情 当时有人建议应该把文档以及其结构组织的更好一些 而我的想法是采用智能算法 让crass在提取时给出所有可能的插件列表以及对应的提取命令和参数 也许这真是一个很好的想法 但是这个做法
1）增加了代码的复杂度和维护难度 我相信这个特性引入后会引起很多问题
2）真的值得花时间在这上面吗 记住crass是一个提取器 支持更多的文件格式才是首要任务
所以我现在觉得智能猜测完全不对路 而之所以有这个想法是因为即使文档组织的再好 人还是可能不去看它
我不觉得持有简单的丢弃这些懒汉的想法就能让一切变得更好 诚然每个用户都应该仔细阅读手册 但是做到的人真的不多
所以 把问题转换一下 不要想着指望用户看文档；如果不看 那么我们就以程序的方法给出建议 这完全走向了另一个怪圈
根结应该是：为什么需要指定其他的参数才能提取
ok 我想问题提出来了 那么我来说一下那些需要指定额外参数才能提取的插件为什么需要额外参数 以及用他们来干什么
第一类参数：插件名
这种插件之所以存在 就像前面说的 被提取的文件格式很特殊 插件没有什么办法去判定插件是否支持并提取这个文件 所以 为了不产生错误 只能请用户来指定 如果你认为这个插件能提取某游戏 那么请指定这个插件 这就好像插件被用户做了一个假设 假设你现在提取的文件 就是你支持的格式 当然你故意指定错误 出错是一定的了
当然指定插件有另一个好处：加快提取速度 crass不再用所有的插件一个个测试了 直接用你指定的插件来提取 实际上 按照这种理解去使用指定插件名的使用着才是crass的熟练使用者 不过这个加速也只不过是省去了先期的自动探测而已
第二类参数：索引文件
因为被提取的文件的一些重要信息 有时候会单独存在另一个文件里 为了顺利提取 你不得不还得指定这个文件的位置
这个参数的存在看起来似乎理所当然 因为被提取的文件确实被分成了2部分：数据文件和索引文件
所以好像没法避免不指定这个参数
第三类参数：特殊参数
这类参数比较杂 简单的情况是指定game名称 复杂一点的是指定某exe或特殊文件的路径
这种参数的用途很简单 因为每个游戏用的算法都不同 所以通过game参数告诉插件应该用什么算法来提取 打个比方 比如某插件的game参数支持6个game 那么其实你可以认为存在6个不同的插件 每个插件只能提取一个游戏 而且只有用-u指定插件名才能提取指定的游戏 所以人为干预插件去提取是必须的
最臭名昭著的一个例子是Csystem插件 它是需要同时指定以上3类参数才能正确提取的佼佼者：用game参数指定不同的游戏；用-l参数指定索引文件 又因为格式特殊 无法自动匹配 所以还要指定插件名 orz
解决方法：
对于第一类 实际上我已经有在特别注意了：在开发新插件的时候 尽量通过判定索引段的方法来确定这种特殊格式文件的唯一性 比如如果读取的最后一个索引项的指定的资源的偏移＋size等于整个文件的size 那么基本上就是正确的了 当然要排除全0的可能 或者干脆验索引段里的每一项 但是索引项的个数也应该做足检查 否则一口气分配索引段将可能导致分配过大的内存 基本上 大多数被标记为no magic也就是必须指定插件名才能提取的游戏 都可以用这种探测方法解决 老的插件我得慢慢改 而新的插件我会尽量不让用户指定插件名来提取。也许现在这类插件还有一定数量 但是在将来这类型的插件将不会成为主要的需要提供额外参数才能提取的“问题”对象
对于第二类 因为通常索引文件和被提取的文件在同级目录 可以通过指定的文件路径推断出索引文件的位置 但是对于目录提取 尤其是你指定的是盘符 而实际的文件在很深的目录 这个功想法可能会受到限制 最多我们只能猜出一级而已 所以看起来似乎并不实用 不过在本级作猜测（假设被提取文件所在的目录或被提取的目录的目录下就有索引文件）还是可行的
对于第三类 能改善的地方相当有限 因为不是每个解密算法都能通过穷举或者利用一些算法的漏洞，在即使不指定解密key也能猜出真正的key或者是明文key hash或加密后真正用来解密的key的情况下，可以自动对数据解密 能做到这个的插件数量不多 所以几乎可以肯定 这类参数在未来会占主流。
综上所述 我会在未来的开发中尽量避免用户指定源文件或目录以外的参数的 但是不可能完全避免 比如现在有160个插件 那么如果只有10％－15％左右的插件只需要必须指定额外的参数 那么我想这还是可以接受的
[ 本帖最后由 痴汉公贼 于 2009-07-02 09:39 编辑 ]
