Java AES图片加密解密：基于字节流的文件加密实现-育师

简介：面向Java学习者与信息安全初学者的图片加密解密示例，程序基于Java IO流与常见对称加密算法实现，适用于课程设计、实验练习或理解数据保护基础原理。资源包共5个文件，包含可运行的Java源码、编译后的class文件、示例图片以及数据库文件，压缩包整体仅514KB，轻量易用，适合导入IDE后对照阅读和运行验证。目前已有1904人学习下载。源码覆盖字节流读写、BufferedInputStream/BufferedOutputStream缓冲机制、CipherInputStream/CipherOutputStream加密流，以及密钥生成与保存、异常捕获、模块化封装等关键点；通过内置的样例图片，可以直观对比加密前后文件内容与可读性的变化，并测试不同图片格式下的兼容性。对于希望将Java IO与加密技术结合应用的读者来说，这是一份便于快速上手的入门参考，也能帮助建立文件安全处理的基础认知。

1. 这个图片加密程序到底是什么：一条字节流，不是一张图片处理

给一批图片加个密，再丢给别人，对方拿到手也打不开——这个用Java实现的图片加密程序干的就是这件事。第一眼看上去它跟常规的图像处理没什么关系：不识别图片内容、不压缩画质、不去逐像素计算，它处理的是图片文件本身的字节流。整条加密链路一共三件事：读文件字节、加密字节、写回新文件；解密就是逆着走一遍。核心是Java IO流与图片加密解密，适合正在学Java文件流操作的人看，也适合想给素材资源做一层简单保护、又不想引入重型加密框架的开发者。整套程序零外部依赖，编译后就是一个可执行Jar，命令行一把梭。

2. 技术选型与工程结构：为什么用文件IO直读字节流

2.1 为什么选文件IO而不是像素矩阵处理

拿到“图片加密”这个需求时，第一反应可能有两条路：一条是把图片读成BufferedImage，遍历像素点做置乱或异或，再重新编码写出；另一条是老老实实用FileInputStream把整个文件读成byte数组，对整个字节序列做加密。这个项目选的是第二条路，而且选得相当克制。

原因很直接：如果走BufferedImage路线，图片在读取和写出时必须经过ImageIO编解码，一次往返就是一次有损压缩。JPEG格式尤其明显，连续加解密几次之后，图片会出现色块、噪点，文件大小也会变，用户拿到解密文件一看，画质跟源文件对不上，这就违背了“加密后要能无损还原”的初衷。而字节流方案拿到的原始二进制是什么样，解密还原出来就是什么样，逐字节一致，无论PNG、JPG还是BMP，通吃。

加密算法方面，这个项目没有自己造轮子，用了JDK自带的AES对称加密。AES-128-CBC是主流选择：密钥长度16字节，KeyGenerator初始化方便，Cipher.getInstance("AES/CBC/PKCS5Padding")一次拿全，不需要额外引入任何库。至于为什么不直接上AES-256，后面避坑章节会专门讲，这里先卖个关子。

2.2 目录结构与模块职责

整个工程是一个标准的Maven单模块项目，但说实话，就算没有Maven，用javac手动编译也能跑起来，因为没有任何第三方依赖。目录结构如下：

src/main/java/com/example/imagecipher/ ├── Main.java ├── core/ │ ├── ImageCipher.java │ ├── KeyDeriver.java │ └── FileHeader.java ├── cli/ │ └── CommandParser.java └── exception/ └── CipherException.java

四层各管各的，拆得很干净。core包是核心逻辑，ImageCipher负责加密和解密主流程，KeyDeriver负责把用户输入的密码字符串变成合法的AES密钥，FileHeader维护加密文件的头部结构——这个头部结构是整套设计里最值得看的点，后面会展开；cli包只做命令行参数解析，不掺业务；exception包统一定义了业务异常，比如文件头校验失败、密钥非法这类情况，上层只需要catch一种异常类型就够了。

提示：项目没有用Spring、没有用Bouncy Castle，整个依赖就一个JDK 8+。这一点对想拿它当学习材料的人非常友好，断网环境下也能编译运行。

3. 核心模块拆解：密钥派生、加密写盘、解密校验的完整链路

3.1 密钥派生：从密码字符串到AES-128密钥

先看KeyDeriver。这段代码解决的根本问题是：用户输入的是字符串密码，而AES-128要求密钥恰好是16字节。直接拿字符串.getBytes()取前16位是一种做法，但会踩字符集和长度不够的坑。常见做法是把密码做SHA-256散列，再截取前16字节作为AES密钥，这样任意长度的密码都能稳定生成固定长度的密钥。

import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; public class KeyDeriver { /** * 从用户密码派生AES-128密钥 * @param password 用户输入的密码字符串 * @return 16字节密钥 */ public static byte[] deriveKey(String password) { try { MessageDigest digest = MessageDigest.getInstance("SHA-256"); byte[] hash = digest.digest(password.getBytes("UTF-8")); // AES-128 只需要16字节，截取前128位 byte[] key = new byte[16]; System.arraycopy(hash, 0, key, 0, 16); return key; } catch (NoSuchAlgorithmException | java.io.UnsupportedEncodingException e) { throw new CipherException("密钥派生失败", e); } } }

逻辑不复杂，但有三个细节值得说。第一，固定用UTF-8编码取字节，这是为了避免不同操作系统默认字符集不一致导致同一个密码产生不同的字节序列；第二，SHA-256散列保证了即使密码很短，密钥空间也是均匀分布的，不会出现全是0的弱密钥；第三，截取前16字节这个动作写成了System.arraycopy，比手动for循环清晰，也避免了数组复制的玄学性能问题。

3.2 加密主流程：魔数、IV、密文写盘

加密的完整过程分为三步：读取源文件字节、构造文件头、加密并写出。文件头是这套设计的精髓，它在密文的最前面写入了三个信息：魔数、加密算法参数偏移量、原始文件名长度和原始文件名。为什么要写原始文件名？因为加密后的文件已经不再是图片格式，后缀名没有意义，解密时必须能恢复原名。

public void encrypt(File src, File dest, String password) throws Exception { // 1. 读入整个图片文件字节 byte[] plainBytes = readAllBytes(src); // 2. 派生AES密钥 byte[] key = KeyDeriver.deriveKey(password); // 3. 随机生成16字节IV，CBC模式必须保证IV随机且每次不同 byte[] iv = new byte[16]; SecureRandom random = new SecureRandom(); random.nextBytes(iv); // 4. 初始化加密器 Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"), new IvParameterSpec(iv)); byte[] encryptedBytes = cipher.doFinal(plainBytes); // 5. 组装文件头：魔数 + 版本 + IV + 原文件名长度 + 原文件名 + 密文 byte[] fileNameBytes = src.getName().getBytes("UTF-8"); ByteBuffer header = ByteBuffer.allocate(8 + 1 + 16 + 4 + fileNameBytes.length); header.putLong(0x494D47454E435233L); // 魔数 "IMGENCR3" header.put((byte) 0x01); // 版本号，预留兼容后续格式 header.put(iv); header.putInt(fileNameBytes.length); header.put(fileNameBytes); try (FileOutputStream fos = new FileOutputStream(dest)) { fos.write(header.array()); fos.write(encryptedBytes); } }

这里有个关键点：加密器初始化后密文的长度会发生变化。PKCS5Padding会把明文补齐到16字节的整数倍，所以加密后的文件会比原文件多出1到16字节的填充，这是正常现象，不要以为是数据损坏。IV是随机生成并明文写在文件头里的，不要担心IV泄露，IV本身不需要保密，CBC模式下它的作用只是让相同明文在不同加密中得到不同密文。

文件头的魔数我用的值是0x494D47454E435233L，对应ASCII字符“IMGENCR3”。这段设计的价值在于：解密时先读前8字节做校验，一旦对不上就直接抛出“不是有效的加密文件”，而不是傻乎乎地去解一段垃圾数据，避免了一堆难以排查的诡异情况。

3.3 解密流程：校验头部并还原原始文件名

解密是加密的逆过程，但多了两步：读文件头、校验魔数。这也是整个程序里最容易出bug的地方，因为文件头的字节布局必须和加密时完全一致，一个字节错位，所有解析结果全乱。

public String decrypt(File encFile, File destDir, String password) throws Exception { byte[] key = KeyDeriver.deriveKey(password); try (FileInputStream fis = new FileInputStream(encFile)) { // 1. 读取8字节魔数并校验 byte[] magicBuf = new byte[8]; fis.read(magicBuf); long magic = ByteBuffer.wrap(magicBuf).getLong(); if (magic != 0x494D47454E435233L) { throw new CipherException("文件头校验失败，不是本程序生成的加密文件"); } // 2. 读版本号 int version = fis.read(); if (version != 0x01) { throw new CipherException("不支持的加密版本: " + version); } // 3. 读取IV byte[] iv = new byte[16]; fis.read(iv); // 4. 读取原始文件名长度和文件名 byte[] lenBuf = new byte[4]; fis.read(lenBuf); int nameLen = ByteBuffer.wrap(lenBuf).getInt(); byte[] nameBuf = new byte[nameLen]; fis.read(nameBuf); String originalName = new String(nameBuf, "UTF-8"); // 5. 读取剩余密文并解密 byte[] encryptedBytes = fis.readAllBytes(); Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.DECRYPT_MODE, new SecretKeySpec(key, "AES"), new IvParameterSpec(iv)); byte[] plainBytes = cipher.doFinal(encryptedBytes); // 6. 写出到原文件名 File outFile = new File(destDir, originalName); try (FileOutputStream fos = new FileOutputStream(outFile)) { fos.write(plainBytes); } return outFile.getAbsolutePath(); } }

参数说明：encFile是加密文件路径，destDir是解密输出目录，密码必须与加密时一致。解密时Cipher.doFinal密文长度不需要手动去掉填充，PKCS5Padding会在解密时自动去掉补位字节，返回的plainBytes就是原始图片的完整字节。

常见的一个误区是：有人会自己计算“去掉最后N个填充字节”，这完全是画蛇添足，而且容易误伤原图最后一位恰好是0x01的情况。解密返回的字节数组直接用就行，不要再做任何长度修正。

4. 避坑笔记与运行步骤：常见的翻车现场排查和一条命令跑通

4.1 踩坑：加密后的图片双击打不开

现象：加密流程跑完，生成的文件扩展名还是.jpg，双击打开直接报错，图片查看器提示文件格式损坏。

原因：文件的真实格式由文件头的前几个字节决定，JPEG的头部固定是FF D8开头的SOI标记。加密后整个字节序列变成了AES密文，文件头自然不再是FF D8，图片查看器拿着密文当JPEG解析，当然打不开。

解决：加密后的文件扩展名不要沿用原图片格式，建议统一改成.img、.enc这类自定义后缀。更进一步的做法是在文件头里存原始文件名，也就是这个项目已经实现的机制——解密时直接恢复原名，而不是让用户手动输入。

4.2 踩坑：大图解密时直接内存溢出

现象：一张十几MB的高清素材图，加密没问题，解密时JVM直接抛OutOfMemoryError，程序当场崩掉。

原因：项目里的readAllBytes和readAllBytes两个方法都是把整个文件一次性读进内存。图片文件动辄几十MB时，加上AES加解密过程中产生的中间数组，瞬时内存占用可能达到文件大小的三四倍。JDK默认堆内存只有256MB左右，很容易触顶。

解决：如果确认处理的是普通尺寸图片，保持现状没问题；如果可能有几十MB以上的大文件，建议把单次全量读写改成分块流式处理，Cipher.update配合8KB缓冲区分批加解密。这也是第5章二次开发里我会给的改进方向之一。

4.3 踩坑：同一密码在不同机器上解不开

现象：开发机上加密没问题，换一台机器解密，报“BadPaddingException: Given final block not properly padded”。

原因：经典坑。旧版本代码里密钥派生直接用了password.getBytes()，没有指定字符集。Windows默认GBK，Linux默认UTF-8，同一个中文字符密码在两台机器上生成的字节序列不一样，派生出来的AES密钥也就不一样。AES解密时密钥对不上，PKCS5Padding校验必然失败，最终表现就是最后一个块填充不合法。

解决：密钥派生时明确指定UTF-8，也就是现在KeyDeriver里password.getBytes("UTF-8")的写法。已经踩过这个坑的，需要拿着原密码重新在开发机上加密一遍，没有其他后悔药可吃。

4.4 踩坑：解密出的图片能打开但是花屏

现象：解密没报错，文件也打开了，但图片内容全是彩色噪点，完全看不出原图。

原因：这种情况九成是IV不对。如果加密时没有把IV写入文件头，而是用了固定IV，那么加密、解密都还能跑通，不会报错；如果IV在文件头里写错位置或者读错偏移，解密出来的第一块明文就是乱的。CBC模式下每个密文块都依赖前一个块，IV错一个字节，第一个块全错，CBC还有可能往下传播两个块。

解决：加密时将IV写入文件头，解密时严格按相同偏移读取。每次加密用SecureRandom随机生成新IV，不要写死。判断IV对不对有个土办法：我的血泪经验就是花屏图片如果前16字节乱、后面能隐约看到图像轮廓，基本可以断定是IV解析错位，直接去看文件头读写代码。

4.5 完整运行步骤与命令行参数

编译运行不需要任何外部依赖，Maven或javac都可以。命令行参数设计得也比较直白，一共三个动作：

参数	说明
encrypt <源图片> <输出文件>	加密图片，输出自定义后缀文件
decrypt <加密文件> <输出目录>	解密到指定目录，自动恢复原始文件名
password	在encrypt/decrypt之后输入，示例中直接作为第三个参数传入

# 用Maven打包 mvn clean package # 加密 java -jar target/imagecipher.jar encrypt photo.jpg photo.img password # 解密 java -jar target/imagecipher.jar decrypt photo.img ./output password

Main入口负责把命令、文件路径、密码三个参数解析出来，然后分发到ImageCipher的encrypt或decrypt方法。校验逻辑放在CommandParser里：命令不合法、文件不存在、密码为空，都会直接打印错误提示并退出，不会往下走到核心逻辑层。

5. 二次开发改造：从单文件加密到批量工具的三个落地方案

5.1 方案一：抽象加密接口，算法即插即用

现在ImageCipher类里硬编码了AES/CBC/PKCS5Padding，如果哪天想换成SM4或者其他算法，要动核心类。改造思路是抽一个CipherEngine接口，把算法初始化、加密、解密三个动作抽象出来，AES实现、XOR实现、SM4实现各自成一个类，ImageCipher只依赖接口。

public interface CipherEngine { byte[] encrypt(byte[] data, byte[] key, byte[] iv) throws Exception; byte[] decrypt(byte[] data, byte[] key, byte[] iv) throws Exception; }

这样改造后，文件的魔数还可以顺便加一位算法标识，解密时读头部就知道该用哪个引擎，做到加密文件的自解释。

5.2 方案二：流式包装类，处理超大文件

一次性读入字节数组的内存问题，可以用CipherOutputStream和CipherInputStream解决。把加密逻辑包成流，文件多大就用多大缓冲区分批写，内存占用永远是固定的64KB级别。我一般会这样设计：加密时把文件头先写入，再包装一层CipherOutputStream写文件体；解密时反过来，先读文件头，再包装CipherInputStream读文件体。