简介：面向 ArchLinux 用户的 Navicat Premium 15 安装与激活备份包，内容为已被删除的 navicat-keygen 工具源码及其配套文档，适合需要重新编译、回顾补丁思路或研究其授权机制的 Linux 开发者。压缩包共包含 41 个文件，以 C++ 头文件与源文件为主：21 个 hpp 负责接口与数据结构声明，11 个 cpp 实现具体逻辑，另有 Makefile、LICENSE、.gitignore 及 6 篇 Markdown 说明，整体体积仅 71KB，结构紧凑，便于离线查阅或按需提取。源码按 navicat-keygen 与 navicat-patcher 两个方向组织，覆盖序列号生成、授权文件生成、补丁加载入口、Keystone/Capstone 汇编与反汇编封装、ELF 可执行文件解析、RSA 加密等底层模块；中文与英文双语文档分别解释了工作原理和构建方法，方便读者从零编译或在离线环境下核对关键步骤。目前已有 699 人学习下载，对于具备 C++ 基础、想深入拆解 Navicat 15 激活链路的开发者而言，这是一份难得的高密度参考源码，既可作为应急备份，也可用于学习授权软件常见校验思路。
1. 在 ArchLinux 上装 Navicat Premium 15，真正卡人的是激活和误删
Navicat Premium 15 在 Linux 下的安装本身不难：官方和社区都提供过 tar.gz 封装，ArchLinux 用解压就能跑。真正让工程师反复折腾的是另外两件事——一是激活信息写进了用户配置目录，升级、清理或换机器后就失效；二是很多人把配置文件、备份文件混放在同一个目录里，一次rm -rf误删，连 Navicat 导出的.sql、.pscf备份也一起没了。这篇文章按“环境准备 → 激活与许可迁移 → 误删恢复 → 自动兜底快照”的顺序，把 Navicat_Premium_15_linux 安装与激活在 ArchLinux 上的完整路径写透，最后给出一个不依赖第三方网盘的备份防删除方案。
2. 安装前先把运行环境理顺：原生包还是 Wine 跑 Navicat 15
2.1 先分清两种安装形态，再决定要不要 Wine
Navicat Premium 15 官方发布过 Linux 原生版本，解压后是一个navicat15-premium-cs.AppImage或navicat15-premium的 ELF 可执行文件。这类原生包在 Ubuntu 上没问题，到了 ArchLinux 上最常见的坑是动态库缺失，因为 Arch 的 glibc、libssl 和 libicu 版本都偏新，Navicat 15 打包年代较老，可能出现libicuuc.so.XX、libcrypto.so.1.0.0找不到的情况。
另一种更省心的手段是在统一稳定版本上装 Wine，把 Navicat 当 Windows 程序跑。Wine 方式的好处是绕过 Linux 原生包那些旧 ABI 兼容问题，缺点是激活路径会从~/.config/navicat挪到 wineprefix 的AppData\Roaming下。下文两种方案都会给，先检查原生包依赖，缺哪补哪。
file navicat15-premium-cs.AppImage ./navicat15-premium-cs.AppImage --appimage-extract cd squashfs-root ldd ./navicat15-premium | grep "not found"输出里看到not found库时，就到官方仓库找对应的旧版本兼容库补上。常见做法是sudo pacman -S lib32-icu icu这类包名调整，但不要盲目装 AUR 里名字相似的包，先确认缺的是 32 位还是 64 位库。如果缺libssl，检查系统里是否被openssl-1.0覆盖，Arch 默认openssl是 3.x，Navicat 15 很可能要openssl-1.0。
2.2 Wine prefix 初始化与 winetricks 运行库安装
如果选择 Wine，我一般会给 Navicat 单独建一个独立 prefix，避免污染常用 Wine 环境，也方便将来整体备份激活状态。
export WINEPREFIX="$HOME/.wine-navicat16" export WINEARCH=win64 wineboot -u winecfg -v win10参数说明：WINEARCH=win64强制 64 位 prefix，winecfg -v win10告诉 Wine 模拟 Windows 10 环境。Navicat 15 在 win7 和 win10 下都能跑，但win10对后续 msstyle 主题和 msvcp 库的处理更稳。初始化完确认 wine 版本，wine --version不低于 7.0 时，装 mfc42、msvcp140、riched20 这三个库基本够用：
winetricks -q mfc42 msvcp140 riched20其中mfc42提供 MFC 类库，Navicat 的界面框架依赖它；msvcp140是 Visual C++ 运行库，直接关系到导入导出向导是否闪退；riched20负责编辑器控件，缺失时 SQL 编辑器里中文输入可能无法显示候选词。把这些库装好，再安装 Navicat 15 的 Windows 版安装包，一路默认路径即可。
2.3 解压乱码与字体问题的处理
ArchLinux 安装 Navicat 15 时遇到的“中文乱码”多半有两类。第一类是 tar.gz 包里的文件名带了 GBK 编码，解压出来是乱码，这时不要急着改系统 locale，先用lsar和unar这类工具按原编码解压。
lsar -l navicat15_premium_x86.tar.gz unar -e gbk navicat15_premium_x86.tar.gzlsar只列出文件清单，-l能看到文件名的原始编码元数据；确定源编码是gbk后用unar -e gbk解压，避免中途encoding不对导致整个解压流程失败。第二类是 Navicat 窗口里中文显示成方块，一般发生在 Wine 环境。补上中文字体再生成字体缓存：
sudo pacman -S wqy-microhei wqy-zenhei fc-cache -fvWine 通过 fontconfig 读取字体，fc-cache刷新缓存后，重启 Navicat 即可正常显示。如果用的是 ArchLinux 与 fcitx5 wayland 输入法组合，需要在 wine 客户端启动前设置输入法环境变量，否则 SQL 编辑器里无法切换中文输入。
export XMODIFIERS=@im=fcitx export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx这三行在终端启动 Navicat 前执行即可，不写入全局 profile，避免影响其他 Wine 程序。
2.4 Linux 原生包还是 Wine 的选择归档表
| 判断条件 | Linux 原生包 | Wine 方式 |
|---|---|---|
| 依赖干净度 | 要求系统有旧版 libicu/openssl | 只依赖 Wine 库 |
| 激活配置目录 | ~/.config/navicat/Premium/ | $WINEPREFIX/.../AppData/Roaming/PremiumSoft CyberTech/ |
| 数据库连接稳定性 | 直接走本机 Unix socket | 走 TCP，需要确认防火墙 |
| 备份恢复兼容性 | 高 | 高，因为导出格式相同 |
| 中文输入法 | 原生支持较好 | 必须设 fcitx 环境变量 |
选择建议：如果你是跑在开发机上，日常只连 MySQL、PostgreSQL，原生包更轻；如果你有多个迁移场景，比如把整套 Navicat 从 Windows 换到 Linux，Wine 方式能直接复用原有的激活配置目录结构，后面第三部分讲激活迁移时会更省事。
3. 激活的本质是许可文件迁移：Navicat Premium 15 在 ArchLinux 里的配置位置
3.1 先搞清激活信息存在哪，再谈备份
Navicat 15 的激活流程不是只往安装目录里写文件。它把序列号、机器指纹、试用期状态都固化在用户配置目录里。Wine 版和 Linux 原生版路径不同，确切的共同特征是目录名带PremiumSoft或navicat。
Linux 原生版常见路径：
~/.config/navicat/Premium/Wine 版常见路径：
$WINEPREFIX/drive_c/users/$USER/AppData/Roaming/PremiumSoft CyberTech/这两个路径下列出了preferences、licenses、Navicat子目录和以.dat结尾的本地缓存文件。激活时输入官方注册码后，程序会把授权状态写入这里的licenses目录。很多人以为“激活”只在安装时发生一次，实际上每次启动 Navicat 时它都会重新读这些文件，只要这些文件被删除或改坏，就会出现“试用期已结束”或“激活码失效”的提示。
3.2 官方激活码的输入与命令行验证
在 Navicat 15 里输入激活码的路径是帮助 → 注册。填写序列号和激活码后，保存成功会有提示。为了确认激活确实写进了 ArchLinux 的配置目录，可以用 grep 直接检查。
grep -r "SerialNo" "$HOME/.config/navicat/Premium/" grep -r "ActivationStatus" "$WINEPREFIX/drive_c/users/$USER/AppData/Roaming/PremiumSoft CyberTech/"第一行针对原生包，第二行针对 Wine。如果输出了形如ActivationStatus: 1的内容，说明激活状态已经落盘。如果没有任何输出，大概率是注册码没有写成功，需要回到 Navicat 里重新输入。这里强调一个注意事项：不要在~/.config/navicat里手动改SerialNo字段，Navicat 对激活文件有校验，手工改会触发重新激活。
3.3 可迁移的许可备份清单与恢复步骤
在 ArchLinux 上重装系统或切换 Wine prefix 前，先把整个配置目录打包。这一步的价值大于安装包本身的备份，很多用户重装后找不到激活码，就是因为只备份了安装包，没备份这个目录。
tar -czf navicat-premium-backup.tar.gz \ "$HOME/.config/navicat/Premium/"Wine 版本则把对应目录打进去：
cd "$HOME/.wine-navicat16/drive_c/users/$USER/AppData/Roaming" tar -czf "$HOME/navicat-lic.tar.gz" "PremiumSoft CyberTech"tar打包时会保留原有的属主和权限位，-c创建归档，-z用 gzip 压缩，-f指定输出文件。恢复时只要把归档解开到原路径，不用重新输入激活码。注意不要在归档时省略PremiumSoft CyberTech路径里带空格的引号，否则 tar 会把目录拆成两个文件参数。
恢复到新机器后验证激活是否生效，启动 Navicat 看“关于”页面；也可以直接对比注册表中对应的指纹值：Wine 环境可以用wine reg query查 Windows 注册表项，原生 Linux 版没有注册表，只能看配置文件。
wine reg query "HKCU\Software\PremiumSoft\Navicat Premium 15" /v SerialNo如果命令返回空，说明当前 prefix 下根本没有 Navicat 的注册表痕迹；这通常发生在用wine命令行但没指定WINEPREFIX的场景。检查一下环境变量是否真的带上了。
3.4 激活后崩溃时的排查手段
我先给一个非常常见的失败样例：升级 Wine 后 Navicat 能打开，但提示激活失效。这不是激活码被注销，而是 Wine prefix 版本变化导致配置目录的同步锁文件被标记为失效。排查办法是先备份配置，再删除该目录下的.lock结尾文件：
find "$WINEPREFIX/drive_c/users/$USER/AppData/Roaming/PremiumSoft CyberTech" -name "*.lock" -deletefind的-name "*.lock"精确匹配锁文件，-delete逐个删除。删除后重启 Navicat，它会重新生成锁文件，同时保留原有的激活信息。如果依然提示失效，就把之前的归档恢复回来，不要直接重新注册——重新注册可能产生新的机器指纹，而旧备份里的指纹绑定的是之前的环境。
4. 备份被删除之后的抢救逻辑：在 ext4 与 btrfs 上找回 .sql
4.1 误删后按顺序做的四件事
假设你在 ArchLinux 的~/Documents下误删了 Navicat 导出的sales_report.sql。第一反应不是安装恢复工具，而是要停止对目标分区的一切写操作。rm删除文件后，目录项被移除，但 inode 和数据块在磁盘上往往还有残留，只要没有新的写入覆盖这些块，恢复的成功率就很高。
按顺序执行：
lsof +L1查找被删除但仍被进程打开的句柄- 如果 Navicat 或 mysqld 还开着，立刻把句柄对应的内容复制出来
- 对目标分区执行
mount -o remount,ro或直接卸载 - 再运行第三方恢复工具
第一步的操作：
lsof +L1 | grep sales_report+L1表示列出 link count 小于 1 的文件，也就是被删除但仍有进程引用的文件。如果输出显示某个 PID 持有该文件，且状态是deleted，可以用进程的 fd 号直接恢复：
cp /proc/1234/fd/17 /home/user/recovered.sql/proc/1234/fd/17里的 1234 是进程 PID，17 是文件描述符编号。这种恢复方式不需要任何磁盘头恢复工具，因为没有真正释放数据块。Navicat 在导出过程中有时会把.sql临时写入自己的程序目录而非导出目标目录，所以lsof搜索时要带上进程名过滤。
4.2 ext4 文件系统下用 extundelete 找回来
如果分区是 ext4，最常用的命令是extundelete。在 ArchLinux 上安装：
sudo pacman -S extundelete sudo mount -o remount,ro /dev/sda2 sudo extundelete /dev/sda2 --restore-file Documents/sales_report.sql--restore-file后面路径必须是分区挂载点内的相对路径，不能写绝对路径。默认恢复结果会写到当前目录下的RECOVERED_FILES目录里。如果--restore-file没找到文件，可能是 inode 已经被复用，改用--restore-inode：
sudo extundelete /dev/sda2 --restore-inode 123456先查 inode：
sudo debugfs -R "lsdel" /dev/sda2lsdel会把 ext4 中已删除但未被清零的 inode 列出来，输出了两列，一个是 inode 编号，一个是删除时间。找到对应时间点的记录，再用--restore-inode恢复。这条链路的适用条件是分区在删除后没有大量写过数据，并且文件原本不是位于一个已有创建历史的新文件里。
4.3 btrfs、xfs 和 SSD 下的恢复边界
如果/home 是 btrfs，并且开了快照，恢复要比 ext4 简单得多。直接用btrfs subvolume list找之前快照：
sudo btrfs subvolume list /home sudo btrfs subvolume snapshot -r /home /home/.snapshots/restore-pointsanpshot命令不会丢数据，因为 btrfs 的 CoW 机制天然支持从旧快照里拷贝文件。如果没开快照，btrfs restore也能扫磁盘里的有效树结构，但效果不稳定，因为 btrfs 删除文件时会把元数据树同步清理。
xfs 的情况比较尴尬，官方没有像 extundelete 那样的工具，通常只能用xfs_undelete这类社区程序，且要指定文件尺寸区段，成功率很低。如果是 NVMe SSD，还要考虑 TRIM 隐性风险：现代fstrim会在后台跑，TRIM 会把已删除的数据块清零，恢复工具再强也无济于事。所以在执行恢复前先检查挂载参数：
sudo findmnt -no OPTIONS /home输出里看到discard就说明挂在自动 TRIM，误删之后赶紧关掉或 remount —— 虽然已经晚一点，但至少阻止后续 TRIM 继续扩大范围。
4.4 testdisk 找回已经被删的整个备份目录
Navicat 备份很多时候不止一个.sql，而是一整个Navicat Backups目录。用 testdisk 按目录树恢复更高效。安装运行：
sudo pacman -S testdisk sudo testdisk /dev/sda交互界面里选择[Intel]分区类型，再选分区后进入[Advanced] Filesystem Utils，使用[Undelete]进入目录搜索。testdisk 适合恢复被删目录，因为它在未分配空间里扫描 MFT 和 ext 目录项时，能找到一批 link count 为 0 的文件，并把文件连同相对路径一起导出。
需要注意的是 testdisk 的Undelete过程会把恢复文件写到用户指定的另一个分区，所以不要在当前被删文件所在分区里建恢复目录。我在 ArchLinux 上做恢复时的习惯是挂一个移动硬盘专门做写入目标，既避免二次写入覆盖，也简化参数。
5. 给 Navicat 备份目录加自动快照：inotify + systemd path 的兜底方案
与其等误删后花一个小时扫磁盘，不如让备份目录一到新文件就自动生成快照。ArchLinux 上最常见、最轻量的做法是把inotifywait和 systemd path 单元组合起来，听上去复杂，实际上只需要两个文件。
先确认安装了inotify-tools：
sudo pacman -S inotify-tools然后写一个快照脚本，存放在/usr/local/bin/navicat-autosnap.sh：
#!/bin/bash SNAP_DIR="$HOME/snapshots/navicat" TARGET_DIR="$HOME/Documents/NavicatBackups" mkdir -p "$SNAP_DIR" SNAP_NAME="navicat-$(date +%Y%m%d-%H%M%S)" cp -al "$TARGET_DIR" "$SNAP_DIR/$SNAP_NAME" find "$SNAP_DIR" -maxdepth 1 -name "navicat-*" -ctime +7 -exec rm -rf {} \;脚本核心是cp -al，它创建的是硬链接集合，不复制数据块，只复制目录项。这样可以秒级生成一个看起来完整的备份目录，磁盘占用几乎为零。只有当原文件被删除时，硬链接里的旧内容才真正保留下来，达到“防 rm 误删”的效果。find后面的-exec rm -rf做 7 天滚动清理，避免快照无限增长。
接着创建.path单元，让 systemd 专门监视Documents/NavicatBackups目录：
# /etc/systemd/system/navicat-backup.path [Unit] Description=Watch Navicat backup dir [Path] PathModified=/home/YOUR_USER/Documents/NavicatBackups [Install] WantedBy=default.targetPathModified会在目录被修改时触发，而不是启动时全量触发。再配置对应的 service 单元执行上述脚本：
# /etc/systemd/system/navicat-backup.service [Unit] Description=Snapshot Navicat backups [Service] ExecStart=/usr/local/bin/navicat-autosnap.sh启用和启动：
sudo systemctl enable --now navicat-backup.path启用后，只要 Navicat 往这个目录写入导出文件，systemd 就会在一个极短延迟内调用脚本生成硬链接快照。验证方法比较直接：
systemctl status navicat-backup.path ls -l "$HOME/snapshots/navicat"看到navicat-2025xxxx目录后，再故意删掉Documents/NavicatBackups/下的一个文件，快照目录里的旧文件依然可读。这个思路比依赖 btrfs snapshot 更通用，因为cp -al在 ext4/xfs 上都有效。后续若想升级，可以在脚本里把cp -al换成rclone copy --backup-dir，但初版不需要，简单、可靠、能跑就够了。
本文还有配套的精品资源，点击获取
