## 一、缘起：为什么不直接用浏览器

做房地产设计与规划咨询，日常要翻看的图纸和文档种类繁多：DWG 图纸、PDF 文本、Excel 测算表、PPTX 汇报稿、 CAD图纸、SketchUp 模型……它们散落在各个软件里，来回切换、格式不兼容、还担心敏感图纸被上传到云端。
于是我们想做一个**本地优先、离线可用、不传文件**的桌面查看器：一个窗口里用标签页打开多种格式，支持分屏对照、放映汇报。这就是我想开发这个软件的起点。它目前运行在 Windows 上，最新版本 **v2.7.3**。
![image.png](https://developer.qcloudimg.com/http-save/yehe-12603908/3d08bbf8e0e5020101d731a3578c4e92.png)
## 二、技术选型：Electron + 自研查看器矩阵

我们选了 Electron 31 做壳，内核逻辑很轻：**每种格式 = 一个独立的 viewer 模块**，全部放在 `resources/app/viewers/` 下，由 `main.js` 统一注册文件选择对话框的过滤器，`preload.js` 暴露只读文件接口。
整个应用围绕一个极简的 IPC 契约运转：
```
// preload.js —— 渲染进程侧
api.readFileBuffer = (path) => ipcRenderer.invoke('read-file-buffer', path);

// main.js —— 主进程侧
ipcMain.handle('read-file-buffer', async (e, path) => {
  const buf = await fs.promises.readFile(path);
  return { ok: true, data: buf.buffer }; // 返回 ArrayBuffer
});
```每个查看器拿到结果后必须先"拆信封"再使用：
```
const r = await api.readFileBuffer(ctx.path);
if (!r.ok) throw new Error(r.error || '读取失败');
const u8 = new Uint8Array(r.data); // 注意：是 r.data，不是 r 本身
```这套契约看起来平平无奇，却是后面好几个 bug 的根源——下面会看到。
## 三、那些真正卡住我们的难题

### 1. SketchUp "打不开"：一个被忽略的信封

早期版本打开 `.skp` 文件，永远报错"文件头损坏"。排查许久才发现：`skp-viewer.js` 把整个 `{ ok, data }` 对象直接喂给了 `new Uint8Array(r)`，而 `Uint8Array` 对一个普通对象求长度是 **0**——于是文件字节数变成 0，被误判为损坏。
修复就一行：先解包 `r.data` 再构造 `Uint8Array`。同时给解析器加了三角面/边数的上限保护（`MAX_TRIS`、`MAX_EDGES`），避免超大模型卡死渲染进程。这个修复随 v2.4.4 落地，也是"打不开"问题的真正根因。
>经验：跨进程传递二进制时，**信封（envelope）和载荷（payload）一定要在文档里写清楚**，任何一个 viewer 漏解包都会表现为莫名其妙的"解析失败"。

### 2. Excel：为什么我们放弃了 SheetJS 社区版

Excel 是最容易"看起来能打开、其实不对"的格式。社区版 SheetJS 能读单元格值和基础样式，但**不解析填充色、边框、字体细节，更不处理条件格式**。而我们做房地产测算表，底色、边框、条件高亮是信息的核心。
于是我们写了一套**自研样式引擎**，直接用 JSZip + DOMParser 解析 xlsx 包内结构：
```
// excel-viewer.js —— 自研样式引擎核心思路
const styles = parseStyles(xlsxFile('xl/styles.xml'));      // fills / borders / fonts / cellXfs
const theme  = parseTheme(xlsxFile('xl/theme/theme1.xml')); // 主题色板
for (const sheet of sheets) {
  for (const cell of parseSheet(sheet.xml)) {
    const xf = styles.cellXfs[cell.s];   // 取该单元格样式索引
    applyFill(xf.fillId, theme);         // 填充
    applyBorder(xf.borderId);            // 边框
    applyFont(xf.fontId);                // 字体
    applyCondFormat(cell, sheet.condFmt);// 条件格式（dxfs + 每页 conditionalFormatting）
  }
}
```条件格式我们支持了 `cellIs` / `containsText` / `duplicate` / `unique` / `top10` 以及 `colorScale` 渐变。代价是工程量大，但换来和 Excel 几乎一致的视觉还原。
>说明：`.XLS`（BIFF 老格式）目前仍不解析样式，仅保留提示。

### 3. CAD / DWG：原生直读与"脏数据"

DWG 用 `@mlightcad` 做原生直读，DXF 作为兼容后备。真正麻烦的是**脏数据**：实测图纸里常有坐标离谱的碎线、飞点，直接渲染会撑爆视口。
我们用 **MAD（中位数绝对偏差）离群剔除** 清理几何，再用 **ACI（AutoCAD Color Index）调色板** 把索引色映射成真实 RGB，保证图纸配色和 AutoCAD 一致。这一步直接决定了打开大图时是否"一眼就能用"。
### 4. PPTX：主题色的 NaN 幽灵

PPTX 形状填充常引用 `a:schemeClr`（主题色），解析后要走主题调色板换算成 RGB。早期版本偶发整页形状"消失"——追查是主题色解析出了 `NaN`，导致透明度/坐标计算出错，形状被渲染成不可见。
修复是给颜色解析加了兜底：
```
function resolveColorEl(el, theme) {
  const c = resolveSchemeOrSrgb(el, theme); // 处理 srgbClr / schemeClr
  if (isNaN(c.r) || isNaN(c.g) || isNaN(c.b)) return lastClr; // NaN 兜底
  return c;
}
```一个小小的兜底，消除了整类"莫名其妙透明"的反馈。
### 5. PDF：页面旋转（最新功能）

PDF 用 pdf.js 渲染。最近的需求是给页面加旋转。旋转本质上是**视图变换**，不应改动原文件——这也是大多数阅读器的做法。
核心是在取视口时带上 `rotation`：
```
const vp = page.getViewport({ scale, rotation }); // rotation: 0/90/180/270
```文本层会自动跟随 `vp.transform` 同步旋转，缩放和搜索高亮都不受影响。我们在工具栏加了 ↺ / ↻ 两个按钮和实时角度标签，并绑定快捷键 `R`（顺时针）、`Shift+R`（逆时针），放映模式同样生效；`destroy()` 时移除键盘监听，避免多文档泄漏。
## 四、工程化：把"装到哪"交给用户

早期安装器把文件解到临时目录，用户看不到、也改不了安装位置。我们改成**自定义 NSIS 安装器**，把默认位置明确写死为 `D:\Program Files\Kinderly Browser`，并加入"选择安装目录"页：
```
InstallDir "D:\Program Files\Kinderly Browser"
!insertmacro MUI_PAGE_DIRECTORY
```落地逻辑放在 `install-bootstrap.ps1`，支持 `-InstallDir` 参数，尊重用户在目录页的选择：
```
param([string]$InstallDir)
if (-not $InstallDir) { $InstallDir = 'D:\Program Files\Kinderly Browser' }
```>踩坑：NSIS 默认按系统编码读脚本，`.nsi` 里写中文注释会报 `Bad text encoding`。我们的做法是 **`.nsi` 保持纯 ASCII，中文只留在 `.ps1` 里**。

## 五、版本与部署的一些教训

- **按文件类型模块化**：每个 viewer 独立，交互层保持稳定，内部可单独重构。反馈邮箱收到的需求，往往是"某格式显示不对"，定位成本很低。
- **单一真源**：开发过程中出现过桌面副本、共享副本、专家协作副本多份并存。教训是——只要有一份不是真源，就会有人"从旧版本接着改"。现在我们明确：可编辑源码在 `KinderlyBrowser-Setup-v2.7.3\src\`，改完重打包 `app.tar`、再用 makensis 重建安装器。
- **发布节奏**：保持交互不变，按文件类型做模块化拆解；细节问题汇总后统一升级。

## 六、展望

下一步仍遵循"交互不变、内核模块化"的路线：继续打磨 CAD 与条件格式的边界情况，想办法自己开发代码，破解天正格式的cad图纸的显示问题。评估把 PDF 旋转"写回文件"的破坏性需求，并收集真实使用反馈批量升级。
如果你也在做桌面工具、文档预览或 Electron 应用，欢迎在评论区交流。

做房地产设计与规划咨询，日常要翻看的图纸和文档种类繁多：DWG 图纸、PDF 文本、Excel 测算表、PPTX 汇报稿、 CAD图纸、SketchUp 模型……它们散落在各个软件里，来回切换、格式不兼容、还担心敏感图纸被上传到云端。于是我们想做一个本地优先、离线可用、不传文件的桌面查看器：一个窗口里用标签页打开多种格式，支持分屏对照、放映汇报。这就是我想开发这个软件的起点。它目前运行在 Windows 上，最新版本 v2.7.3。

从 0 到 2.7.3：一个桌面多格式文件查看器的开发实录

做房地产设计与规划咨询，日常要翻看的图纸和文档种类繁多：DWG 图纸、PDF 文本、Excel 测算表、PPTX 汇报稿、 CAD图纸、SketchUp 模型……它们散落在各个软件里，来回切换、格式不兼容、还担心敏感图纸被上传到云端。于是我们想做一个本地优先、离线可用、不传文件的桌面查看器：一个窗口里用标签页打开多种格式，支持分屏对照、放映汇报。这就是 Kinderly Browser的起源。

策划规划

编程语言

一款专为房地产设计与规划打造的本地桌面查看器，支持DWG、PDF、Excel、PPTX等格式，无需云端上传，离线可用。采用Electron技术，自研查看器矩阵，解决SketchUp、Excel样式、CAD脏数据等难题。最新版本v2.7.3，支持PDF页面旋转，安装位置自定义，模块化设计便于维护。适用于房地产专业人士高效查看各类图纸文档。

代码解释

Windows

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

一款专为房地产设计与规划打造的本地桌面查看器，支持DWG、PDF、Excel、PPTX等格式，无需云端上传，离线可用。采用Electron技术，自研查看器矩阵，解决SketchUp、Excel样式、CAD脏数据等难题。最新版本v2.7.3，支持PDF页面旋转，安装位置自定义，模块化设计便于维护。适用于房地产专业人士高效...

从 0 到 2.7.3：一个桌面多格式文件查看器的开发实录-腾讯云开发者社区-腾讯云

从 0 到 2.7.3：一个桌面多格式文件查看器的开发实录

从 0 到 2.7.3：一个桌面多格式文件查看器的开发实录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐