如何上传文件名加解密脚本

上周三凌晨两点，何上老张在群里发了条消息：“谁有那个批量改文件名的传文脚本？我手动改了三百个，眼快瞎了。名加解”配图是密脚资源管理器里密密麻麻的缩略图。这事我太熟了——去年做数据标注时，何上一万多张图片要按“日期_序号_标注员”的传文格式重命名，纯手动操作等于自残。名加解后来写了个Python脚本，密脚顺手加了AES加密，何上文件丢网盘也不怕被人扒。传文

脚本本身不复杂，名加解核心就两步：用os.rename()或pathlib处理文件名，密脚再用cryptography库做加解密。何上但上传到服务器时踩了坑——第一次传完发现脚本里的传文密钥是明文硬编码，等于把家门钥匙插在锁上。名加解改成本地读取.env文件后，又遇到权限问题：上传目录的chmod设成777，结果被扫描到漏洞。最后用paramiko走SFTP，配合ssh-keygen生成的密钥对，才算把传输环节锁死。

上传前先过三遍筛子

第一遍查依赖。脚本里import了cryptography和tqdm，服务器上没装tqdm，跑起来直接报ModuleNotFoundError。用pipreqs生成requirements.txt，再pip install -r，比手动一个个装靠谱。

第二遍看路径。本地测试时文件名带中文没问题，上传到Linux服务器后os.rename直接乱码。加# -*- coding: utf-8 -*-没用，得在脚本开头写import sys; sys.setdefaultencoding('utf-8')——Python 3其实默认就是utf-8，但服务器locale设成了POSIX，还是得用locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')兜底。

第三遍试加密。AES的Fernet模式要求密钥是32位url-safe base64编码，我图省事用os.urandom(32)生成后直接base64.urlsafe_b64encode()，结果解密时总提示InvalidToken。后来发现是Fernet对时间戳有校验，加密解密间隔超过60秒就失效。改成AES.MODE_GCM模式，自己管理nonce和tag，才稳定下来。

传输通道别用裸HTTP

有次图快，直接用requests.post把脚本传到临时文件服务器。第二天收到安全告警：脚本里的测试密钥被爬虫扫到了。后来改用scp加-i指定私钥，再套一层ssh -L端口转发。如果非要用HTTP，至少得上HTTPS+Bearer Token，token还得设成十分钟过期。

实际部署时我习惯分三块传：脚本主体、配置文件、密钥文件。密钥文件单独走gpg --encrypt加密，解密口令通过Signal发给运维。有次偷懒把密钥和脚本打包成zip传，结果zip的-P密码被暴力破解工具秒破——那密码是123456，活该。

验证环节别省

传完先跑python -m py_compile rename_encrypt.py查语法，再用md5sum对比本地和服务器上的文件哈希。有回哈希对不上，查了半天发现是vim自动在末尾加了换行符。最后写了个deploy.sh，把校验、备份、回滚全串起来：先cp旧版本到.bak，再rsync新文件，跑python -c "import rename_encrypt"确认能导入，最后systemctl restart服务。

现在老张的脚本跑在阿里云1核1G的轻量服务器上，每天凌晨三点自动扫描/data/incoming目录，把文件名里的空格换成下划线，再用AES-256加密成.enc后缀。上周他跟我说：“终于不用半夜爬起来改文件名了。”我回他：“下次记得把密钥存在~/.ssh里，别放桌面。”

本文地址：http://www.79wt.cn/news/1022a1699881.html