navicat加密的sqlite数据库需用支持sqlcipher的jdbc驱动（如io.github.willena:sqlite-jdbc-crypt），并以pbkdf2派生的十六进制密钥（如mysecret123→6d79736563726574313233）配合jdbc:sqlite:db.db?cipher=sqlcipher&key=...url连接，否则报密码错误。
Navicat 加密的 SQLite 数据库不能用标准 sqlite-jdbc 驱动连接，直接报密码错误（比如 file is encrypted or is not a database 或 not an sqlite3 database）——这不是你输错了密码，而是驱动根本不识别 Navicat 用的 SQLCipher 加密格式。
确认 Navicat 确实用了 SQLCipher 加密
Navicat 对 SQLite 的加密只有一种方式：SQLCipher AES-256。它不会用自定义算法，但关键点在于：你必须知道原始设置时输入的明文密码，并把它转成十六进制密钥（hex key），而不是直接传字符串。
- 如果你在 Navicat 中设置加密时填的是
mysecret123，那 Java 连接时不能直接用这个字符串 - SQLCipher 要求密钥是 hex 格式（如
6d79736563726574313233），长度通常为 64 字符（32 字节） - Navicat 内部会把明文密码用 PBKDF2 派生出密钥，但对外暴露的“密码”字段就是你要还原的原始明文
换用支持 SQLCipher 的 JDBC 驱动
标准 org.xerial:sqlite-jdbc 完全不支持加密，必须换成明确兼容 SQLCipher 的实现：
- 推荐用
io.github.willena:sqlite-jdbc-crypt（Maven 坐标），注意版本要匹配你的 SQLite 和 SQLCipher 版本（例如0.8.0对应 SQLCipher 4.x） - 不要用网上搜到的“patch 版 sqlite-jdbc”，它们往往过时或不兼容最新 SQLCipher 密钥派生逻辑
- 驱动类名仍是
org.sqlite.JDBC，但底层已重写加密握手流程
添加依赖示例：
<dependency><groupid>io.github.willena</groupid><artifactid>sqlite-jdbc-crypt</artifactid><version>0.8.0</version></dependency>
JDBC URL 必须带 cipher 和 key 参数
URL 格式不对是密码错误的最常见原因。必须显式声明 cipher 类型和 hex 密钥：
- 正确写法：
jdbc:sqlite:/path/to/db.db?cipher=sqlcipher&key=6d79736563726574313233 -
cipher=sqlcipher不可省略，否则驱动按普通 SQLite 打开文件 -
key=后面必须是小写 hex 字符串，长度为偶数（建议 64 字符），不能带0x或引号 - 如果原始密码是中文或含特殊字符，需先 UTF-8 编码再 hex（可用 Python
password.encode().hex()快速生成）
容易被忽略的两个硬性限制
即使以上都做对了，仍可能失败，因为 SQLCipher 本身有强制约束：
- Navicat 加密的数据库文件头固定为
SQLite format 3+ SQLCipher magic bytes，如果用非 SQLCipher 工具（如 DB Browser for SQLite）误操作保存过，头部会被破坏，此时任何驱动都打不开 - Java 进程启动时若没加载 native 库（
libsqlcipher.so/sqlcipher.dll），会静默降级为普通 SQLite 模式，导致“密码错误”假象——检查日志里是否有couldn't load sqlcipher native library
