简介面向iOS开发者的HTML字符串与富文本互转demo源码聚焦服务端HTML内容在UILabel、UITextView等原生控件中的富文本呈现。资源围绕NSAttributedString的初始化转换方法演示如何加载本地HTML文件并解析常见标签帮助解决网页式内容在iOS界面中的显示与样式适配问题。压缩包约1.38MB主要包含工程源码、配置文件及必要的资源文件可直接导入Xcode运行查看效果免去从零搭建工程的麻烦。源码结构清晰注释与示例兼顾能够直观对比原始HTML与转换后的富文本效果。目前已有2715人学习下载。通过该demo可系统掌握HTML转NSAttributedString的完整链路包括标签映射、字体颜色继承、超链接点击等处理思路同时能了解XSS安全过滤、复杂HTML解析兼容性以及大量文本转换时的性能优化注意事项实际项目中服务端返回的文章、公告等富文本内容往往依赖此类转换能力适合刚接触iOS富文本开发的初中级工程师作为参考也可作为日常开发中的工具库直接抽取使用。1. HTML字符串与富文本互转为什么说这层转换是所有富文本编辑器的地基任何一个做后台管理系统、内容发布平台或在线文档的团队迟早要撞上同一个问题富文本编辑器里那一屏带格式的内容存进数据库时到底是什么答案几乎都是 HTML 字符串。而要把这段字符串还原成用户当初看到的样子又必须把它塞回编辑区域。HTML字符串与富文本互转本质上就是围绕contenteditable的一块胶水代码做得稳不稳直接决定编辑器是能用还是三天两头出 bug。这个标题里还藏着一个容易被忽略的点加载本地 html。很多 demo 只教怎么转字符串却不提本地文件怎么读进来。实际开发中用户把本地的.html文件拖进页面、解析后回填到富文本区是非常常见却很少被写清楚的需求。本文按一条完整链路来拆先讲清contenteditable与 HTML 的映射关系再给出互转的最小可运行 demo最后把加载本地 html 文件的几种方案和排错点一次性说透。2. 富文本的本质contenteditable与 HTML 字符串的映射关系2.1 浏览器把 HTML 字符串解析成 DOM 树再把 DOM 树渲染成富文本很多初学者把「富文本」理解成某种特殊的数据格式这是一个根本性的误会。富文本在浏览器里只有一个承载者contenteditable属性。只要把div或iframe的contenteditable设为true这个元素内部就变成可编辑区域用户输入、加粗、插链接背后全是浏览器在操作 DOM。这意味着一个关键结论富文本的内容从来不是神秘的二进制而是标准 HTML。按下加粗按钮时编辑器执行的是document.execCommand(bold)浏览器把选中文本包进b或strong插入图片时编辑器往 DOM 里插了一个img节点。这些 DOM 节点的序列化结果就是 HTML 字符串。既然如此HTML字符串与富文本互转就有了两个清晰的锚点HTML 字符串 → 富文本把字符串塞进innerHTML浏览器自动解析成 DOM 并渲染富文本 → HTML 字符串读取编辑区的innerHTML拿到序列化后的 HTML这个过程里最值得警惕的是「字符串塞进去之后编辑器内部状态会不会乱」。contenteditable区域是有光标位置和选区概念的直接改innerHTML会丢失所有编辑状态。所以真正的互转不是简单的赋值还要考虑时机、事件和异常兜底。2.2 为什么不用textContent或value来存取富文本textContent返回的是纯文本所有标签都会被剥离格式信息全丢value只对textarea和input有效它们根本不支持富文本。只有innerHTML能在字符串与格式化内容之间完整往返。但innerHTML有个副作用每次赋值都会销毁原有 DOM 节点并重建。如果一个编辑器里有图片懒加载、自定义事件绑定或第三方控件重建意味着这些状态全部失效。理解了这一点你就能解释很多线上 bug为什么富文本里插入的视频在回显后不能播放为什么自定义 提及在保存再打开后点击无反应——多半是innerHTML重建砍掉了事件。2.2.1 一个验证映射关系的最小实验打开浏览器控制台执行以下三行代码能直观看到互转的底层逻辑// 创建一个可编辑区域并插入 HTML 字符串 const editor document.createElement(div); editor.contentEditable true; editor.innerHTML p第一段 strong加粗/strong/p; document.body.appendChild(editor); // 读取序列化后的 HTML console.log(editor.innerHTML); // 输出: p第一段 strong加粗/strong/p // 读取纯文本 console.log(editor.textContent); // 输出: 第一段 加粗这段代码的关键在innerHTML的赋值与读取。赋值时浏览器走 HTML parser把字符串变成 DOM读取时走 HTML serializer把 DOM 变回字符串。textContent则完全忽略标签结构只保留文本节点。实际操作中判断一个编辑器是否回显正确第一件事就是看innerHTML往返是否无损。3. HTML 字符串转富文本三种注入方式与光标保留策略3.1 方式一直接赋值innerHTML最简单但会丢光标这是最直观的做法适合初始化回显场景function setEditorContent(htmlString) { const editor document.getElementById(richEditor); editor.innerHTML htmlString; }参数htmlString是服务端返回的 HTML 片段。这个方案的优点是代码量极小、解析性能好浏览器原生处理缺点同样明显——直接赋值会清空原有 DOM、丢光标、丢选区而且如果字符串里有未闭合标签浏览器会自动纠错可能出现「存进去是p回显变成p/p或嵌套错乱」的现象。innerHTML赋值只推荐在编辑器初始化、或用户主动切换文档时使用。3.2 方式二document.execCommand(insertHTML)保留光标并触发撤销栈execCommand虽然被标记为废弃但所有主流浏览器至今仍在实现它富文本编辑器领域短期内还离不开它。它的优势在于在光标位置插入 HTML、保留编辑状态、并且进入浏览器的撤销栈CtrlZ 可用。function insertHtmlAtCursor(htmlString) { const editor document.getElementById(richEditor); editor.focus(); // 先尝试 execCommand失败则回退到 innerHTML 追加 const success document.execCommand(insertHTML, false, htmlString); if (!success) { editor.innerHTML htmlString; } }这段代码的核心是document.execCommand(insertHTML, false, htmlString)。第二个参数false表示不启用 UI第三个参数是待插入的 HTML 字符串。execCommand返回布尔值但不是所有浏览器都返回可靠结果所以加了回退逻辑。实际操作中如果编辑器支持图片粘贴插入img用这个方式就不会破坏剪贴板事件里的文件句柄。3.3 方式三基于选区 API 手动插入适合需要精确控制 DOM 的场景如果要在插入前后做 DOM 操作——比如过滤脚本、给图片加防盗链标记——execCommand就不够灵活了。这时可以直接操作 Selection 和 Rangefunction insertHtmlAtSelection(htmlString) { const editor document.getElementById(richEditor); editor.focus(); const selection window.getSelection(); if (!selection || selection.rangeCount 0) return; const range selection.getRangeAt(0); // 将 HTML 字符串解析为 DocumentFragment保留内部结构 const template document.createElement(template); template.innerHTML htmlString.trim(); const fragment template.content; // 删除当前选中的内容再插入新节点 range.deleteContents(); const lastNode fragment.lastChild; range.insertNode(fragment); // 将光标移动到插入内容的末尾 if (lastNode) { range.setStartAfter(lastNode); range.collapse(true); selection.removeAllRanges(); selection.addRange(range); } }这里的核心是template元素。template.innerHTML只解析不渲染不会触发图片加载或脚本执行比直接用div.innerHTML更安全。range.insertNode(fragment)会把整个片段插入到光标位置且插入后 DOM 是真实节点而非字符串后面要再调整结构可以直接操作这些节点。range.setStartAfter(lastNode)是把光标挪到最后一个子节点之后避免插入后光标跳到文档开头。实际操作中lastNode可能为 null插入空串时所以加了判空。3.4 三种方式的选型标准与性能比拼注入方式是否丢光标是否进撤销栈能否在执行前后拦截 DOM性能innerHTML直接赋值丢不进不能最快execCommand(insertHTML)不丢进不能快Selection Range 手动插不丢需要自己实现能中等真实项目中我一般这样划分初始化回显用方式一用户在当前文档里插入模板、图片、链接用方式二需要做内容安全过滤或精确控制插入位置的用方式三。需要提醒的是execCommand在部分移动端 WebView 里行为不一致insertHTML偶尔会失效所以方式二里的回退代码不是防御性写法而是必要兜底。4. 富文本转 HTML 字符串与加载本地 html读取、解析和回填4.1 从编辑器里取 HTML读innerHTML不等于拿到的就是干净字符串富文本转 HTML 字符串多数人第一反应是editor.innerHTML。这在简单 demo 里没有错但真实场景会遇到三个问题第一浏览器会补全标签。用户输入b粗体innerHTML返回的却是b粗体/b。这是好事但如果你用字符串比较来判断内容是否变化会得到错误结论。第二不同浏览器对空内容的序列化不一致。Chrome 返回brFirefox 可能返回pbr/p。这会导致同一份内容在两个浏览器里存下来的字符串不同。第三编辑器可能加了额外的类名或 data 属性。很多富文本库如 Quill 的部分主题会在 DOM 上挂标记直接读innerHTML会把内部实现细节也存进数据库下次升级库版本时这些标记可能导致样式错乱。一个稍微稳一点的做法是读取前先做归一化function getEditorHtml() { const editor document.getElementById(richEditor); // 先移除空段落避免存下一堆 pbr/p editor.querySelectorAll(p).forEach(p { if (p.innerHTML br || p.textContent.trim() ) { p.remove(); } }); return editor.innerHTML.trim(); }这段代码做的事情是把所有「空段落」从 DOM 里删掉再返回序列化字符串。p.textContent.trim() 判断段落里没有可见文本p.innerHTML br单独处理换行占位。实际使用中如果产品需求是「保留空行」这个清理就要去掉改为把pbr/p替换成pnbsp;/p之类的占位符。4.2 加载本地 html 的第一道坎file://协议下fetch被 CORS 拦截现在进入标题里的核心难点——加载本地 html 文件。最常见的错误是有人直接写fetch(./local.html)在本地双击打开页面时必然失败错误信息是Cross origin requests are only supported for protocol schemes: http, data...。原因在于file://协议下页面源是null任何跨文件请求都会被 CORS 拦截。Chrome 更是直接禁止file://页面发起fetch。不要把--allow-file-access-from-files当常规方案它需要所有访问者都改浏览器启动参数不适合任何正式场景。4.3 正确方案用input typefile加FileReader读取本地 html既然不能用fetch读任意文件就用文件选择框让用户主动授权。input typefile拿到的是File对象不涉及 CORS读取权限由用户手势授权。input typefile accept.html,.htm idhtmlFileInput div contenteditabletrue idrichEditor stylemin-height: 300px; border: 1px solid #ccc; padding: 12px;/divconst fileInput document.getElementById(htmlFileInput); const editor document.getElementById(richEditor); fileInput.addEventListener(change, (event) { const file event.target.files[0]; if (!file) return; // 限制文件大小避免大 HTML 文件阻塞主线程 if (file.size 2 * 1024 * 1024) { alert(文件不能超过 2MB); fileInput.value ; return; } const reader new FileReader(); reader.onload (e) { const htmlString e.target.result; // 关键过滤去掉 script 和 iframe防止恶意代码 const cleaned sanitizeHtml(htmlString); editor.innerHTML cleaned; }; reader.onerror () { alert(文件读取失败请确认文件不是二进制格式); }; reader.readAsText(file, utf-8); }); function sanitizeHtml(input) { const template document.createElement(template); template.innerHTML input; // 移除所有 script、iframe、object、embed 标签及其内容 template.content.querySelectorAll(script, iframe, object, embed, link, meta).forEach(el el.remove()); // 移除所有元素上的 on* 事件属性 template.content.querySelectorAll(*).forEach(el { [...el.attributes].forEach(attr { if (attr.name.toLowerCase().startsWith(on)) { el.removeAttribute(attr.name); } }); }); return template.innerHTML; }这段 demo 的完整逻辑是文件选择框拿到本地 html 文件FileReader.readAsText(file, utf-8)以 UTF-8 编码读成字符串然后先经过sanitizeHtml清洗再回填到编辑器。sanitizeHtml里两个querySelectorAll分别处理两件事一是删掉script、iframe、object、embed这类高危标签二是遍历所有元素的事件属性如onclick、onerror。这两步做完本地 html 文件基本就安全了。需要注意这个清洗函数是 demo 级的生产环境建议直接用 DOMPurify 这类成熟库不要自己维护一份过滤名单。4.4 中文乱码问题readAsText的编码参数与 HTML 内部声明的冲突加载本地 html 时中文乱码几乎是必现问题。原因很典型本地.html文件内部声明了meta charsetgb2312或meta charsetgbk但FileReader.readAsText(file, utf-8)强制按 UTF-8 解码编码不一致就乱码。两个解决思路思路一读二进制再探测编码。用readAsArrayBuffer拿到原始字节然后用TextDecoder配合编码探测。TextDecoder支持gbk和gb18030但不支持自动探测需要自己判断。最常用的探测方法是检查 HTML 头部charset声明function detectCharset(buffer) { const text new TextDecoder(utf-8).decode(buffer); const match text.match(/charset\s*\s*[]?([\w-])/i); if (match match[1].toLowerCase() utf-8) { return utf-8; } // 常见于国内旧系统的 GBK / GB2312 页面 if (match /gb2312|gbk|gb18030/i.test(match[1])) { return gb18030; } return utf-8; // 默认回退 } fileInput.addEventListener(change, (event) { const file event.target.files[0]; if (!file) return; // 先读 ArrayBuffer const bufferReader new FileReader(); bufferReader.onload (e) { const buffer e.target.result; const charset detectCharset(buffer); const decoder new TextDecoder(charset); const htmlString decoder.decode(buffer); editor.innerHTML sanitizeHtml(htmlString); }; bufferReader.readAsArrayBuffer(file); });这里用TextDecoder(gb18030)而不是gbk因为gb18030是gbk的超集能解码更多字符兼容性更好。detectCharset里的正则匹配 HTML 头部的charset声明找到gb2312或gbk就用gb18030解码。实际操作中还有一种偷懒的兼容法先把 UTF-8 解码结果丢给用户看如果出现替换字符就提示用户手动选择编码。这个兜底虽然不优雅但确实能在极端编码场景下救命。5. 进阶技巧图片转 base64、粘贴清理与 XSS 过滤5.1 本地 html 里的图片src相对路径会直接失效加载本地 html 文件后一个高频问题HTML 里的图片全裂了。原因很直白——html 文件在你的磁盘上它引用的图片是./images/a.png你把 html 内容塞进页面后这个相对路径指向的是服务器上的/images/a.png当然 404。解决思路只有两个要么把图片文件一起上传要么把图片转成 base64 嵌进 HTML。demo 场景下推荐 base64因为不需要额外管理文件依赖function convertImagesToBase64(htmlString) { const template document.createElement(template); template.innerHTML htmlString; const images template.content.querySelectorAll(img); images.forEach((img, index) { const src img.getAttribute(src); if (!src || src.startsWith(data:) || /^https?:\/\//.test(src)) { return; // 已经是 base64 或网络图片跳过 } // 这里需要 fetch 本地文件实际场景通常是 FileReader 逐个读取 // demo 提供占位逻辑请求用户选择这张图片文件 console.log(第 ${index 1} 张图片需要手动关联: ${src}); }); return template.innerHTML; }这段代码的意义更多是演示排查路径遍历img标签过滤掉已经是data:开头或http(s)开头的图片剩下的就是需要处理的相对路径图片。完整的自动转换要走 FileReader 逐个读取图片文件再转 base64代码量不小且涉及图片体积膨胀问题base64 会让体积增加约 33%所以大多数生产系统选择「上传图片到服务器替换 src 为线上 URL」而不是 base64。5.2 粘贴网页内容时的隐性 HTMLtext/html与text/plain的双通道从浏览器复制一段带格式的文本再粘贴到富文本编辑器里剪贴板会同时提供多种格式。paste事件里可以取到两种text/html和text/plain。如果编辑器只处理text/plain粘贴的格式全部丢失只处理text/html又可能带上复制源站点的样式类名。一个常见的处理策略是优先尝试text/html但先清洗再回退到text/plaineditor.addEventListener(paste, (event) { event.preventDefault(); const html event.clipboardData.getData(text/html); const plain event.clipboardData.getData(text/plain); if (html) { // 清洗粘贴的 HTML避免带来 on* 属性和 script const cleaned sanitizeHtml(html); document.execCommand(insertHTML, false, cleaned); } else if (plain) { // 无 HTML 时插入纯文本注意换行要转成 br 或分段 const safeText plain.replace(//g, amp;).replace(//g, lt;).replace(//g, gt;); document.execCommand(insertHTML, false, safeText.replace(/\n/g, br)); } });clipboardData.getData(text/html)拿到的是复制源提供的 HTML可能包含源站点的 CSS 类名甚至内联样式所以必须过一遍sanitizeHtml。纯文本路径里replace(//g, amp;)这类转义是必须的否则用户粘贴1 2会被浏览器解析成标签。换行先转br再插入能保证多行文本不会挤成一段。5.3 性能边界大 HTML 字符串注入时的卡顿与崩溃一个 5MB 的 HTML 字符串直接塞进innerHTML浏览器会卡顿甚至崩溃。HTML parser 解析 DOM 是同步主线程操作节点数量大了之后布局和样式计算也会跟着遭殃。一个省事的做法是分段注入function injectLargeHtml(htmlString, targetElement) { // 按 body 标签切分或者按固定长度分段 const chunkSize 100 * 1024; // 每段 100KB const chunks []; for (let i 0; i htmlString.length; i chunkSize) { chunks.push(htmlString.slice(i, i chunkSize)); } targetElement.innerHTML ; let index 0; function appendNext() { if (index chunks.length) { return; } // 分段赋值让浏览器有机会处理其他任务 targetElement.insertAdjacentHTML(beforeend, chunks[index]); index; requestAnimationFrame(appendNext); } requestAnimationFrame(appendNext); }insertAdjacentHTML(beforeend, chunk)是在内部末尾追加不会重建已有 DOM比分段拼接innerHTML性能好。requestAnimationFrame把每次追加放在不同帧里避免一次同步解析阻塞页面。实际操作中这个方案仍有隐患——如果第一段里div标签未闭合后续段落的解析会出错。安全做法是按完整标签边界切分而不是固定字节数切分。5.4 验证互转结果是否无损的检查清单项目上线前用下面几个用例验证互转链路比写一百行断言都管用用例预期结果失败时检查哪里空编辑器保存后再回显编辑器为空无残留br读取前是否清理了空段落粘贴一段带图片的文字再保存图片 URL 能被保存和回显图片是相对路径还是绝对路径加载含script的本地 html脚本不执行标签被移除sanitizeHtml是否覆盖了所有高危标签html 文件为 GBK 编码中文显示正常detectCharset是否识别到了charset声明在文本中间插入 HTML 后按 CtrlZ能撤销回插入前的状态是否用了execCommand(insertHTML)或自己实现了撤销栈这套清单的核心逻辑是互转不是「字符串能放进去再取出来」这么简单而是要验证编码、安全、光标准和 XSS 四个维度同时成立。任何一条不满足用户都会在某个具体操作里遇到诡异问题——有的能复现有的只在特定浏览器或特定 doc 里出现。最后补一个实用技巧开发时可以写一个console.log快捷键一键打印当前编辑器的innerHTML快照格式化后复制到本地 html 文件再用input typefile加载回来。这个「存→读→回显」闭环能帮你快速验证当前这版的互转代码是否真的无损。本文还有配套的精品资源点击获取