夜雨聆风在 OA、知识库或项目管理系统里，附件预览本来应该是一件很自然的事：点开，看完，继续处理业务。
但碰到 .wps、.et 或 .dps，流程常常会突然拐一个弯。先下载到本地，再确认电脑有没有合适的软件；打不开时，还要请发送方另存成 Word、Excel、PowerPoint 或 PDF。明明只是想看一眼内容，最后却变成了一次格式转换接力。
WPS Viewer 想解决的，就是这段并不起眼、却每天都在发生的绕路。
它是一套面向浏览器的 WPS 文档预览能力，当前围绕 WPS 文字、表格与演示三类文档展开，直接覆盖 .wps、.wpt、.et、.ett、.dps、.dpt 六个核心后缀。文件在浏览器端完成识别、解析和静态渲染，适合接入 OA 附件、档案系统、知识库、客服工单和项目协作平台。
它首先是一套可接入的预览组件
WPS Viewer 不是把文件内容粗略抽出来，拼成一长段文本。它提供的是一套完整的阅读工作区：流式与分页视图、页面缩略图、页码定位、40% 到 200% 缩放、适合宽度，以及纸张、解析状态和诊断信息。
对业务系统来说，接入入口保持得很短。拿到用户选择的 File 后，创建查看器并调用 load 即可。
import { createWpsViewer } from 'wps-viewer'
const container = document.querySelector<HTMLElement>('#preview')
if (!container) throw new Error('Preview container not found')
const viewer = createWpsViewer(container)
await viewer.load(file, {
parseOptions: { fileName: file.name },
})
这段 API 背后做的事情比“按扩展名选择组件”多得多。文件名可以被修改，内部容器却不会说谎。WPS Viewer 会结合文件签名、加密状态、CFB 目录、ZIP 包内容和文档特征判断真实类型，再把它送到对应的文字、表格或演示适配器。
扩展名提示
-> 文件签名与加密探测
-> CFB 目录或 ZIP 内容画像
-> Writer / Spreadsheet / Presentation 适配器
-> 统一文档模型
-> 流式 / 工作表 / 幻灯片渲染器
-> 诊断与保真度信息
所以，一个后缀为 .wps 的文件，如果内部实际是 OOXML 包，仍然可以进入对应的文档链路；遇到未知变体或损坏文件，也会给出可解释的诊断，而不是留下一块空白页面。
46 个登记格式，成熟度需要分开看
完整支持矩阵目前登记了 46 个扩展名。它们来自 WPS 官方在线预览格式范围，并补充了 5 个 UOF 3 常见别名。这里的“登记”表示系统能够识别并分派，不代表每一种格式都已经达到同样的原生解析深度。
WPS 文字与通用文档包括：.wps、.wpt、.doc、.dot、.docx、.dotx、.docm、.dotm、.rtf、.txt、.xml、.mhtml、.mht、.html、.htm、.uof、.uot3、.uott3。
WPS 表格与电子表格包括：.et、.ett、.xls、.xlt、.xlsx、.xltx、.xlsm、.xltm、.csv、.uos3、.uost3。
WPS 演示与幻灯片包括：.dps、.dpt、.ppt、.pps、.pot、.pptx、.pptm、.ppsx、.ppsm、.potx、.potm、.uop3、.uopt3。
固定版式与辅助格式包括：.pdf、.ofd、.otl、.dbt。
按当前注册表的实现状态统计，7 个格式已经走直接实现链路，17 个格式委派给经过验证的 Office 渲染能力，21 个格式处在部分解析或渐进增强阶段，.otl 仍明确标记为暂不支持。
这个区分很重要。支持矩阵不是越长越好看，而是每个后缀都应该有清楚的入口、出口和失败方式。一个格式即使只能提取部分结构，也应当告诉使用者目前看到了什么、遗漏了什么，而不是悄悄把不完整结果当作完整文档。
文字、表格、演示，共用一套识别链路
不同文档最终会进入不同的阅读方式。文字文档关心段落、分页、图片与 OfficeArt；表格关心工作表、单元格、合并区域和几何布局；演示文稿则关心幻灯片顺序、画布、文本框与图片资源。
以表格为例，工作区不仅显示单元格文字，还需要保持行列尺寸、合并区域和页面关系。当前 ET 基线样本识别出 1 个工作表、15 行、10 列和 5 个合并区域，浏览器输出与 PDF 基线都是 2 页。
演示文稿走的是另一条渲染路径。当前 DPS 基线样本包含 36 张幻灯片和 19 个图片资源，浏览器输出与 PDF 基线均为 36 页。对文字样本，系统识别出 1455 个正文块、488 个可见媒体和 3 组 OfficeArt；浏览器分页为 104 页，LibreOffice 基线为 100 页，因此仍不能把它描述成像素级一致。
这些数字不是宣传装饰，而是回归测试的一部分。分页有差异，就保留差异；模板样本不足，就继续补样本。只有把边界写下来，后续优化才有可靠的起点。
预览，不等于执行文档里的程序
WPS Viewer 的目标是只读查看。宏、ActiveX、DDE、外部数据连接和文档内程序不会被执行。遇到密码保护、未知容器或结构异常时，解析器会返回诊断状态，业务系统可以据此提示用户补充密码、重新上传或下载原文件处理。
当前源码检查覆盖 31 个 TypeScript 模块，核心语料库 11 个样本全部通过，6 项必需门禁全部通过，聚合证据评分为 83.3/100。剩余缺口主要集中在 .wpt、.ett、.dps、.dpt 的独立原生样本，以及 .wpt 的布局基线。
换句话说，产品已经可以进入真实系统做受控接入，但仍会诚实保留模板格式和复杂版式的验证清单。生产可用不是一句“都支持”，而是每次升级都能重新回答：哪些样本通过了，哪些链路退化了，哪些格式仍需谨慎。
下一步：接入 File Viewer 的完整矩阵
WPS Viewer 目前是一套独立、专注的能力。下一步会把它接入 File Viewer，让业务系统通过同一个入口处理 WPS、Office、PDF、OFD、CAD、压缩包、图片、音视频和更多长尾文档。
File Viewer 当前由生成目录登记 221 个扩展名、32 条渲染管线。将 WPS Viewer 的 46 个登记格式与它逐项比对后，有 28 个后缀已经存在于现有矩阵，另外 18 个后缀还没有对应入口。六个 WPS 核心后缀也在这 18 个之中。
接入会分四步推进。
先增加独立的 WPS 渲染器，接住 .wps、.wpt、.et、.ett、.dps、.dpt，打通文件识别、Worker、WASM、静态资源和组件生命周期。对已经重叠的 28 个后缀复用 File Viewer 现有管线，避免同一种 Office 文档出现两套互相冲突的路由。 对 UOF 别名、 .mhtml、.mht、.pps、.dbt等剩余入口逐项核对；.otl在证据充分前继续保持诊断状态。最后补齐预设包、Vite 插件、完整包、真实样本、截图基线、离线验证和发布门禁，让新增能力能被安装、按需加载，也能被持续验证。
合并后的扩展名总数不会提前写死。真正进入 File Viewer 的格式，必须通过生成目录和对应门禁，最终数字以合并时的代码事实为准。
先把“打开看看”这件事做好
WPS 文档不是什么稀奇格式。它们一直存在于合同、报表、汇报材料和历史档案里，只是过去经常被挡在浏览器预览之外。
WPS Viewer 做的事情很朴素：让这些附件在需要被阅读的时候，少一次下载，少一次转换，也少一句“麻烦再发个 PDF”。至于更复杂的版式、模板和历史变体，我们会继续靠真实样本一点点补齐。
点击文末的「阅读原文」，即可打开 WPS Viewer 在线 Demo。
