Windows BAT批处理 .pdf

批处理文件的编写8-BAT 文件的加密与解密 记事本程序在保存一篇新建的文档时，如果没有指定编码类型，会使 用缺省的ANSI 类型（对于中文版来说，对应的就是GB 码）。 而在打开一篇已创建的文档时，它会分析文档的编码类型，它首 先判断文档头部有无BOM（Byte order Mark，字节序标记，长度为( ２ - ３字节)，如有则根据其内容判断编码类型，FF、FE （Unicode）,FE、 FF （Unicode big endian）,EF、BB、BF （UTF-8)。 因为事实上有很多非ANSI 编码的文档是没有任何BOM 的“纯文 本” ，所以对这些文档不能简单的判断为ANSI 编码。而需要使用一 系列的统计学算法根据文档内容来猜测文档编码。记事本使用了 IsTextUnicode 函数来判断是否为Unicode/Unicode big endian 编码，使用 IsTextUTF8 判断是否为 UTF8 编码。但既然是统计学 算法，就难免存在误判，尤其在文档内容过短时，由于样本的容量太 小，这种误判的概率会显著增大。 比如那个有名的微软与联通有仇的笑话，就是记事本在打开只有 “联通”二字的ANSI 编码文档时，IsTextUTF8 函数将其误判为UTF8 编码。 示例 1： 新建一个记事本文本文档，然后顶头输入“联通”两个字，保存以 后再打开，看看是不是变成“■” 了。然后点另存为，注意看“编码”里是 不是由“ANSI”变成“UTF8” 了。 同样的误判也发生在IsTextUnicode 函数上，比如“this app can break”这种具有4335 结构的文档，会被误判为 Unicode 编 码。 示例2： 新建一个记事本文本文档，然后顶头输入“this app can break”， 保存以后再打开，看看是不是变成“桴獩愠灰挠湡戠敲歡”了。然后点 另存为，注意看“编码”里是不是由“ANSI”变成“Unicode”了。那么， 什么是4335 结果文档呢？就是所有形式是“AAAA AAA AAA AAAAA” 的。这里的A 可以是任意数字或字母等。这样的文档，都会 引起IsTextUnicode 函数的误判。 需要说明的是，这种误判的可能性是建立在文本较短且其字节位 特征不被干扰的前提上的。如果将上述的示例1 和示例2 中的文本做 稍许修改（即使只是增加一个回车），则误判很难再发生。而这种方 法的特殊性在于，它的字节串不但具有Unicode 特征，而且很长达 到了1288 字节，也就是说它的Unicode 特征性很强，所以可以抵 抗一些较短的不具有Unicode 特征串的干扰，这是由统计学的规律 所决定的。但是在干扰串稍长时，Unicode 的特征将会受到显著干 扰，直至被 IsTextUnicode 函数认定为非Unicode 。所以，有些 朋友总是无法测试成功，应该是与附加的批处理代码长度和内容相关。 因为其他的编辑器（比如 Word / Wordpad / EditPlus / UltraEdit ） 使用了更新的编码类型判断算法，所以在 Unicode 判断上改进了不 少，而 UTF8 的判断仍然不尽如人意。但因为理论上来说完全准确 地算法并不存在，所以我们只能依靠避免使用无BOM 的非ANSI 文 档，或者打开文档时手动指定编码类型。 另外，如果使用记事本保存了这些误判了编码类型的文件，则将 难以恢复。如果使用误判编码保存，则将给原文档加上BOM 标记， 则使用其他编辑器也再无法观察到原文档。如果使用ANSI 编码保 存，则原文档将会被当作 Unicode 文档而被转换，还原的可能性接 近于零。例如，将示例1 和示例2 中的内容清空，不做其他改动，会 发现其编码类型依然没有变化，即没有回到正常的ANSI 编码。 那么，编码的类型与今天我们要讲的BAT 批处理文件加密有什 么关系吗？当然！我们知道，查看BAT 批处理文件是一般使用记事 本。而默认的输入和查看的编码类型就是ANSI 编码。所以，简单的 加密方法就是混淆他的编码类型。那么，怎么做呢？难道在开头输入 “联通” 吗？当然不是！其实方法很简单，就是在开头大量加入 “%%a” 。 我们先看一个示例： 示例3： @echo off title 本程序仅用于 Windows XP Pro SP2 输入法的修复寒夜孤星 【初学者】 color 2f echo. echo.