桌面应用文档音视频OCR【免费下载链接】flyingmouse-format飞鼠格式 FlyingMouse Format - Windows 免费文件格式转换工具离线可用内置 FFmpeg/LibreOffice/Poppler/Tesseract。图片/文档/表格/PPT/PDF/音视频/WPS 格式互转 OCR 批量转换音频仅支持普通格式。作者牢蜂LaoFeng仅供个人免费使用禁止商业售卖/转卖/套壳项目地址https://gitcode.com/gh_mirrors/fl/flyingmouse-format点击查看免费下载本文基于 FlyingMouse Format 仓库内 v0.3.6 商店上传校验记录系统讲解该 Windows 免费格式转换工具在 Microsoft Store 渠道的包校验规范从 781 MB APPX 的 SHA-256 指纹、AppxManifest 身份字段核对、包内离线引擎资源清单到 check-appx.py 自动化校验器、Partner Center 三阶段门槛与上传注意事项。读完本文你将掌握本地构建 → 自动化校验 → 现场上传 → 认证回读的完整商店发布实战链路并理解商店版MSIX/APPX与 GitHub NSIS 版在运行时行为上的关键差异。一、校验记录概览一个可追溯的商店包快照v0.3.6 商店上传校验记录生成于 2026-08-12本机本质上是一份面向商店提交的包验收快照它把待上传的包是什么、里面有什么、身份对不对固化为可复核的事实项目值包文件dist\FlyingMouse Format-Setup-0.3.6-x64.appx大小781,295,280 字节约 745 MBSHA-2564f627586440cdf3c598659a6938f72d0333e4a093fa5c845adafb54e1404e792处理器架构x64版本0.3.6.0注意一个细节记录的是完整包的 SHA-256 而非 ZIP/CRC 校验。SHA-256 是对整个文件字节流的摘要任何一位字节的改变都会导致指纹完全变化因此它是商店上传、传输核验、以及本地原件与上传副本是否一致最可靠的证据。这与 check-appx.py 内部用hashlib.sha256逐 1 MiB 分块流式计算摘要的做法一致——大文件校验不整读进内存而是分块迭代。二、AppxManifest 身份字段核对商店提交的身份证商店包的核心身份声明位于包内根部的AppxManifest.xml。v0.3.6 记录核对出的字段如下Manifest 字段v0.3.6 实际值说明Identity Name488B6338.354574AC174AD产品唯一身份标识预留名称与 Partner Center 产品绑定ProcessorArchitecturex64目标架构商店按此分发PublisherCN56D7A4A1-B653-4162-A5E2-7D9B3F3754AD发布者主题Subject取自开发者证书Version0.3.6.0四段版本号商店升级依据DisplayNameFlyingMouse Format商店内显示的应用名PublisherDisplayName牢蜂喜欢开飞机发布者显示名这些值并非手写在构建脚本里而是集中配置在仓库根目录 package.json 的build.appx段appx: { applicationId: FlyingMouseFormat, identityName: 488B6338.354574AC174AD, publisher: CN56D7A4A1-B653-4162-A5E2-7D9B3F3754AD, publisherDisplayName: 牢蜂喜欢开飞机, displayName: FlyingMouse Format, languages: [zh-CN, en-US] }其中build.win.target同时声明了nsis与appx两种产物artifactName模板为${productName}-Setup-${version}-${arch}.${ext}这正好解释了记录中的文件名FlyingMouse Format-Setup-0.3.6-x64.appx的命名规律。从源码结构可以推断identityName/publisher在构建期被写入 ManifestPublisherDisplayName与DisplayName则用于商店展示。三、包内引擎资源清单745 MB 里装了什么v0.3.6 校验记录明确列出的离线引擎资源全部位于包内构建配置见 package.json 的build.win.extraResources包内路径引擎用途resources\ffmpeg\ffmpeg.exeFFmpeg音视频与媒体格式处理resources\libreoffice\LibreOfficePortable\App\libreoffice\program\soffice.comLibreOffice文档/表格/PPT/WPS 等 Office 格式转换resources\poppler\Library\bin\pdftoppm.exePopplerPDF 转图片配合 OCRresources\tessdata\eng.traineddata.gzTesseract英文 OCR 语言数据app.asarElectron 应用归档含 mflac-format / ebook / bmp-input / xml-json / text-conversion 等全部转换模块这正是项目离线可用承诺的工程基础——所有重活引擎随包分发转换不依赖网络。从 electron-main.js 的configureRuntime()可以看到这些引擎在运行时如何被注入环境变量FLYINGMOUSE_FFMPEG_PATH、FLYINGMOUSE_LIBREOFFICE_PATH、FLYINGMOUSE_PDFTOPPM_PATH、FLYINGMOUSE_TESSDATA_PATH分别指向解包后的引擎路径后续模块通过runtime-paths.js统一解析。3.1 商店版引擎的特殊处理只读目录与可写缓存商店版MSIX/APPX与普通安装版的一个关键差异是安装目录只读。MSIX 安装到C:\Program Files\WindowsApps\...后应用对安装目录无写权限而 LibreOfficePortable 无法在只读目录初始化会报 installation could not be completed。electron-main.js 的configureWritableLibreOfficeForStore()专门处理该问题首次运行时把捆绑的 LibreOffice 引擎整体复制到%LOCALAPPDATA%下的每用户可写目录再通过 store-engine-cache.js 在后台 worker 中完成复制与校验office-readiness只对 Office 类转换任务等待就绪其余转换不受影响。tests/store-capabilities.test.js 用测试证明了这一行为Office 探测未完成时PDF 目标查询与文本转换照常可用只有 Office 转换会进入 pending 状态并返回OFFICE_ENGINE_PREPARATION_FAILED503之类的明确错误。四、上传前本地校验check-appx.py 自动化验证器v0.3.6 记录中的各项校验结果在仓库里由 scripts/check-appx.py 自动化复现。它面向未签名的 x64 Store MSIX/APPX做失败即退出非零的严格检查命令行用法python scripts/check-appx.py 包文件.appx dist/win-unpacked/resources/app.asar可选参数参数默认值作用--version来自package.json的version.0期望的四段版本号如0.3.6.0--identitypackage.json的build.appx.identityName期望的 Identity Name--publisherpackage.json的build.appx.publisher期望的 Publisher--launcher-reference重建产物旁的FlyingMouse Format.exe期望的引导启动器bootstrap EXE--runtime-reference重建产物旁的FlyingMouse Format Runtime.exe期望的 Electron Runtime EXE--package-json仓库根package.json默认值来源4.1 校验器的核心检查项源码级解读结合 check-appx.py 的verify_package()实现它至少覆盖以下 10 类检查这正好是商店上传前自查的 checklistZIP 完整性archive.testzip()逐项 CRC 校验任何损坏条目立即报错必需根条目[Content_Types].xml、AppxManifest.xml、AppxBlockMap.xml必须存在于包根部Manifest 身份一致性Identity 的Name/Publisher/Version/ProcessorArchitecture必须与期望值完全一致任一不符即失败入口可执行文件Manifest 中Application/Executable必须存在于包内且必须是兼容性引导启动器app/FlyingMouse Format.exe不允许直接指向 Electron Runtime——测试test_manifest_cannot_bypass_launcher专门验证了这一点启动器/Runtime 双 EXE 配对包内的 launcher 与XXX Runtime.exe必须与本地重建产物的 SHA-256 逐字节一致且两者不能是同一个文件测试test_same_binary_cannot_be_used_as_launcher_and_runtimeapp.asar 一致性包内app/resources/app.asar必须与本地重建 ASAR 的 SHA-256 一致防止包是旧的、代码是新的禁止签名AppxSignature.p7x出现即失败——商店提交交付物必须未签名签名由商店侧流程完成路径安全拒绝%2e%2e/%5c..编码穿越、重复路径、大小写冲突路径、包含冒号或空字节的条目开发/备份目录过滤拒绝.git、.codex、backup、backups、.bak等目录被误打进包OPC 编码名匹配MakeAppx 会把 ZIP 条目中的空格编码为%20校验器统一unquote后与 Manifest 的普通路径比对避免Manifest 指向Flying Mouse.exe、包里却存成Flying%20Mouse.exe这类隐性不匹配见测试test_makeappx_opc_encoded_spaces_match_the_manifest_executable。4.2 测试覆盖与失败即关闭行为tests/check_appx_test.py 用 20 个用例覆盖了上述全部检查路径可直接运行验证python -m unittest discover -s tests -p check_appx_test.py该测试文件同时验证了两个工程要点一是verify_package()返回结构化 JSON 证据evidence含expectedVersion、各文件的referenceSha256/packagedSha256、identity属性、sizeBytes、ok、errors便于记录归档二是 CLI 返回码与 JSON 中的ok字段联动任何一项失败进程退出码非 0杜绝人工看一眼以为没问题。五、Partner Center 上传三阶段门槛与现场回读v0.3.6 记录明确区分了三个不同门槛这是商店发布最容易被混淆的部分上传验证Upload validation包上传到 Partner Center 后的基础格式/身份检查认证Certification微软对包内容、策略、技术要求的正式审核公开发布Publishing认证通过后推向用户的最终步骤。记录中的现场状态v0.3.3 Submission 2ID1152921505701615843最后回读为Pre-processing in progress/In certification说明上传成功绝不等于认证通过更不等于已上架。提交后必须回到 Partner Center 现场回读 submission ID、当前阶段与最终结果不能沿用旧提交号或把未回读状态当作事实。微软商店上架清单 与 0.7.10 修复与发布记录 都反复强调这一原则并给出可操作的检查项上传前现场核对包身份与预留名称、记录 submission ID 与提交时间、认证完成后回读最终结果与商店下载链接。六、商店版与 GitHub 版的差异v0.3.6 之后演进v0.3.6 校验记录本身是上传准备文档而仓库中后续的记录见 v0.5.0 商店上传校验记录揭示了商店版与公开 GitHub NSIS 版刻意存在的差异可作为本文的延伸事实DRM 规避功能隐藏商店版构建时process.windowsStore分支将 ncm/kgg/mflac/mgg/kgma/mmp4 等加密音频解锁入口从 capabilities 过滤解密分发统一返回AUDIO_UNLOCK_UNAVAILABLE_ON_STORE降低 DRM 规避法律风险自动更新禁用商店版跳过应用内自动更新逻辑商店自行更新对应 electron-main.js 中!process.windowsStore的启动器细节配置setAppDetails、setAppUserModelId以及 electron-main.js 的packageType()区分microsoft-store-appx与github-nsis商店文案边界商店公开文案只宣传本地离线转换、OCR、批量处理等能力不宣传 NCM/KGG 或绕过 DRM见 微软商店上架清单 的商店文案边界一节。七、上传注意事项与常见误区根据 v0.3.6 记录末尾的注意项整理出三条硬性约束上传必须由用户本人操作Partner Center 要求微软账号 2FA 登录这是账号安全红线任何自动化流程都不能替代状态必须现场回读上传验证 / Certification / 公开 Publishing 三阶段各自独立任何一阶段的进行中都不能当作下一阶段已完成的证据同一商店产品下旧 Submission 的状态也不能推断新包的状态商店展示素材与包内资源是两套体系商店页面展示图标来自 Store listing 素材与包内 assets 相互独立。若商店页面仍显示旧图标应检查 Store listing 的 logo 素材是否已同步而不是只盯着包版本此条在 v0.5.0 商店上传校验记录 与 微软商店上架清单 中均被重复强调。八、参考文档与延伸阅读v0.3.6 商店上传校验记录本文主体来源v0.5.0 商店上传校验记录商店版 DRM 过滤与自动更新禁用差异微软商店上架清单产品身份、提交前检查项与历史故障排查0.7.10 修复与发布记录最新渠道状态与 Submission 记录口径check-appx.py 与 check_appx_test.py包校验器源码与测试package.jsonbuild.appx身份配置与引擎资源清单electron-main.jsprocess.windowsStore分支与只读目录引擎缓存逻辑store-engine-cache.js 与 store-capabilities.test.js商店引擎缓存与能力就绪行为赞分享桌面应用文档音视频OCR【免费下载链接】flyingmouse-format飞鼠格式 FlyingMouse Format - Windows 免费文件格式转换工具离线可用内置 FFmpeg/LibreOffice/Poppler/Tesseract。图片/文档/表格/PPT/PDF/音视频/WPS 格式互转 OCR 批量转换音频仅支持普通格式。作者牢蜂LaoFeng仅供个人免费使用禁止商业售卖/转卖/套壳项目地址https://gitcode.com/gh_mirrors/fl/flyingmouse-format点击查看免费下载相关推荐FlyingMouse Format 微软商店上架全流程实战MSIX 候选包校验、产品身份配置与提交前检查清单FlyingMouse Format 微软商店上架全流程实战MSIX 候选包校验、产品身份配置与提交前检查清单 导读 本文基于 FlyingMouse For桌面应用文档音视频OCRHermes 与 Jira 集成教程如何关联项目与工单系统Hermes 与 Jira 集成教程如何关联项目与工单系统 Hermes 是一款功能强大的文档管理系统A document management systeelectron-builder AppX 打包完全指南从微软商店发布到企业侧载electron builder AppX 打包完全指南从微软商店发布到企业侧载 本指南以 electron builder 仓库的 website/docs构建工具桌面应用开发工具上一篇Relay 运行时 CacheConfig 类型完全指南从 force 强制刷新到 poll 轮询与 live 实时查询下一篇Presto 0.236 版本发布详解CASE 修复、Alluxio 本地缓存与 Verifier 结果自动比对能力创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考