Navicat ≥ v15 导出 XML 时 Password 字段默认为空或缺失，是官方刻意设计的安全机制，并非 bug 或导出失败；该设计确保 XML 文件不携带可解密密文，防止离线批量还原密码，必须通过 GUI 或 CLI 显式导出，且导入时须走“文件→导入连接”路径并处理 BOM 编码问题。
导出 XML 时密码字段为空，不是 bug 是设计
navicat ≥ v15 导出为 xml 格式时，password 字段默认缺失或为空（如 <password></password>），这是官方刻意为之的安全机制，不是导出失败或配置错误。它意味着：你拿到的 xml 文件本身不携带可解密的密文，也就无法被离线批量还原成明文密码。
常见错误现象：导出后打开 XML，发现 Password 标签里什么都没有，误以为“导出没成功”；或者用旧脚本强行注入密文再导入，结果 Navicat 拒绝加载或静默忽略该字段。
- 必须通过 GUI 或 CLI 显式触发导出动作：
navicat --export-connections --format=xml --output=cons.xml（v17+ 内置） - Windows 下若导入时中文连接名乱码，大概率是 XML 含 UTF-8 BOM；用 VS Code 打开 → 右下角编码 → Save with Encoding → UTF-8 (no BOM)
- 导入路径只能是：
文件 → 导入连接 → 选择 XML 文件；双击或拖入会当作普通文本处理，不触发连接解析逻辑
为什么直接复制 connections.ncx 等同于交出数据库钥匙
connections.ncx 看似是加密文件，实则是设备绑定的密文容器。它依赖当前机器的硬件特征（Windows 的 DPAPI、macOS 的 Secure Enclave）或本地密钥环解密，跨设备打开时 Navicat 不报错，只表现为连接列表空白或加载无响应——你根本不知道密码已被丢弃。
更危险的是：Navicat 12–14 版本使用硬编码 AES 密钥 "libcckeylibcckey" 和固定 IV "libcciv libcciv "，只要拿到 .ncx 文件，就能用公开算法批量解密所有密码；网上流传的 Python 解密脚本在 v15+ 失效，不是代码错了，而是密钥派生环节少了 TPM/Secure Enclave 输出，但 v12–14 的文件仍可被轻松破解。
- 绝对不要通过微信、邮件、网盘传输
connections.ncx文件 - 不要用管理员权限导出该文件试图“提取密钥”——密钥根本不在文件里，而在设备底层
- 团队交接时若收到他人发来的
.ncx，应立即丢弃并要求对方重导 XML
XML 导入后补录密码的三种方式，安全等级差异极大
XML 中密码为空，不代表不能自动化；但自动化方式直接影响风险敞口。人工补录最安全，环境变量注入次之，硬编码密文最危险。
- 人工补录：导入 XML 后双击连接 → 弹出对话框手动输入密码。全程不落盘、不进日志、不进 Git，适合生产环境或高敏系统
-
环境变量注入（CLI 场景）：用自定义脚本读取独立存储的
connections.json（由exportConnections工具生成），拼接 XML 模板；但 Navicat 仍拒绝加载含密码的 XML，最终一步仍需人工触发连接 —— 这只是减少键盘输入，不改变密码暴露面 -
禁止行为：编辑 XML 直接写入明文或密文密码（如
<password>myPass123</password>或<password>U2FsdGVkX1+...</password>），Navicat 会忽略该字段，且该文件一旦泄露即等于明文泄露
真正可控的共享流程只有三步，缺一不可
安全共享不是选“哪种格式”，而是控制整个链路：从导出源头到落地执行，每一步都有明确技术约束。
- 导出端必须用 GUI 或 CLI 显式导出 XML，并确认勾选了
Export Password（注意：这个选项控制的是是否把加密密文写入 XML，但 v15+ 默认仍不写；实际起作用的是“导出为 XML”这个动作本身） - 传输过程必须走加密通道（如企业 IM 的端到端加密、SFTP），且接收方下载后立即校验文件哈希（
shasum -a 256 cons.xml） - 导入端必须用 Navicat 原生导入功能，且导入后第一时间检查连接是否能正常测试（避免因 BOM 或编码问题导致连接名异常而误判成功）
容易被忽略的点：macOS 上 GUI 导出的 XML 默认带 UTF-8 BOM，Windows 导入会失败；而 CLI 导出（navicat --export-connections）默认无 BOM，跨平台兼容性更好。别让一个字节的 BOM 让整套安全流程失效。
