PGP加密XML上传无特殊限制，但解密必须在接收方完成；上传前须确认目标系统已导入公钥、上传的是.gpg/.asc密文文件、上传通道支持二进制；Linux批量解密需用--batch避免交互；Java解密常见陷阱包括输入流未重置、密钥环加载失败及字符集未指定。
PGP 加密的 XML 文件上传本身没有特殊限制，但解密环节必须在接收方环境里完成——上传过程只是传输密文，真正的安全边界在解密那一刻才被检验。
上传前必须确认的三件事
很多团队卡在“文件传上去了却解不开”，问题往往出在上传前没验证基础条件：
- 目标系统是否已导入你的
公钥？否则对方无法用你的公钥加密 XML，也就不存在“你上传后自己解密”的逻辑（你只有私钥，不能解别人用你公钥加密的内容） - 你上传的是
.gpg或.asc后缀的密文文件，不是原始 XML；若误传明文 XML，后续所有解密动作都无意义 - 上传通道（如 SFTP、API 接口、Web 表单）是否支持二进制文件？某些老旧 HTTP 上传接口会自动转码或截断，导致
gpg --decrypt报错invalid packet或no valid OpenPGP data found
Linux 下用 gpg 批量解密 XML 文件的可靠写法
手动输入密码不可用于自动化流程，但直接硬编码密码又违反安全规范。折中方案是使用 gpg-preset-passphrase + 环境隔离，或改用 --batch --passphrase-fd 0 配合管道（仅限测试环境）：
echo "my_secret_passphrase" | gpg --batch --quiet --passphrase-fd 0 \ --output report.xml --decrypt report.xml.gpg
注意：--batch 是关键，否则遇到交互提示（如密钥信任警告）会卡住；--quiet 可减少日志干扰。生产环境强烈建议用 gpg-agent 缓存解锁后的私钥，而非传参式密码。
Java 用 Bouncy Castle 解密 PGP XML 的典型陷阱
常见报错 org.bouncycastle.openpgp.PGPException: Unknown object in stream，基本都源于两个细节：
- 输入流未重置：如果从
HttpServletRequest.getInputStream()读取后又想复用，必须先reset()，否则流已耗尽 - 密钥环加载错误：调用
PGPSecretKeyRingCollection时传入的是InputStream，但该流已被其他代码提前读过（比如日志组件打印了原始请求体），结果集合为空 - XML 内容含非 ASCII 字符却未指定字符集：解密后得到的字节数组需明确用
new String(decryptedBytes, StandardCharsets.UTF_8)转换，否则中文变乱码，看起来像“解密失败”
真正棘手的从来不是“怎么解”，而是“谁在什么时候以什么权限解”。比如 Web 服务收到加密 XML 后，是交由后台 worker 进程解密，还是在主线程同步解？前者需确保 worker 机器上已导入对应私钥且 gpg --list-secret-keys 可见；后者若用 Java 实现，则 Bouncy Castle 的 PGPSecretKey 必须从文件或数据库加载，不能硬编码在 classpath 里——这些决策点，比命令行多敲一个参数影响大得多。
