Linux版Navicat无法识别Windows导出的.ncx文件，根本原因是跨平台加密结构不兼容与BOM/CRLF元数据污染；ncx实为含AES加密段的二进制容器，Windows与Linux密钥派生逻辑不同，且BOM会被误判为非法加密头导致解析失败。
Linux版Navicat无法识别Windows导出的.ncx文件，根本原因是跨平台加密结构不兼容 + 文件元数据污染，不是简单改后缀或复制就能解决的。
ncx文件本质不是纯文本配置
很多人误以为Connections.ncx是XML或JSON这类可读格式，实际上它是Navicat内部加密序列化的二进制容器（v15+含AES加密段）。Windows和Linux版使用不同密钥派生逻辑与初始化向量，即使主版本号一致（如16.2 → 16.3），只要底层构建环境（OpenSSL版本、glibc版本、Qt编译链）有差异，解密就会失败。
常见错误现象包括：Invalid connection file、导入后连接列表为空、双击连接无响应但无报错。
- v15导出的
.ncx不包含密码字段，导入Linux版后必须重输所有密码 - v16+导出时必须手动勾选
Include password并设置临时主密码（如temp123），否则SSH/数据库密码全丢失 - v17无法解析v16导出的
.ncx——官方明确不提供向下/向上转换工具
Windows编码痕迹会直接破坏Linux端解析
Windows记事本/PowerShell导出的.ncx默认带UTF-8 BOM头和CRLF换行符，而Linux版Navicat在加载时对BOM极其敏感：它会把BOM字节当作非法加密头的一部分，导致整个文件被判定为损坏；CRLF则可能让某些字段长度计算偏移，引发截断或乱码（比如中文连接名变成方块）。
实操建议：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 用VS Code打开
.ncx→ 右下角点击编码 →Save with Encoding→ 选UTF-8 (no BOM) - 右下角点击换行符 → 改为
LF→ 保存 - macOS用户额外执行：
xattr -d com.apple.quarantine ~/Library/Application\ Support/PremiumSoft/Navicat/Connections.ncx
SSH路径与代理配置必然失效
.ncx里存的是绝对路径，Windows的C:\Users\Alice\.ssh\id_rsa在Linux上根本不存在；HTTP/SOCKS代理设置也只记录原始字符串，不会做路径映射或环境变量展开。
导入后必须逐个修复：
- 打开每个连接 → 切到
SSH选项卡 → 手动指定Linux私钥路径（如/home/alice/.ssh/id_rsa） - 检查
SSH 用户名和SSH 密码字段——即使设置了主密码，这两项也不自动填充 - 代理需对照原截图或记忆重填；
Options.xml中的代理配置完全不随.ncx迁移
locale与MySQL字符集必须双重对齐
即使.ncx文件本身干净，Linux终端locale未设UTF-8也会让Navicat初始化失败。它依赖系统LANG解码配置，但连接MySQL时又只认自身SQL命令。
关键操作缺一不可：
- 终端执行：
locale | grep UTF-8确认输出含UTF-8；若无，临时运行：export LANG=en_US.UTF-8 - Navicat连接属性 →
高级页 → 勾选Use Unicode UTF-8→Initial command框填：SET NAMES utf8mb4
最常被忽略的是：这个SET NAMES必须写在Initial command里，而不是靠MySQL服务端my.cnf全局设置——Navicat建立连接时根本不读那个文件。
