技术复盘 · LINUX 桌面应用交付

WPS Office Linux AppImage

打包、依赖封装与文件关联指南

从官方 RPM 到 Nautilus 右键打开方式：一次完整的可移植桌面应用交付

目录

本指南按“原理 → 构建 → 安装 → 文件关联 → 验证与排障”的顺序组织，可直接作为后续重新构建或迁移到其他 Linux 机器的操作底稿。

01 | 摘要与最终交付

这次工作的目标不是简单地把 WPS 二进制塞进一个压缩包，而是交付一个能在目标机器上稳定启动、能打开文档、能被桌面文件管理器识别的 Linux 应用包。最终采用的路线是：以 WPS 官方 RPM 为内容源，组装标准 AppDir，把 WPS 自带资源、官方启动脚本和外部共享库一起放入 AppImage，再通过 AppRun 完成重定位。

最终结果

·官方 WPS Office 12.1.2.29183 x86_64 RPM 被转换为单个 AppImage。

·AppDir 解包后约 2.1 GB，最终 AppImage 约 806 MB，使用 Type 2 Runtime 和 zstd 压缩。

·扫描 529 个 ELF 文件，最终打包 114 个外部用户态共享库，覆盖 Qt、X11、字体、OpenGL、GTK、ICU、XML、图像、音频等。

·远端安装路径为 /home/tony/.application/WPS-Office.AppImage。

·wps 命令链接为 /home/tony/.local/bin/wps -> /home/tony/.application/WPS-Office.AppImage。

·已为 WPS 文字、表格、演示、PDF 建立 Nautilus 右键“打开方式”入口，并设为默认。

·Okular 已卸载，用户配置、缓存和 MIME 残留已清理。

·云空间报错通过清理旧 WPS 实例与旧临时挂载解决；CloudDoc 列表和云端 PDF 打开均已验证。

关键产物

02 | 架构与原理

AppImage 不是把整个应用程序目录简单改后缀，而是一个带 ELF 运行时的可执行文件。运行时会通过 FUSE 把内部的 SquashFS 只读挂载到 /tmp/.mount_xxx，然后执行 AppDir 根目录下的 AppRun。WPS 的 Qt、CEF、字体和办公模块都从这个挂载点读取。

图 1：AppImage 运行时结构。左侧是单个文件，右侧是挂载后的 AppDir 视图。

三个层次

1. Type 2 Runtime：负责挂载、校验和调用 AppRun；它由 appimagetool 嵌入到文件头部。

2. SquashFS 数据：保存 AppRun、WPS office6、外部依赖库、图标、字体和 MIME/desktop 元数据。

3. AppRun 脚本：真正决定启动哪个 WPS 组件、设置哪些环境变量、使用哪些库路径。

03 | 获取并校验官方 WPS RPM

官网 linux.wps.cn 页面提供的 RPM 下载地址带有时间戳和签名参数。页面脚本先计算 MD5(secretKey + pathname + timestamp)，再拼成 ?t=...&k=...。如果直接访问裸 URL，会得到 403，因此下载脚本需要模拟这一步。

BASE='https://wps-linux-personal.wpscdn.cn'          RPM='wps-office-12.1.2.29183.AK.preread.sw.Personal-1-806792.x86_64.rpm'          URI="/wps/download/ep/Linux2023/29183/$RPM"          KEY='7f8faaaa468174dc1c9cd62e5f218a5b'          T=$(date +%s)          K=$(printf '%s' "$KEY$URI$T" | md5sum | cut -d' ' -f1)          curl -fL "$BASE$URI?t=$T&k=$K" -o "$RPM"

下载后先用 file、bsdtar 和 sha256sum 做基础检查。本次官方 RPM 的 SHA-256 为：

23292233dd3d2cc8b731e4cb27aadc478285b49eb7afb8a36bd5583fe65a9ffa

RPM 解包后约 2.1 GB，包含 office6、模板、WPS 字体、图标、desktop 文件和 MIME XML。WPS 自带启动脚本 /usr/bin/wps、et、wpp、wpspdf 也需要保留；它们不是普通命令，而是决定 prome_fushion 融合模式的关键入口。

04 | 组装 AppDir

AppDir 的目标不是最小化文件数量，而是尽量保留官方安装后的相对路径与文件语义。最终结构如下：

图 2：AppDir 目录结构与三个重定位修正点。

关键复制操作

# office6、模板、字体、图标、MIME、字体替换规则          cp -a --link rpm-root/opt/kingsoft/wps-office/office6 AppDir/opt/kingsoft/wps-office/          cp -a --link rpm-root/opt/kingsoft/wps-office/templates AppDir/opt/kingsoft/wps-office/          cp -a --link rpm-root/usr/share/fonts/wps-office AppDir/usr/share/fonts/          cp -a --link rpm-root/usr/share/icons/hicolor AppDir/usr/share/icons/          # 官方包装脚本放在 office6 同级          for name in wps et wpp wpspdf; do          cp -a --link "rpm-root/usr/bin/$name" "AppDir/opt/kingsoft/wps-office/$name"          done

另外要修复 RPM 中一个悬空的 libbz2.so 符号链接：它指向的 libbz2.so.1.0.4 并不在工作目录中。把 AppDir 内的这个悬空链接移除，让运行时继续从宿主系统解析 libbz2.so.1.0，避免动态加载器在无效路径上停住。

图标文件被安装到 AppDir 的 hicolor 主题目录，并在 AppImage 根目录建立 .DirIcon 链接；字体和字体替换规则则用于让 WPS 的宋体/微软雅黑等字体名回退到实际可用字体。

05 | AppRun 启动器与重定位

AppRun 是 AppImage 的“入口脚本”。它需要完成五件事：解析当前挂载点、设置动态库与 Qt 插件路径、注册 WPS 字体、识别用户想要的组件、最终 exec 官方包装脚本。

APPDIR="$(cd "$(dirname "$(readlink -f "$0")")" && pwd -P)"          OFFICE="$APPDIR/opt/kingsoft/wps-office/office6"          INSTALL="$APPDIR/opt/kingsoft/wps-office"          export PATH="$OFFICE:$APPDIR/usr/bin:$PATH"          export LD_LIBRARY_PATH="$APPDIR/usr/lib/wps-deps:$OFFICE:$OFFICE/addons/cef:$OFFICE/addons/kcef:$OFFICE/qt/lib"          export QT_PLUGIN_PATH="$OFFICE/qt/plugins"          export QT_QPA_PLATFORM="${WPS_APPIMAGE_QT_PLATFORM:-xcb}"          export XDG_DATA_DIRS="$APPDIR/usr/share:${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"

组件选择规则同时支持显式参数和文件扩展名：--writer/--sheets/--presentation/--pdf 分别映射到 WPS 文字/表格/演示/PDF；如果传入 .docx/.xlsx/.pptx/.pdf，则按扩展名选择。没有参数时默认启动 WPS 文字。

case "${1-}" in          --writer|--wps) shift; app="wps" ;;          --sheets|--et) shift; app="et" ;;          --presentation|--wpp) shift; app="wpp" ;;          --pdf) shift; app="wpspdf" ;;          esac          if [ -x "$INSTALL/$app" ]; then          exec "$INSTALL/$app" "$@"          fi          exec "$OFFICE/$app" "$@"

06 | 依赖闭包与 114 个共享库

WPS 的主程序、Qt 插件、CEF、图像模块和可选办公组件都是 ELF 文件。只检查主程序的 ldd 并不够；必须对 AppDir 内所有 ELF 文件做动态依赖闭包扫描，才能发现由插件间接引入的 X11、GTK、ICU、字体和多媒体库。

图 3：依赖闭包扫描过程。529 个 ELF 最终收敛为 114 个外部用户态库。

扫描思路

export LD_LIBRARY_PATH="$OFFICE:$OFFICE/addons/cef:$OFFICE/addons/kcef:$OFFICE/qt/lib"          find "$APPDIR" -type f \( -perm /111 -o -name '*.so' -o -name '*.so.*' \) -print0 \          | xargs -0 file | awk -F: '/ELF/ {print $1}' > elf-files.txt          while IFS= read -r f; do          ldd "$f" 2>&1          done < elf-files.txt | grep -Eo '/[^[:space:]]+' | sort -u > deps-all.txt

扫描结果中有一部分是 WPS 自身子目录里的模块，运行时由 WPS 的私有加载器解析；外部路径才是需要放进 AppImage 的库。最终将 114 个外部用户态库放入 AppDir/usr/lib/wps-deps，并把它放在 LD_LIBRARY_PATH 前部。

为什么要额外打包 libstdc++ / libgcc

WPS RPM 自带 GCC 13 的 libstdc++.so.6，而目标系统的 Qt/集成插件需要更新的 CXXABI_1.3.15。把系统 libstdc++.so.6 与 libgcc_s.so.1 一并打入 wps-deps，并让 wps-deps 位于 LD_LIBRARY_PATH 前部，可以同时满足旧 WPS 模块和新系统插件。

宿主边界

AppImage 不应把 glibc 和动态加载器强行打进去，否则宿主 bash、图形栈和内核接口容易出现版本冲突。本包保留的宿主库只有 glibc 家族、动态加载器、systemd NSS 模块和 GPU 内核驱动接口；运行时审计实际观察到的宿主侧库为：

/usr/lib/ld-linux-x86-64.so.2          /usr/lib/libc.so.6          /usr/lib/libdl.so.2          /usr/lib/libm.so.6          /usr/lib/libpthread.so.0          /usr/lib/librt.so.1          /usr/lib/libresolv.so.2          /usr/lib/libnss_mdns_minimal.so.2          /usr/lib/libnss_myhostname.so.2          /usr/lib/libnss_mymachines.so.2          /usr/lib/libnss_resolve.so.2

07 | 构建 AppImage

AppDir 组装并通过 desktop-file-validate、bash -n、核心可执行文件 ldd 检查后，用 appimagetool 生成 Type 2 AppImage。zstd 在体积和解压速度之间比较平衡。

图 4：从官方 RPM 到可安装 AppImage 的构建流水线。

ARCH=x86_64 ./squashfs-root/AppRun \          --no-appstream \          --comp zstd \          --runtime-file runtime-x86_64 \          AppDir-v3 \          WPS-Office-12.1.2.29183-x86_64-deps.AppImage

本次构建过程中 appimagetool 自动下载 runtime 时遇到 GitHub 证书/网络异常。解决办法是从已有 AppImage 中提取 runtime 前缀：先定位第二个 hsqs 偏移，再截取该偏移之前的 ELF 部分，作为 --runtime-file 传入。这样不依赖临时网络下载，也保证了 Runtime 版本一致。

offset=$(grep -abo 'hsqs' WPS-Office-12.1.2.29183-x86_64.AppImage | sed -n '2p' | cut -d: -f1)          head -c "$offset" WPS-Office-12.1.2.29183-x86_64.AppImage > runtime-x86_64          chmod 755 runtime-x86_64

最终 AppImage 大小为约 806 MB。文件头是 ELF + AppImage 标识（7f 45 4c 46 ... 41 49 02），可直接 chmod +x 后执行。

08 | 安装与 wps 命令替换

替换旧 AppImage 时，先保留旧文件的路径不变，只更新文件内容；用户目录和命令入口保持稳定。

APP="$HOME/.application/WPS-Office.AppImage"          NEW="$HOME/wps-appimage-work/WPS-Office-12.1.2.29183-x86_64-deps.AppImage"          unlink "$APP" 2>/dev/null || true          mv "$NEW" "$APP"          chmod 755 "$APP"          mkdir -p "$HOME/.local/bin"          ln -sfn "$APP" "$HOME/.local/bin/wps"

登录 shell 的 PATH 已包含 ~/.local/bin，因此从 i3 的 dmenu_run / Mod+D 输入 wps 就能找到新入口。验证命令：

wps --version          # WPS Office 12.1.2.29183 (AppImage)          readlink -f ~/.local/bin/wps          # /home/tony/.application/WPS-Office.AppImage

09 | Nautilus 文件关联

Nautilus 的“打开方式”并不直接识别 AppImage，而是读取 XDG desktop 文件和 MIME 关联。解决思路是安装四个独立的 desktop 文件：每个文件声明自己支持的 MIME 类型，并通过 Exec 调用 AppImage 的对应组件。

图 5：MIME → desktop → AppImage → AppRun → WPS 组件的完整链路。

四个入口

一个 desktop 文件的关键字段

[Desktop Entry]          Type=Application          Name=WPS Writer          Name[zh_CN]=WPS 文字          Exec=/home/tony/.application/WPS-Office.AppImage --writer %F          TryExec=/home/tony/.application/WPS-Office.AppImage          Icon=wps-office2023-wpsmain          MimeType=application/msword;application/vnd.openxmlformats-officedocument.wordprocessingml.document;application/rtf;application/vnd.oasis.opendocument.text;          StartupWMClass=wpsoffice

这里使用 %F 而不是 %U：文件管理器传入本地路径时，WPS 官方包装脚本可以直接接收文件路径，避免 file:// URL 再经过额外解码。桌面文件安装到 ~/.local/share/applications，图标安装到用户 hicolor 主题目录。

设为默认关联

for f in "$HOME/.local/share/applications"/wps-office-*.desktop; do          id=$(basename "$f")          mimes=$(grep '^MimeType=' "$f" | cut -d= -f2- | tr ';' ' ')          for mime in $mimes; do          xdg-mime default "$id" "$mime"          done          done          update-desktop-database "$HOME/.local/share/applications"

验证时使用 gio mime：它不仅显示默认应用，也显示“Registered applications”；右键菜单正是基于这一份注册信息。

gio mime application/pdf          # Default application for “application/pdf”: wps-office-pdf.desktop          # Registered applications:          #wps-office-pdf.desktop          xdg-mime query default application/pdf          # wps-office-pdf.desktop

图 6：Nautilus 中右键 sample.docx，菜单直接显示“Open With WPS Writer”。

10 | 运行验证

打包完成并不等于交付完成。最终验证覆盖了 AppImage 版本、组件启动、文档关联和真实文件打开。

图 7：WPS Writer 打开脱敏示例 sample.docx。截图中不包含云空间私人文档。

首次使用一个全新的用户配置目录时，WPS 会显示软件许可与隐私政策；这是 WPS 自身首次运行行为，不是 AppImage 故障。

11 | 移除 Okular

目标机上原先安装了 Okular 26.08.1-1。为避免它继续占用 PDF 默认关联和桌面资源，执行了包级卸载，并清理用户配置、数据和 MIME 残留。

printf '%s\n' '********' | sudo -S pacman -Rns --noconfirm okular          # 同时移除的孤立依赖：          # okular, threadweaver, phonon-qt6, phonon-qt6-vlc

用户侧清理：

find "$HOME/.local/share/okular" -depth -delete          unlink "$HOME/.config/okularrc"          unlink "$HOME/.config/okularpartrc"          sed -i -E '/[Oo]kular/d' "$HOME/.config/mimeapps.list"

验证：pacman -Q okular 返回“package was not found”。用户目录中不再存在 Okular 应用配置、缓存和 MIME 关联。Breeze/Papirus 主题包自带的通用 Okular 图标 SVG 属于图标主题资源，没有作为应用文件手工删除，以免破坏包管理状态。

12 | 云空间问题排查

系统曾出现“Can not connect to server, please check your network setting”。排查结果表明，这不是 AppImage 缺库，也不是基础网络不可达，而是旧 WPS 实例和旧临时挂载可能仍在运行，导致云空间连接链路指向过期路径。

图 8：云空间问题的风险链与清理后的复测结果。

关键发现

·WPSCloud.conf 的 libpath 在每次 WPS 启动时会更新为当前挂载点；旧挂载点本身是正常的历史残留形式。

·如果旧 wpscloudsvr 进程仍引用旧挂载，新的 AppImage 可能被旧实例干扰。

·问题修复需要清理旧 WPS 进程和无主 FUSE 挂载，然后从当前 AppImage 重新启动。

·网络复核：account.wps.cn 200、drive.wps.cn 200；qing/plus 返回 404/405 但 TLS 已建立，说明服务可达。

清理动作

pgrep -a -u tony -f 'office6/(wps|et|wpp|wpspdf|wpsoffice|wpscloudsvr|wpsd)'          for mp in $(mount | awk '/WPS-Of/{print $3}'); do          fusermount -u "$mp" || fusermount3 -u "$mp"          done          # 重新启动 wps 后再进入 CloudDoc

复测时 CloudDoc 云目录正常显示，云端 PDF（测度论.pdf）在 WPS PDF 中成功打开。处理原则是：先清理旧实例，再启动当前 AppImage；不要同时保留旧窗口和新命令入口。

13 | 可复现步骤

下面给出一套可以按顺序执行的最小流程。实际路径、WPS 版本和时间戳参数需按环境调整。

01准备目录：mkdir -p ~/wps-appimage-work && cd ~/wps-appimage-work

02下载 RPM：使用官网签名 URL；校验 file、sha256sum、bsdtar -tf。

03解包 RPM：mkdir rpm-root && bsdtar -xf "$RPM" -C rpm-root。

04组装 AppDir：复制 office6、模板、字体、图标、官方包装脚本；补 AppRun 和 desktop 文件。

05扫描依赖：对 AppDir 内所有 ELF 执行 ldd；将外部库复制到 usr/lib/wps-deps。

06校验：bash -n AppRun；desktop-file-validate；ldd 核心程序无 not found。

07构建：ARCH=x86_64 appimagetool --comp zstd --runtime-file runtime-x86_64 AppDir output.AppImage。

08安装：替换 ~/.application/WPS-Office.AppImage；更新 ~/.local/bin/wps 链接。

09关联：安装四个 desktop 文件；复制图标；update-desktop-database；xdg-mime default。

10复测：wps --version、wps --sheets、Nautilus 右键、CloudDoc。

14 | 注意事项与结论

技术边界

·glibc / 动态加载器 / NSS / 内核与 GPU 驱动属于宿主系统边界，不建议塞进 AppImage。

·libGL/EGL 等用户态库可以打包，但厂商 GPU 驱动仍需与宿主内核匹配。

·FUSE 不可用时可以临时使用：APPIMAGE_EXTRACT_AND_RUN=1 ./WPS-Office-...AppImage。

·AppImage 的临时挂载路径每次启动都会变化；不要手工把 /tmp/.mount_WPS-xxxx 写死到用户配置或脚本中。

·WPS 是专有软件；发布/分发前应确认 WPS 许可条款与官方 RPM 的再分发边界。

·替换 AppImage 前先结束旧 WPS 进程，避免旧 wpscloudsvr / 旧挂载干扰新实例。

结论

这次交付的核心不是“做一个能双击的包”，而是把 WPS 的官方安装语义、Qt/CEF 资源路径、外部动态库、桌面文件关联和故障排查串成了一条可复现链路。最终结果是：单个 AppImage 可启动、可打开文档、可通过 wps 命令运行，并且 Nautilus 的右键菜单能够直接选择 WPS 文字、表格、演示和 PDF。

附录 A | Desktop 文件与关联范围

以下四个 desktop 文件安装在 ~/.local/share/applications。它们的 Name 会出现在 Nautilus 的“打开方式”菜单中；MimeType 决定文件管理器是否把该入口列为候选。

WPS Writer 的关键 MIME

application/msword;          application/vnd.ms-word;          application/x-msword;          application/vnd.openxmlformats-officedocument.wordprocessingml.document;          application/vnd.ms-word.document.macroEnabled.12;          application/rtf; text/rtf;          application/vnd.oasis.opendocument.text;          application/wps-office.doc; application/wps-office.docx;          application/wps-office.wps; application/wps-office.wpt;

WPS Spreadsheets 的关键 MIME

application/vnd.ms-excel;          application/msexcel; application/x-msexcel;          application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;          application/vnd.ms-excel.sheet.macroEnabled.12;          text/csv; application/csv;          application/vnd.oasis.opendocument.spreadsheet;          application/wps-office.xls; application/wps-office.xlsx;          application/wps-office.et; application/wps-office.ett;

WPS Presentation 的关键 MIME

application/vnd.ms-powerpoint;          application/mspowerpoint; application/powerpoint; application/x-mspowerpoint;          application/vnd.openxmlformats-officedocument.presentationml.presentation;          application/vnd.openxmlformats-officedocument.presentationml.slideshow;          application/vnd.ms-powerpoint.presentation.macroEnabled.12;          application/vnd.oasis.opendocument.presentation;          application/wps-office.ppt; application/wps-office.pptx;          application/wps-office.dps; application/wps-office.dpt;

WPS PDF 的关键 MIME

application/pdf;          application/wps-office.ofd;

如果后续安装了其他 PDF 阅读器，xdg-mime 的默认值可能被改回其他应用；只要重新执行一次 xdg-mime default wps-office-pdf.desktop application/pdf 即可恢复。

附录 B | 最终检查清单

关键路径

目标机：          /home/tony/.application/WPS-Office.AppImage          /home/tony/.local/bin/wps          /home/tony/.local/share/applications/wps-office-writer.desktop          /home/tony/.local/share/applications/wps-office-spreadsheets.desktop          /home/tony/.local/share/applications/wps-office-presentation.desktop          /home/tony/.local/share/applications/wps-office-pdf.desktop          本任务输出：          outputs/WPS-Office-12.1.2.29183-x86_64.AppImage          outputs/WPS-Office-12.1.2.29183-x86_64.AppImage.sha256          outputs/BUNDLED_LIBRARIES.txt          outputs/README.txt