Navicat 17 不支持导出 SQL 文件的任何加密功能，导出内容均为明文；其转储逻辑为读取→拼装SQL→写入磁盘，无加密环节或配置项，需借助外部工具（如7z、gpg）或脚本实现加密或脱敏。
Navicat 17 不支持对导出的 SQL 文件进行加密（如 AES 加密、密码保护或混淆），它没有“加密转储”选项，也不提供任何内置的文件级加密机制。你右键数据库选择“转储SQL文件”，或使用“导出向导”生成 .sql 文件，最终输出的始终是明文文本——哪怕源数据库本身启用了加密（如 SQLite 的 SEE 或 SQLCipher），导出过程也会先解密再写入纯 SQL。
导出时无法启用加密，但可手动加壳
Navicat 的导出逻辑是：读取数据库内容 → 拼装标准 SQL 语句 → 写入磁盘。整个流程不经过加密环节，也无 API 或配置项可干预。常见误解包括：
- 误以为勾选“高级”里的“压缩”等于加密（实际只是 ZIP 压缩，无密码）
- 误以为“备份数据库”功能含加密（该功能针对 SQLite 是二进制拷贝，但不加密；对 MySQL/PostgreSQL 则调用 mysqldump/pg_dump，本身也不加密）
- 试图在“格式设置”页找到密码输入框（不存在）
如果你需要交付带访问控制的 SQL 文件，必须在 Navicat 导出后额外处理：
使用系统级工具加密：
7z a -p -mhe=on backup.sql.7z backup.sql（需用户输入密码解压）gpg --symmetric --cipher-algo AES256 backup.sql（生成backup.sql.gpg）用脚本自动混淆敏感字段（如手机号、邮箱）：
可用 Python +re.sub()替换INSERT INTO user VALUES (..., '138****1234', ...)，但注意这会破坏数据可恢复性若目标是防止导入时被随意执行，可在 SQL 文件开头加注释警告：
-- ⚠️ 此文件含生产数据，请仅在授权环境导入
SQLite 场景下尤其要注意类型与语法陷阱
SQLite 数据库若本身用了 SQLCipher，Navicat 17 无法直连并导出其内容——它不支持 SQLCipher 协议。你看到的“连接成功”，大概率是 Navicat 把密文当普通 SQLite 文件打开，然后导出一堆乱码或报错 file is encrypted or is not a database。此时唯一可行路径是：
- 先用
sqlcipherCLI 工具解密：sqlcipher plain.db→ 输入密码 →.output decrypted.db→.dump→ 保存为 SQL - 再用 Navicat 连接
decrypted.db，走常规“转储SQL文件”流程
导出后验证是否真“安全”
别只看文件扩展名或是否压缩。打开生成的 .sql 文件，搜索以下内容确认风险点：
- 是否存在明文
INSERT INTO user (password) VALUES ('$2b$12$...')（bcrypt 哈希还算可控） - 是否有
INSERT INTO config (api_key) VALUES ('sk<em>live</em>...')（硬编码密钥必须删） - 是否含
CREATE TABLE credit_card (... card_number TEXT ...)（PCI 合规要求脱敏）
真正需要加密的不是“转储文件本身”，而是传输渠道和存储位置。用 scp 替代邮件发送，存到受控的 NAS 而非共享网盘，比给 SQL 文件加个密码更有效。
Navicat 17 的导出能力边界很清晰：它负责结构化还原，不负责数据治理。加密这件事，得交还给操作系统、归档工具或自定义脚本来兜底。
