Torrent.cheers();自定义密码长度的一个文件加密类
废话去代码文件里面的注释吧~直接上图上代码，有图有码有真相
package org.bruce.file.handle.handler;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.util.ArrayList;
import java.util.List;
import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.DESKeySpec;
import org.apache.commons.io.IOUtils;
import org.bruce.file.handle.config.BYSingle;
import org.bruce.file.handle.util.BY;
import org.bruce.file.handle.util.FileLists;
import org.bruce.file.handle.util.FileNameFilter;
/**
* @author Bruce Yang
* 由于 RSA，DES 的 key 都有着固定的长度，若将密钥保存为文件倒是合适，
* 但有时候却给一些情况带来不便，如：我不想随时拿着一个盛装着密钥的U盘
* 而且，如果用U盘来装密钥，u盘一旦丢了，那就完蛋了~
* 如果能够为加密文件设置一个自定义的密码，那么就没什么问题了，只要你不把密码忘了便行~
* 自定义密码长度的改造 des 加密算法~
*
* 另外，还想到其他几种自定义密码长度加密文件的方法，如：
* 1。由密码字符串获取字节数组，用这个字节序列对文件数据的0101取反
* 据介绍，DES算法加密的明文常有被破解的消息传出，
* 试想本例的 DES 算法采用了 8 个字符长度的密码对数据进行加密，多少是比不上 rsa 加密算法，
* 据我所至，rsa的密钥长度是 1024 bit 或 2048 bit等，长度比 des 对称算法所用的密钥长度长得多了，
* 破解的难度自然不小，试想 DES 如果采用了那么长的密钥，安全性也不会低的~
* 事实上，对文件数据进行加密，加密文件的安全性肯定是不能和web服务器数据库里面存放的数据相提并论的，
* 试想如果一个具备程序编写能力和对加解密比较熟悉的人获得了你加密过的文件，
* 他可以肆无忌惮的对你的文件进行各种各样的，不分白昼的解密尝试。
* 和 web 服务器数据库的安全性是完全无法作对比的。
* web服务器不高兴了，你针对某个账号做了仅仅几次的密码猜解，便会针对你的ip不让你再做多的尝试。。
* 那么，即便密码是简单的213三个数字，也不要想有多的想法。
* 当然，你也可以不停的换 ip 做猜解。我对这个不是很熟悉，不做多的评论。。。
* 密码简单也并非不安全，下面还有其他几个案例：
* 1。如银行取款机的6位密码，你又能有多少想法(有摄像头呢，你套密码就不怕被盯上?)？
* 2。如网站会员登陆时的验证码机制；
* 3。如淘宝的手机验证码验证机制，等等~
* 一句话，现在的人们都学精了啊，要早出生那么十几年，猜解暴破什么的，那就容易的多了~ ^ ^
* 花了不少时间研究这个主要是因为还没发现有一款像 windows 里面的 WinRAR 那样的软件，
* 如果有的话，我也不用费这么多劲儿了~
*
* 不过，对于一般人而言，即使是对普通的数据文件（图片，声音，视频，文档等）的2进制数据稍作修改，
* 如将文件的文件头做下处理，让相关程序在打开文件的时候无法处理此文件，
* 便能够过滤掉相当一部分人，让他们放弃获知文件真实内容的想法。
* 不过，对于别有居心的人，我还是提倡尽量将加密做到底！
* 其实，如果不是为了方便我记忆密码，采用8个字符的DES算法对文件进行加密，我个人还是觉得不那么安全的。
* 在我的印象里面，des貌似是将 文件分割成一段一段的，然后用密码对这一段一段的内容做加密处理
* 。。。。。思路有点儿乱了，下次有空在继续研究
*
* 可改进的地方：
* 1。写个UI壳子，这个东东基本上就可以拿来用了，到时候把种子，账号密码，私密照片什么的内容
* 通过这个东西来处理一下，基本上就能称得上有点儿安全内涵了，不错不错...
* 2。comment里面只能放ascii字符，到时候可以将中文用BAse64处理一下，就可以支持中文注释了，
* 到时候也可以在GUI里面弄一个加密文件的缩略信息查看功能，
* 要求能比较高效的拿出description部分的文件描述数据~
* 3。zip归档~
* 4。..暂时还没多的想法
*/
public class EncryptZipper extends Handler {
/** DES对称加密所用到的密码~ */
public static String PWD = "hello,java!";
/** 用于存放被加密过后的文件的中转目录~ */
public static String ENCRYPTED_DIR = "/Users/user/MyData/MyPersonal/encrypted";
/** 用于存放解密出来的文件的中转目录~ */
public static String DECRYPTED_DIR = "/Users/user/MyData/MyPersonal/decrypted";
/** 待加密文件所处的目录，或者是待加密文件的路径~ */
public static String RAW_FILES_DIR = "/Users/user/Desktop/test";
// 筛选特定格式的文件路径~
public static String[] SUFFIXS = {
".des",
};
public enum Mode {
encrypt,
decrypt,
};
// public static Mode MODE = Mode.encrypt;
public static Mode MODE = Mode.decrypt;
public EncryptZipper() {
/** 因为没有对源文件做内容更新，所以，完全没有必要做备份~ */
BYSingle.BAKUP_OR_NOT = false;
/** 测试 ant 的 deprecation 选项~ */
// @SuppressWarnings("deprecation")
// String s = new String(new byte[]{1,2,3}, 33);
}
/**
* 用例，使用的时候将 main(String args) 修改为 (String[] args)~
* 主要是怕手快不小心运行了这个类里面的入口
* （我真实的程序入口在另外一个地方，那里在之前会做一些安全检查操作）~
* 我发现我真有点儿怂了，上次乱搞磁盘被格了200多个G，
* 前几天搞个整站下载器，不小心删掉了我csdn博客40篇博文，
* 在我的辛勤恢复之下，还是丢了几篇文章(CSDN每日限制发布20篇博文)~
* 后面想了下，我当时的session没有关闭，整站下载器跑起来以后对我博客里面的各种连接那是一顿乱点啊，
* 置顶，删除什么的操作，整站下载器那是毫不犹豫地一往无前，结果我便悲催了...一把辛酸泪~
* 扯远了，拉回。。
* 修改 MODE 设置当前是加密还是解密
* 修改 RAW_FILES_DIR， DECRYPTED_DIR，ENCRYPTED_DIR 这几个目录确定相关文件所在的路径~
* 密码可以随便修改(小于我所规定的 32 个 ascii 字符即可，
* 实际上只有前8个字符会参与到 des 加解密，不过我有做简单的处理，还是设了一层屏障)~
* 还有，代码里面用到了一些我自定义的工具类：
* 1。BYSingle 仅仅是对加解密文件所处的路径做设置
* 2。BY 也只是让打印写起来更简短一点，如
* BY.log() == System.out.println()
补充：软件开发 , Java ,
