bat文件虽然好用，但安全性太脆弱
随便什么人都可以打开查看，甚至修改其中内容
有没有什么办法不把.bat转换成.exe或.com之类，仍是.bat文件
但别人无法查看并修改其中内容？？？
有没有什么自我加密之类的呢？
高手给个解决的思路吧
目前讨论的方案如下：
１、在批处理代码插入Unicode特征串的方案
对记事本等使用IsTextUnicode函数识别编码类型的程序有效
对type/edit/EditPlus/UltraEdit等不使用IsTextUnicode函数的程序无效
２、给批处理代码头部增加Unicode字节序标记（BOM）的方案
EncryBat.rar(zxcv)
对记事本、Word、UltraEdit、type等支持Unicode编码的程序有效
对edit/WinRAR内部查看器等不支持Unicode编码的程序无效
３、将批处理代码的回车换行符置换为回车符的方案
对edit等分别识别回车换行符的编辑器有效
４、对批处理代码进行字典式转换的方案
代码明文运行时动态生成，故此方案与编辑器无关；
BAT文件加密法（比Bat2Com那个软件好使<因为那个软件不支持中文>）
方法是:
打开“记事本”将文件开头写入以下的语句
复制代码 代码如下:
for/l%%ain(1,1,10)doren*.jpg%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a%%a
记事本程序在保存一篇新建的文档时，如果没有指定编码类型，会使用缺省的ANSI类型（对于中文版来说，对应的就是GB码）。
而在打开一篇已创建的文档时，它会分析文档的编码类型，它首先判断文档头部有无BOM（ByteOrderMark，字节序标记，长度为２～３字节），如果有则根据其内容判断编码类型，FF、FE（Unicode）,FE、FF（Unicodebigendian）,EF、BB、BF（UTF-8）[1]。
因为事实上有很多非ANSI编码的文档是没有任何BOM的“纯文本”，所以对这些文档不能简单的判断为ANSI编码。而需要使用一系列的统计学算法根据文档内容来猜测文档编码。记事本使用了IsTextUnicode函数来判断是否为Unicode/Unicodebigendian编码，使用IsTextUTF8判断是否为UTF8编码。
但既然是统计学算法，就难免存在误判，尤其在文档内容过短时，由于样本的容量太小，这种误判的概率会显著增大。比如那个有名的微软与联通有仇的笑话，就是记事本在打开只有"联通"二字的ANSI编码文档时，IsTextUTF8函数将其误判为UTF8编码[2]；同样的误判也发生在IsTextUnicode函数上，比如具有“thisappcanbreak”这种具有4335结构的文档，会被误判为Unicode编码[3][4]。
需要说明的是，这种误判的可能性是建立在文本较短且其字节位特征不被干扰的前提上的。如果将上述的文本做稍许修改（即使只是增加一个回车），则误判很难再发生。
而yuanyong630兄方案的特殊性在于，它的字节串不但具有Unicode特征，而且很长达到了1288字节，也就是说它的Unicode特征性很强，所以可以抵抗一些较短的不具有Unicode特征串的干扰，这是由统计学的规律所决定的。但是在干扰串稍长时，Unicode的特征将会受到显著干扰，直至被IsTextUnicode函数认定为非Unicode。所以，有些朋友总是无法测试成功，应该是与附加的批处理代码长度和内容相关。大家可以测试一下[5]中的代码。
因为其他的编辑器（比如Word/Wordpad/EditPlus/UltraEdit）使用了更新的编码类型判断算法，所以在Unicode判断上改进了不少，而UTF8的判断仍然不尽如人意。但因为理论上来说完全准确地算法并不存在，所以我们只能依靠避免使用无BOM的非ANSI文档，或者打开文档时手动指定编码类型。
另外，如果使用记事本保存了这些误判了编码类型的文件，则将难以恢复。如果使用误判编码保存，则将给原文档加上BOM标记，则使用其他编辑器也再无法观察到原文档。如果使用ANSI编码保存，则原文档将会被当作Unicode文档而被转换，还原的可能性接近于零。
[1]Unicode简介
http://my.opera.com/neutronstar/blog/index.dml/tag/编码
[2]微软为什么和联通有仇
http://blog.vckbase.com/localvar/archive/2005/07/12/9510.aspx
[3]Notepadbug?Encodingissue?
http://weblogs.asp.net/cumpsd/archive/2004/02/27/81098.aspx
[4]BushHidTheFacts
http://www.shoutwire.com/comments/16341/Bush_Hid_The_Facts
[5]cry.cmd
对于将0d0a改为0a的方法，不如将之改为0d。也即将回车换行改为只回车不换行，则当前行的文本会被没有换行的文本行所覆盖，如此反复覆盖叠加。如果在批处理的最后一行添加一句长度大于以上所有行的注释文本，则最终只会显示这样注释。
这样的方法，对EDIT和TYPE是有效的，所以在DOS时代曾一度流行。不过，这个方案与yuanyong630兄的方案类似，只是针对于特定文本处理器的特定文本处理机制，无法适用于所有平台环境。
至于其他的加密方法，也各有缺陷，想达到软件工程的要求是比较困难的。.
BAT加密工具.rarEncryBat.rar