Base64编码使图片变大是因每3字节转4字符，理论膨胀33%，加换行符后约增大1/3；常见错误是重复编码或误用文本模式读取，正确做法是rb模式读取bytes并用ascii解码。
Base64编码图片时为什么文件变大了
Base64把每3个字节转成4个可打印字符，理论膨胀率是 4/3 ≈ 33%，实际还多2个换行符（\n）——所以用base64.b64encode()直接处理二进制数据后，结果比原图大1/3左右。这不是bug，是设计使然；如果你发现膨胀远超这个比例，大概率是误把已编码字符串又编了一次，或读取时用了encoding='utf-8'导致乱码。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 编码前务必以
'rb'模式打开图片文件，得到bytes对象 - 避免对
bytes调用.decode()再传给b64encode()——它只接受bytes - 如需嵌入HTML的
src="data:image/png;base64,..."，结尾不用加换行，用base64.b64encode(data).decode('ascii')转成干净字符串
Python里解码Base64字符串保存为图片总报错
最常见错误是binascii.Error: Incorrect padding，说明输入字符串长度不是4的倍数，或混入了空格、换行、URL不安全字符（如+、/）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 先用
string.replace(' ', '').replace('\n', '').replace('\r', '')清理空白 - 检查末尾是否缺
=：Base64长度必须是4的倍数，不足则补=（最多补2个） - 如果是从URL或表单来的字符串，可能用了URL安全变种（
_代替-，-代替+），得先还原：string.replace('-', '+').replace('_', '/') - 解码后务必用
base64.b64decode()得到bytes，再用open(..., 'wb')写入，别用'w'文本模式
如何用PIL验证Base64解码后的图片是否有效
光解码成功不代表图片能正常打开——可能头信息损坏、格式不匹配，或被截断。靠try/except捕获IOError或OSError不够准，PIL的Image.open()才是真校验。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 解码得到
img_bytes后，用io.BytesIO(img_bytes)构造内存流，再传给Image.open() - 立刻调用
.verify()（注意：该方法可能静默失败，需配合try/except） - 更可靠的是尝试
.load()或访问.size属性，触发真正解码 - 如果原始Base64来自前端Canvas导出，注意它默认是
image/png，但若后缀写成.jpg，PIL会因格式不匹配报错
命令行快速编码/解码图片的实用脚本怎么写
不需要GUI，一个带参数的脚本能覆盖90%临时需求。关键是区分输入类型：是文件路径？还是Base64字符串？还是stdin流？
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
argparse接收--encode/--decode和input_path，再根据是否存在.png等后缀判断模式 - 编码时：读文件→
b64encode→打印；解码时：读字符串或文件→清理→b64decode→写文件 - 支持管道：
cat photo.png | python b64tool.py --encode，此时忽略input_path，从sys.stdin.buffer读bytes - 别硬编码
utf-8：Base64字符串本质是ASCII，用ascii解码更安全
Base64本身无加密性，只是编码；真正容易被忽略的是：不同系统对换行符的处理（\n vs \r\n）、前端JS的btoa()和Python的b64encode()在空格容忍度上的差异，以及PIL加载时对EXIF元数据的静默丢弃——这些细节不报错，但会让图片显示异常或丢失信息。
