简介：面向Web前端开发者与需要为网站补充文件预览能力的工程师，这份资源用HTML与JavaScript演示如何在浏览器中直接查看PDF、Excel、PPT、DOC、JPG、PNG等常见格式，无需下载即可浏览内容。压缩包共6个文件，约238KB，包含HTML示例页面、jQuery及媒体预览脚本、说明文档，以及用于验证效果的图片与文档样本，结构轻量、便于直接运行和二次改造。已有27287人学习下载，说明该方案在实际项目中具有较高参考价值。读者可从中获得PDF嵌入与第三方解析库的用法、图片标签预览、Office文档借助在线查看服务或服务端转换的完整思路，并对照示例页面理解各格式的接入方式与兼容性边界，为搭建用户友好的在线预览功能提供可复用的代码基础与排错参考。
1. 浏览器里直接打开 PDF、Excel、PPT：这套 HTML+JS 预览方案到底能干什么
上周同事丢过来一个压缩包，说客户要在后台管理系统里点一下附件就能看，别弹新窗口、别装插件、别让用户下载。我第一反应是后端转码，结果对方环境里连 LibreOffice 都不让装。最后翻出来的就是这套纯前端方案：HTML 加 JavaScript，靠浏览器原生能力和几个成熟库，把 pdf、xlsx、pptx、docx、jpg、png 六类文件在页面里直接渲染出来。它解决的不是“万能预览”，而是“常见办公文档和图片，在不碰服务端的前提下先看起来”。适合做内部管理系统、工单附件、合同台账这类场景的前端同学，也适合想搞清楚各格式预览边界在哪的熟手。下面按我实际拆包、改配置、踩坑的顺序讲，能直接抄的部分我都贴了代码。
2. 六种格式的渲染路径拆解：谁靠原生、谁靠库、谁只能降级
这套方案的核心思路不是“一个库通吃”，而是按文件类型分流。理解分流逻辑比背 API 重要，因为后面所有参数和坑都从这里长出来。
2.1 图片与 PDF：优先吃浏览器原生能力
jpg、png 最简单，<img>标签加一个URL.createObjectURL就能显示，连库都不用引。PDF 稍微复杂一点：现代浏览器（Chrome、Edge、Firefox 较新版本）内置了 PDF 查看器，最省事的做法是直接把 blob URL 塞进<iframe>或<embed>，浏览器自己接管渲染、翻页、缩放。这条路线的优点是零依赖、清晰度高、文字可选中；缺点是移动端 Safari 对 iframe 内 PDF 的支持时好时坏，而且你没法控制工具栏样式。
如果产品要求统一工具栏、要页码跳转、要禁止下载按钮，那就得上 pdf.js。它把 PDF 解析成 canvas 逐页绘制，控制权全在你手里，代价是包体积增加（完整版压缩后仍有几百 KB），以及需要额外配置 worker 文件路径。我的取舍是：后台内部系统用 iframe 够了，面向外部用户的阅读器才上 pdf.js。
// 原生 iframe 预览 PDF：最简路径 function previewPdfNative(file, container) { const url = URL.createObjectURL(file); // 生成临时 blob 地址 const iframe = document.createElement('iframe'); iframe.src = url; iframe.style.width = '100%'; iframe.style.height = '80vh'; iframe.style.border = 'none'; container.innerHTML = ''; container.appendChild(iframe); // 注意：不要立刻 revoke，否则 iframe 加载会失败 iframe.onload = () => URL.revokeObjectURL(url); }这段代码的关键在最后一行注释。URL.createObjectURL生成的是内存引用，很多人习惯用完马上revokeObjectURL，结果 iframe 还没读完就被回收，页面白屏。正确时机是等onload之后再释放，或者干脆在组件卸载时统一释放。参数上height用80vh是经验值，太矮了 PDF 工具栏会挤成一团。
2.2 Office 三件套：xlsx、pptx、docx 各走各的库
这是整套方案里最容易被低估的部分。很多人以为 Office 文件能像 PDF 一样丢给浏览器，实际上浏览器对 OOXML 格式一无所知，必须靠 JS 库解析。
xlsx 用 SheetJS（社区版叫 xlsx），它把工作簿解析成 JSON，你再自己渲染成 HTML 表格。好处是能精确控制单元格合并、列宽、数字格式；坏处是样式（字体颜色、背景填充）社区版支持有限，复杂报表会“形似神不似”。pptx 用 pptxgenjs 的反向能力有限，实际预览一般用 JSZip 解包后读 XML 再拼幻灯片，或者退而求其次转成图片序列。docx 用 mammoth.js，它把 Word 转成语义化 HTML，段落、标题、列表、基础表格都能还原，但页眉页脚、文本框、复杂排版会丢。
// xlsx 预览：解析后手动渲染表格 import * as XLSX from 'xlsx'; function previewExcel(file, container) { const reader = new FileReader(); reader.onload = (e) => { const data = new Uint8Array(e.target.result); // cellStyles: true 尝试读取样式，但社区版能力有限 const workbook = XLSX.read(data, { type: 'array', cellStyles: true }); const firstSheet = workbook.Sheets[workbook.SheetNames[0]]; // header:1 输出二维数组，方便自己控制表头 const rows = XLSX.utils.sheet_to_json(firstSheet, { header: 1, defval: '' }); const table = document.createElement('table'); table.className = 'preview-table'; rows.forEach((row) => { const tr = document.createElement('tr'); row.forEach((cell) => { const td = document.createElement('td'); td.textContent = cell; tr.appendChild(td); }); table.appendChild(tr); }); container.innerHTML = ''; container.appendChild(table); }; reader.readAsArrayBuffer(file); // 必须用 ArrayBuffer，不能读成文本 }参数说明：type: 'array'告诉 SheetJS 输入是字节数组；header: 1让输出保留原始行结构而不是对象数组，这样空单元格和表头位置不会错位；defval: ''防止空单元格变成undefined导致渲染出 “undefined” 字样。readAsArrayBuffer这一步是血泪经验——用readAsText读 xlsx 会得到乱码，因为 xlsx 本质是 zip 压缩包。
2.3 格式分流的判断逻辑
实际落地时，入口只有一个文件对象，得先按扩展名或 MIME 分流。我一般写一个映射表，而不是一长串 if-else，方便后续加格式。
| 格式 | 判断依据 | 渲染方式 | 依赖 |
|---|---|---|---|
| jpg/png | MIMEimage/* | <img>+ blob URL | 无 |
扩展名.pdf | iframe 或 pdf.js | 可选 pdf.js | |
| xlsx | 扩展名.xlsx/.xls | SheetJS 解析 + 自绘表格 | xlsx |
| docx | 扩展名.docx | mammoth 转 HTML | mammoth |
| pptx | 扩展名.pptx | JSZip 解包 + 图片化 | jszip |
注意.doc和.ppt这两个老二进制格式不在支持范围内，库基本都只认 OOXML（即 docx/pptx）。遇到老格式只能提示用户另存为新格式，或者走服务端转换。这一点在需求评审时就要说清楚，否则上线后被投诉“为什么我的 doc 打不开”很被动。
3. 从文件对象到页面渲染：一套可复用的预览调度器
光有单格式函数还不够，真实项目里文件来源五花八门——<input type="file">、拖拽、后端接口返回的 blob、甚至 base64。调度器要做的就是把它们统一成 File/Blob，再按类型分发。
3.1 统一入口与类型识别
先解决“怎么判断文件类型”。只靠扩展名不可靠（用户可以改后缀），只靠 MIME 也不可靠（部分系统上传时 MIME 是空的）。我的做法是扩展名优先、MIME 兜底，两者都拿不到就提示不支持。
// 统一预览入口 const PREVIEW_MAP = { jpg: 'image', jpeg: 'image', png: 'image', gif: 'image', pdf: 'pdf', xlsx: 'excel', xls: 'excel', docx: 'word', pptx: 'ppt' }; function getFileType(file) { const ext = file.name.split('.').pop().toLowerCase(); if (PREVIEW_MAP[ext]) return PREVIEW_MAP[ext]; // 扩展名不认识时用 MIME 兜底 if (file.type.startsWith('image/')) return 'image'; if (file.type === 'application/pdf') return 'pdf'; return 'unsupported'; } async function previewFile(file, container) { const type = getFileType(file); switch (type) { case 'image': return previewImage(file, container); case 'pdf': return previewPdfNative(file, container); case 'excel': return previewExcel(file, container); case 'word': return previewWord(file, container); case 'ppt': return previewPpt(file, container); default: container.innerHTML = '<p class="tip">该格式暂不支持在线预览，请下载后查看</p>'; } }PREVIEW_MAP用对象而不是数组，查找是 O(1)，加格式只改一处。getFileType里扩展名优先是有意的：某些浏览器对 docx 给的 MIME 是application/octet-stream，靠 MIME 会误判。兜底逻辑只处理图片和 PDF，因为这两类 MIME 相对规范。
3.2 docx 与 pptx 的渲染细节
docx 用 mammoth 转 HTML 是最省心的路线，但要注意它输出的是“语义 HTML”，不带原文档的字体和页边距。如果你的产品对还原度要求高，得在容器上加一层 CSS 重置，把h1~h6、p、table的默认样式调得接近 Word。
import mammoth from 'mammoth'; function previewWord(file, container) { const reader = new FileReader(); reader.onload = (e) => { const arrayBuffer = e.target.result; mammoth.convertToHtml({ arrayBuffer }) .then((result) => { // result.messages 里是转换告警，比如不支持的样式 if (result.messages.length) { console.warn('docx 转换告警：', result.messages); } container.innerHTML = `<div class="docx-body">${result.value}</div>`; }) .catch((err) => { container.innerHTML = '<p class="tip">文档解析失败，可能已损坏</p>'; console.error(err); }); }; reader.readAsArrayBuffer(file); }result.messages这个返回值很多人忽略，它记录了哪些元素没转换成功（比如文本框、艺术字）。上线前拿几份真实文档跑一遍，把高频告警记下来，比上线后被用户追问强。pptx 的纯前端预览更麻烦，常见做法是用 JSZip 读出ppt/slides/slideN.xml，提取文字和图片位置，再拼成简化版幻灯片；还原度有限，我一般会在预览区顶部加一行提示“简化预览，版式可能与原文件有差异”，降低用户预期。
3.3 大文件与内存释放
预览不是下载，用户可能连续点十几个附件。每次createObjectURL都会占内存，不释放的话标签页越用越卡。我的习惯是在容器组件卸载或切换文件时，统一清理上一轮的 blob URL。
// 用一个数组记录本轮生成的所有 blob URL let activeUrls = []; function trackUrl(url) { activeUrls.push(url); return url; } function cleanupUrls() { activeUrls.forEach((url) => URL.revokeObjectURL(url)); activeUrls = []; } // 切换文件前调用 cleanupUrls()，再开始新的预览这段不复杂，但漏掉就是黑匣子式的卡顿——用户说不清哪里慢，你也不好复现。另外超过 20MB 的 xlsx 解析会明显阻塞主线程，条件允许的话把解析放进 Web Worker，或者至少加个 loading 遮罩，别让用户以为页面死了。
4. 避坑与排查：预览白屏、乱码、样式错位的真实原因
这一章是我改这套方案时踩过的坑，按“现象 → 原因 → 解决”记，遇到同类问题可以直接对号入座。
4.1 现象：PDF 预览白屏，控制台无报错
原因多半是 blob URL 被提前revokeObjectURL，或者 iframe 的src设置时机不对（容器还没挂到 DOM 上就赋值）。解决：把revoke挪到onload之后或组件卸载时；确保container.appendChild(iframe)先执行，再设src。还有一种情况是跨域策略——如果 PDF 来自后端接口且响应头带了Content-Disposition: attachment，部分浏览器会强制下载而不是内联显示，需要后端配合改成inline。
4.2 现象：Excel 表格全是乱码或解析报错
原因是用FileReader.readAsText读了 xlsx。xlsx 是 zip 容器，必须按二进制读。解决：统一用readAsArrayBuffer，再交给XLSX.read(data, { type: 'array' })。如果解析出来只有第一个 sheet，检查是否只取了SheetNames[0]，多 sheet 场景要加 sheet 切换器。
4.3 现象：docx 转出来的 HTML 样式全乱，标题挤成一坨
原因是 mammoth 输出的是语义标签，项目里的全局 CSS 重置把h1~h6的 margin 清零了。解决：给预览容器加独立命名空间，比如.docx-body h1 { font-size: 1.6em; margin: 0.8em 0; }，把常用标签的样式补回来。别指望还原 100%，能把层级和段落分清就够用。
4.4 现象：图片预览正常，但旋转了 90 度
原因是手机拍摄的 jpg 带 EXIF Orientation 信息，浏览器<img>有时不自动纠正。解决：读取时用createImageBitmap配合imageOrientation: 'from-image'，或者引入轻量的 EXIF 解析库手动旋转 canvas。这个坑在移动端上传场景特别高频。
4.5 现象：连续预览多个文件后页面卡死
原因是 blob URL 和解析后的 DOM 都没释放，内存持续增长。解决：按 3.3 的思路统一 track 和 cleanup；大文件解析加 loading 和超时提示；pptx 这类重解析操作考虑放 Worker。排查时打开浏览器任务管理器看内存曲线，比盯着 console 有效。
5. 进阶：把预览做成可配置组件与还原度验证
走到这一步，单文件预览已经能跑，但真实项目往往要求“同一个组件支持多种格式、能配置工具栏、能降级”。我的做法是把调度器包成一个类，对外只暴露preview(file)和destroy()两个方法，内部维护容器、URL 列表和当前类型。
class FilePreviewer { constructor(container, options = {}) { this.container = container; this.options = { showTip: true, maxSize: 30 * 1024 * 1024, ...options }; this.urls = []; } async preview(file) { if (file.size > this.options.maxSize) { this.container.innerHTML = '<p class="tip">文件过大，建议下载查看</p>'; return; } this.cleanup(); const type = getFileType(file); // 按 type 分发，内部复用前面的单格式函数 await this.render(type, file); } cleanup() { this.urls.forEach((u) => URL.revokeObjectURL(u)); this.urls = []; this.container.innerHTML = ''; } destroy() { this.cleanup(); this.container = null; } }maxSize默认 30MB 是拍脑袋的经验值，超过这个量级前端解析体验急剧下降，不如直接引导下载。showTip控制是否显示“简化预览”提示，外部系统嵌入时可以关掉。验证还原度我一般准备一组固定样本：一份带合并单元格的 xlsx、一份带表格和列表的 docx、一份多图 pptx、一份扫描版 PDF，每次改完代码跑一遍，肉眼比对关键元素是否还在。这套样本比任何自动化断言都直观，毕竟预览的最终裁判是用户的眼睛。
从那以后我每次接预览需求，都先把“支持哪些格式、还原到什么程度、多大文件不拦”这三条写进需求确认单，再动手写代码。希望帮到你。
本文还有配套的精品资源，点击获取
