企业官网建设流程全解析

简介：面向Web开发者的 eWebEditor V12.0 for ASP 多语言商业版，是一套可直接部署的浏览器端所见即所得 HTML 编辑器，用于将传统多行文本框替换为可视化富文本输入区，让内容编辑人员像使用 Word 一样排版并发布 HTML 网页，适合为 CMS、后台管理系统或既有 ASP 站点补齐内容录入能力的场景。压缩包共 753 个文件、约 16.99MB，其中 29 个 ASP 服务端脚本承担配置、上传、登录验证与文件浏览等后端逻辑，131 个 CSS 与 22 个 JS 文件共同构成编辑器皮肤和交互行为，GIF、JPG、PNG 等图像资源五百余个提供工具栏图标与示例素材，另有 HTM 示例页、TXT 说明及可执行程序辅助安装调试。多语言切换与 Word 导入等商业版特性一并保留，可作为二次开发底本。已有 443 人学习下载，适合需要研究富文本编辑器内部结构或进行 ASP 项目集成的开发者参考。

1. 一个还在运行 ASP 的老站，为什么会重新翻出 eWebEditor 多语言商业版

上周有人把一个站点的后台扔给我，管理界面还是十几年前的表格布局，但业务仍在运行，表单里必须要有富文本编辑。技术栈固定为 IIS + 经典 ASP，不能新增 Node 服务，也不能更换框架，能选的方案很少。翻了一圈，最后从资源盘里翻出的就是这份 eWebEditor 多语言商业版压缩包：解包即用、纯 ASP 服务端、自带多套语言包和皮肤，上传、表情、表格、源码切换这些后台高频功能都有现成实现。

它不适合“从零开始建新站”的人，适合三类人：维护存量 ASP 项目的、要给老系统加编辑能力但排不了重构排期的、以及需要在同一套后台里切换简繁中文和英文界面的。下面按我实际部署的顺序拆：先看清目录和运行环境，再接入表单打通保存链路，然后处理多语言和编码，最后把上传与内容过滤固定成固定动作。容易出问题的地方会单独列出一章。

2. 解包先认结构：它是 iframe 组件，不是能 include 进来的类库

很多人第一次接触这套东西会误解：以为和现在的编辑器一样，引一个 js、写个new Editor()就完事。它不是。eWebEditor 的 ASP 版本本质上是“一个独立的编辑页面 + 父页面里的 iframe + 一个同名表单域”的组合。编辑器自己是一个完整页面，工具栏、对话框、上传弹窗全在它内部；父页面只负责把 iframe 摆好，提交时把内容同步到一个普通表单字段里，服务端拿到的就是一段 HTML 字符串。

理解这一点，后面所有问题都好解释：路径问题、跨域问题、样式冲突、提交丢内容，根子都在“它是个独立的 iframe 页面”上。

2.1 运行环境与三个前置条件

在动任何文件之前，先把运行环境确认清楚。这套组件对服务端的要求不高，但对 IIS 的配置项很敏感，少开一个就是白屏或者 500。

应用池用经典模式还是集成模式，我一般先用经典模式跑通，再切集成模式验证一遍。集成模式下有些老版本的路径拼接会读出问题，提前试出来比上线后才发现好。

提示：如果服务器是 64 位且组件里有 32 位 COM 依赖，需要在应用池里把“启用 32 位应用程序”打开。纯 ASP 脚本版本一般用不到，但打包版本里若带了第三方上传组件就会踩到。

2.2 目录里哪些要改，哪些不要动

解包之后先不要急着往站点里复制。我习惯先在本地开一个独立站点目录，把整个包原样放进去，用包内自带的示例页跑通，再谈迁移。原因很简单：示例页里已经写好了正确的 iframe 参数，是最可靠的参考。

按常见打包结构，目录大致分成这几类：

真正需要改的只有三处：配置、上传处理、语言选择。主入口页我基本不碰，因为一旦改动，后续换版本时会很麻烦，而且商业版的授权校验有时和入口页绑在一起。

2.3 先跑示例页，再改任何一行

这一步很多人跳过，结果是后面所有问题都分不清是“组件本身不行”还是“自己接错了”。我的顺序是：

1. 把整包放到D:\sites\editor-demo\下，IIS 建一个独立站点指向它，绑本地端口。
2. 找到包内的示例页，直接浏览器打开。
3. 确认三件事：工具栏出来了、能打字、点图片上传能弹窗。
4. 打开浏览器开发者工具，看 Network 里编辑页返回的状态码是不是 200，有没有静态资源 404。

这三件事全通过，说明运行环境和组件本身没问题，剩下的都是接入问题。任何一件不通过，先解决它，不要往下走。我见过有人示例页都没跑通就开始往正式项目里嵌，最后在一堆变量里排查一整天，容易出问题的地方全在里面。

如果示例页白屏但状态码是 200，通常是编码或脚本报错。F12 的 Console 里会有具体行号；如果是 500，把 IIS 的“向客户端发送错误信息”临时打开，看 ASP 报的具体文件和第几行，比猜快得多。

3. 接进表单：从 iframe 摆位到 Request 取值的完整链路

结构认清了，接下来是真正的集成。这一章给的是能直接抄的骨架：编辑页怎么摆、保存页怎么取、编辑已有数据怎么回显。三步走完，一个能用的后台富文本字段就有了。

3.1 编辑页：一个最小可用的表单骨架

下面这段是我常用的骨架，把编辑器包在一个函数里，页面上要几个字段就调几次。注意表单必须是真正的form提交，不要一上来就 AJAX，先把同步链路验证通过。

<!-- edit.asp：编辑页骨架 --> <form name="frmArticle" method="post" action="save.asp"> <input type="hidden" name="id" value="<%=Server.HTMLEncode(articleId)%>" /> <div class="field"> <label>标题</label> <input type="text" name="title" value="<%=Server.HTMLEncode(title)%>" /> </div> <div class="field"> <label>正文</label> <!-- id 决定表单域名字，style 决定皮肤，两者都要和服务端对齐 --> <iframe id="eWebEditor_content" src="/ewebeditor/ewebeditor.asp?id=content&style=standard" frameborder="0" scrolling="no" width="100%" height="420"></iframe> </div> <input type="submit" value="保存" /> </form>

逻辑说明：id参数是这套组件最关键的一个值，它在父窗口里生成一个同名的隐藏表单域，提交时把编辑区内的 HTML 写进去。所以id=content就意味着保存页要用Request("content")取值，两边必须完全一致，大小写也别乱写。

参数说明：style对应皮肤目录名，写错就是一个没有样式的裸工具栏；width/height建议用像素值而不是百分比，部分老版本在百分比下计算工具栏换行会错位；scrolling="no"要留着，否则右侧会多出一条滚动条。路径最好用站点根相对路径（以/开头），用相对路径时，一旦页面在二级目录里就会 404，这是高频踩坑点。

3.2 保存页：Request 取值与入库前的处理

保存页看起来简单，但有几个地方不注意，数据会以各种奇怪的方式坏掉。

<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%> <% Option Explicit Response.Charset = "utf-8" Session.CodePage = 65001 Dim content, title, articleId articleId = Trim(Request.Form("id")) title = Trim(Request.Form("title")) content = Request.Form("content") ' 注意用 Form 集合，别用 Request("content") ' 空内容保护：编辑器在什么都没输入时可能返回空串或一个空段落 If Len(Trim(content)) = 0 Or content = "<p></p>" Then Response.Write "正文不能为空" Response.End End If ' 长度上限保护，防止超长内容把字段撑爆 If Len(content) > 200000 Then Response.Write "正文超出长度限制" Response.End End If %>

逻辑说明：这里刻意用Request.Form而不是Request。Request("content")会按 QueryString → Form → Cookie → ServerVariable 的顺序取值，只要 URL 上带一个?content=xxx就能覆盖表单内容，是个很容易被忽略的注入点。所有表单字段我都建议显式指定集合。

参数说明：CODEPAGE="65001"和Response.Charset = "utf-8"必须成套出现，只改一个会出现“页面正常但数据库里是乱码”或者“数据库正常但页面乱码”的不一致状态。长度上限按你的数据库字段类型来定，ntext和nvarchar(max)的行为不一样，ntext在部分驱动下写入超长会被静默截断。

入库时我一般直接存原始 HTML，不做转义。转义放在输出环节，这样编辑器回显时不用反转义，数据保持一份原始形态。这条规则要写进注释，不然半年后接手的人一定会在这里加一次Server.HTMLEncode，然后所有富文本都变成源码。

3.3 回显：把数据库里的 HTML 安全塞回编辑区

编辑已有文章时，需要把内容重新灌进编辑器。这一步不能靠 iframe 的src传参（内容一长就超 URL 长度限制），常见做法是父页面提交后由编辑器自己拉取，或者用页面内的脚本注入。我用的方式是在编辑页判断有没有初始值，有就调编辑器暴露的赋值入口。

// edit.asp 底部：有初始内容时灌进编辑器 (function () { var initial = document.getElementById("initialContent"); if (!initial) return; var frame = document.getElementById("eWebEditor_content"); if (!frame) return; frame.onload = function () { try { var w = frame.contentWindow; // 不同打包版本入口名可能是 getHTML/setHTML、gethtml/sethtml var setter = w.setHTML || w.SetHTML || w.setHtml; if (typeof setter === "function") { setter.call(w, initial.value); } } catch (e) { // 拿不到入口时不要抛错，退回到用户手动粘贴 if (window.console) console.warn("editor setHTML unavailable:", e.message); } }; })();

逻辑说明：把初始内容放在一个type="hidden"的 textarea 里，比直接内联进 JS 字符串安全得多——正文里的引号、换行、</script>都不会破坏脚本结构。赋值动作绑在 iframe 的onload上，早于加载完成调用会拿不到内部对象。

参数说明：setHTML的入口名在不同打包版本间确实存在差异，所以这里用||串了三套写法并用typeof判定，取不到就静默降级，不阻塞页面。这是血泪经验：直接写死一个方法名，换版本就报undefined is not a function，而用户只会看到编辑区空白。

注意：注入的内容必须来自可信数据源（自己的数据库）。如果有人能把外部 HTML 写进这个字段，等于把 XSS 直接送进后台，详见第 6 章。

3.4 提交方式变了怎么办：AJAX 场景下的手动同步

用普通表单提交，编辑器自己的钩子会处理同步，不用管。但后台改版常用 AJAX 提交，这时同步链路就断了——服务端收到的是空字符串，现象是“保存成功但内容全没了”。

处理办法是在提交前手动触发一次同步。稳妥的写法是把 iframe 内部的隐藏域值读出来，读不到就用兜底方案：

function syncEditorToForm(fieldName) { var frame = document.getElementById("eWebEditor_" + fieldName); var holder = document.getElementById(fieldName + "_backup"); if (!frame) return ""; var html = ""; try { var w = frame.contentWindow; var getter = w.getHTML || w.GetHTML || w.getHtml; if (typeof getter === "function") html = getter.call(w); } catch (e) { html = ""; } // 兜底：从 iframe 内部文档里直接捞编辑区 HTML if (!html) { try { var doc = frame.contentWindow.document; var body = doc.getElementById("eWebEditor_body") || doc.body; html = body ? body.innerHTML : ""; } catch (e2) { html = ""; } } if (holder) holder.value = html; return html; }

逻辑说明：先走官方入口，失败再直接读 iframe 内文档的编辑区节点。两层兜底的意义在于，官方入口名会随版本变，但“编辑区一定在某处”这个事实不会变。把结果写进一个备用隐藏域，AJAX 提交时从备用域取值，比临时拼 payload 稳。

参数说明：fieldName要和你 iframe 的id参数保持一致；备用域命名用_backup后缀区分，不要和编辑器自己生成的同名域冲突，否则服务端可能取到旧值。

4. 多语言与编码：语言包切换和 GB2312 / UTF-8 的取舍

“多语言商业版”这个卖点，落到实操上其实就两件事：界面文字的语种切换，以及页面编码的统一。前者配置一下就能用，后者是最容易出问题的地方——同一个站点里，编辑器是 GB2312、主站是 UTF-8，中文就会在某个环节变成问号。

4.1 语言包怎么切：三处必须对齐

语言切换不是改一个开关就完事。它涉及三个位置：配置里的默认语言、iframe 参数里的语言指定、以及父页面的字符集声明。这三处任意一处不一致，就会出现“工具栏是英文但弹窗是中文”这种半吊子状态。

常见做法是在配置里设默认语言，然后在 iframe 的src上显式带语言参数，覆盖默认值，这样同一套组件可以在一套后台里服务多语言站点：

<!-- 按当前后台语种动态拼 src，langCode 来自登录用户的偏好设置 --> <% Dim langCode, editorSrc langCode = "zh-cn" If Not IsEmpty(Session("AdminLang")) Then langCode = Session("AdminLang") editorSrc = "/ewebeditor/ewebeditor.asp?id=content&style=standard&lang=" & Server.URLEncode(langCode) %> <iframe id="eWebEditor_content" src="<%=editorSrc%>" frameborder="0" scrolling="no" width="100%" height="420"></iframe>

逻辑说明：语言从会话里取，用户在后台切换语种时不用改任何配置文件。Server.URLEncode不能省，语言代码里带连字符虽然多数情况下没事，但拼 URL 时统一编码是习惯问题，能省掉一类难查的 bug。

参数说明：语言代码要和语言包目录里的文件名严格对应，比如目录里是zh-cn.js，参数就必须是zh-cn，写成zh_CN就取不到，界面会退回默认语言而不报错——这种“静默失败”最难查，因为页面看起来是好的，只是语言不对。

语言包本身是纯文本的键值对，新增语种的方式就是复制一份现有语言包，把值逐个翻译。这里有个细节：不要改键名，也不要在翻译时顺手改标点。编辑器的部分提示语是拼接出来的（比如“文件大小超过 X KB”），键名改了会出现提示语只显示半句的情况。

4.2 编码统一：三种情况，三条路

编码这块我给一个判断顺序，按这个顺序走基本不会错。

第一种情况：主站是 UTF-8，编辑器也用 UTF-8。最省事。确认三件事：ASP 文件头有CODEPAGE="65001"、页面有<meta charset="utf-8">、配置文件另存为 UTF-8 无 BOM。注意是“无 BOM”，带 BOM 的配置文件在 ASP 里会在响应头之前输出三个字节，导致Response.Charset设置失败，页面变乱码。

第二种情况：主站是 GB2312，编辑器保持默认。这套组件的很多打包默认就是 GB2312，直接沿用最稳。此时父页面用<meta http-equiv="Content-Type" content="text/html; charset=gb2312">，保存页把CODEPAGE改成 936，Response.Charset = "gb2312"。不要试图混用，GB2312 页面里嵌 UTF-8 的 iframe，编辑器内部的中文提示会全变问号。

第三种情况：主站 UTF-8，但历史数据是 GB2312。这是最麻烦的，也是存量项目最常见的。我的处理是分两步：读出来的老数据先做一次编码转换再灌进编辑器，写回去的时候统一按 UTF-8 存。转换用ADODB.Stream比较稳，比字符串函数靠谱：

<% ' GB2312 字节流转 UTF-8 字符串（处理历史数据回显） Function GBToUTF8(byVal gbText) Dim st Set st = Server.CreateObject("ADODB.Stream") st.Type = 2 ' 2 = 文本流 st.Charset = "gb2312" st.Open st.WriteText gbText st.Position = 0 st.Charset = "utf-8" GBToUTF8 = st.ReadText() st.Close Set st = Nothing End Function %>

逻辑说明：ADODB.Stream的Charset可以在同一个流上切换，切换的瞬间流内字节会按新字符集重新解释，这是做编码转换最省代码的方式。注意转换前要把Position归零，否则读到的是空。

参数说明：Type = 2是文本流，Type = 1是二进制流，这里必须用 2。Charset的取值要用系统认识的名称，gb2312在多数环境等价于gbk，但如果数据里有生僻字，建议直接写gbk，覆盖面更广。

4.3 皮肤与工具栏：把不用的按钮去掉

后台编辑器的工具栏不是越全越好。给编辑人员用的界面，我一般只留：加粗斜体下划线、字体字号、颜色、对齐、有序无序列表、链接、图片、表格、清除格式、源码切换。表情、媒体、全屏这些在后台场景里用得少，反而占位置。

配置方式是在配置文件里改按钮组字符串，把按钮代号按顺序写进去。这一步没有代码，但要提醒一个容易忽略的点：按钮组里引用的对话框，如果对应文件被删了，点按钮会弹出一个空白窗口而不是报错。所以删按钮之前，先确认对应的对话框目录还在不在，别顺手清理“看起来没用”的文件夹。

提示：改完配置一定要清浏览器缓存再验证。配置常被浏览器缓存成静态资源，改完看不到效果，很多人会以为是配置写错了，反复改，最后发现是缓存。

5. 避坑与排查：上传、路径、兼容的五个出错场景

这一章是我自己踩过、也帮别人排查过的五类问题，按现象、原因、解决三段写。遇到类似症状，先对照这里，能省掉大半天。

5.1 上传提示成功，图片却是 404

现象：点图片上传，弹窗显示上传成功，编辑器里图片也显示出来了，但保存后前台打开是红叉，查看路径是/ewebeditor/uploadfiles/2024/xxx.jpg，直接访问 404。

原因：两件事叠在一起。一是上传目录的物理路径配置用了相对路径，而上传处理页所在的目录层级和主站不一致，文件被写到了另一个目录；二是编辑器返回的图片 URL 是相对路径，前台页面在二级目录下时解析出的绝对路径和实际存储位置对不上。

解决：把上传保存路径改成基于Server.MapPath("/")的绝对路径，URL 前缀单独配置成站点根相对路径。改完先手动传一张图，用 FTP 或资源管理器确认文件到底落在哪，再对 URL 做一次拼接验证。这一步我建议做成固定动作：每次换部署环境都验证一次上传落点，不要假设。

5.2 非 IE 浏览器下工具栏变灰或不显示

现象：IE 里一切正常，Chrome 或新版 Edge 打开，工具栏按钮是灰的，或者整个编辑区不渲染，F12 里一堆document.selection is not defined之类的报错。

原因：这套组件的历史实现大量依赖 IE 专有的 DOM 接口和execCommand行为，不同打包版本对标准浏览器的兼容程度差异很大。有的版本会做降级，有的不会。

解决：先确认你手上的版本在目标浏览器里到底支持到什么程度——用一个干净页面单独引编辑器测，不要混在业务页面里测。如果确实不支持，可选的路有两条：一是给站点加X-UA-Compatible让新版 Edge 走 IE 兼容渲染，代价是整站渲染模式被锁定；二是在后台里对编辑器场景保留兼容模式，其他页面不动。第一条是玄学，不同 Windows 补丁版本表现不一样，上线前必须在真实终端上验。

5.3 提交后内容丢失，只剩一对空段落标签

现象：编辑区明明打了一大段字，提交后数据库里只有<p></p>或者干脆是空字符串。

原因：三个可能。第一，表单域名字和 iframe 的id参数不一致，编辑器生成的隐藏域名字对不上，服务端取到空。第二，提交按钮用了type="button"加 JS 跳转，绕过了编辑器自己的同步钩子。第三，表单里嵌套了另一个form，浏览器解析时把内层 form 丢掉了，隐藏域没进入提交集合。

解决：先在保存页把Request.Form的所有键打印出来看一眼，确认content这个键到底在不在。在，说明同步没问题，问题在取值或入库；不在，往 iframe 的id和表单结构上查。表单嵌套这个坑特别隐蔽，因为页面视觉上完全正常。

5.4 本地测好的编辑器，换到正式域名打开是空白

现象：本地开发和测试环境一切正常，部署到正式域名后，编辑区空白或者弹一个提示，其他页面正常。

原因：商业版按授权信息里的域名或 IP 做校验。测试域名和生产域名不一致，就过不了校验。这不是 bug，是授权机制。

解决：先确认采购的授权覆盖范围，包括域名数量、是否含子域名、是否限制 IP。需要扩容就走正规渠道补授权，别在这上面绕，绕过去的方案在上线后迟早出问题，而且排查成本极高——因为现象是“空白”，不会告诉你原因。

5.5 多语言切换后，弹窗里的按钮文字是乱码

现象：主界面语言正常，点开图片上传弹窗，里面的“浏览”“上传”变成了乱码方块。

原因：语言包文件本身的编码和页面声明的编码不一致。主语言包可能是 UTF-8 存的，弹窗用的那份是 GB2312 存的，页面按 UTF-8 解释 GB2312 字节就成乱码了。

解决：把语言包目录下所有文件统一另存为同一种编码，并和页面CODEPAGE保持一致。批量处理时注意别存成带 BOM 的 UTF-8。验一遍的方式很简单：逐个弹窗点开看，别只验主界面。

6. 加固：把上传白名单和内容过滤做成固定动作

这套组件的上传处理是整条链路里最需要动手改的地方。默认配置为了“能用”，类型限制通常比较宽松，而它又是暴露在后台的公网入口，被当成文件上传跳板是老系统最常见的事故。我现在的习惯是：拿到包的第一件事不是接页面，而是先把上传处理页打开，把白名单和落点改掉。

类型校验不要只看扩展名。做法是取扩展名做白名单，同时校验文件的 MIME 头，两者都过才落盘。白名单只留业务真正需要的：jpg、png、gif、pdf。asp、asa、cer、cdx这些必须显式拒绝，光靠“不在白名单里就拒绝”还不够，有些服务器配置下大小写混写、加尾点、加空格都能绕过扩展名判断，所以扩展名要先规范化再比对。

落点也有讲究。上传目录不要给脚本执行权限，IIS 里对该目录设置“处理程序”只保留静态文件；更进一步的做法是把文件存到站点根目录之外，通过一个带权限校验的下载页读出来。后者改动大一些，但一次改完省掉后面所有提心吊胆。

内容过滤放在写入数据库之前，而不是输出时。理由很实际：输出点太多，前台列表、详情页、RSS、App 接口，漏一个就是一个洞；写入点只有一个，守住就行。过滤分两层，一层是危险的标签和属性（script、iframe、on*事件属性、javascript:协议），一层是样式里的expression。这活不用自己写正则，用成熟的白名单过滤库更稳，正则写不全是常态。

从那以后我每次接这类老组件，都会先跑一遍“示例页验证 → 上传落点验证 → 白名单验证”这三步，再动业务代码。顺序反了，后面所有问题都会混在一起，排查成本翻好几倍。希望帮到你。

本文还有配套的精品资源，点击获取