企业官网建设流程全解析

简介：面向动易 SiteWeaver6.8 站点维护者与后台管理员的兼容性修复文档，针对旧版编辑器在 IE9、IE10、IE11 下无法正常加载或编辑的问题，提供直接覆盖与手动改写两条处理路径。文档以单个 doc 文件交付，压缩包约 21KB，篇幅紧凑，便于随取随查；内容围绕浏览器版本识别脚本、后台页面兼容声明以及会员中心编辑页的补充设置展开，并强调操作前备份原文件、修改后清理 IE 缓存再复测。文档先说明覆盖法的适用前提与备份注意事项，再逐步交代编辑器脚本中旧版浏览器判断语句的替换方式、后台模板兼容声明的添加位置，以及会员中心编辑页的补充处理；对于容易遗漏的重复代码、缓存影响和修改后仍不生效等情况也给出排查方向。读者可据此定位需注释或替换的旧版 MSIE 判断代码，理解 EmulateIE7 兼容模式的实际作用，掌握后台与会员中心两处入口的排查顺序，减少反复试错。已有 937 人学习，适合仍在使用 SiteWeaver6.8、需要恢复 IE 高版本浏览器编辑能力的运维与建站人员参考。

1. IE11 里点不进编辑器的那一下，暴露的是十多年前的 UA 判断

某公司内网一套跑了多年的 SiteWeaver 6.8 站点，编辑人员换了新电脑，浏览器从 IE8 升到 IE11，后台登录正常、列表正常，唯独点“发布文章”进去以后，编辑器一片白，工具栏按钮点下去没反应，光标也进不去。运维不敢动整套 CMS，因为模板、栏目权限、投稿流程都被二次改过。真正的问题不在浏览器，而在编辑器脚本里那两行按navigator.appVersion抠版本号的代码——IE9 还能蒙混过关，IE10 开始版本号认错，IE11 直接取到null抛异常。这份资源给的就是两条路：整包覆盖，或者手改四个文件、加四行代码，让后台编辑器和会员中心投稿页在 IE9/IE10/IE11 下重新可用。适合还在维护老 ASP 站点、又没有条件整体重构的人。

2. 先把病因定死：IE9/IE10/IE11 在编辑器上留下的三个断层

老站点改造最忌讳“先改再看”。编辑器点不动，可能是版本号解析崩了，可能是事件绑定方式在标准模式下失效，也可能是文档模式变了导致document.all这一批老 API 集体失灵。这三件事在 IE9 之后是同时发生的，只修一处，另外两处照样让你翻车。下面把三条断层一条条拆开，你能对上号，后面改代码才知道每一行在治什么病。

2.1 navigator.appVersion 里已经找不到想要的版本号

老编辑器判断浏览器能力，靠的是从navigator.appVersion里正则抠主版本号。这个字段在 IE8 及以前非常规整，形如4.0 (compatible; MSIE 8.0; Windows NT 5.1; ...)，一条/MSIE (.)/就能拿到8。但 IE10 和 IE11 把这个约定打破了。

IE10 那行最阴：(.)只吃一个字符，MSIE 10.0匹配到的是MSIE 1，返回字符串"1"，不报错，但编辑器以为自己跑在 IE1 上，于是跳过了所有为高版本准备的兼容分支。IE11 更彻底，UA 里根本没有MSIE字样，match()返回null，null[1]立刻抛异常，而这段代码往往写在编辑器初始化的最前面，一崩全崩，表现出来就是“白板 + 按钮无响应”。

所以正确的做法是改用navigator.userAgent全串匹配，并且把版本号取成完整数字而不是单个字符。这一步是基础，不做后面全是白费。

2.2 YUSERONCLICK 与 anonymous()：工具栏点击是怎么丢的

这套编辑器（eWebEditor 系）把每个工具按钮的点击处理存成一个私有属性element.YUSERONCLICK，在页面级的事件里再eval出来执行。老代码长这样：

if (element.YUSERONCLICK) eval(element.YUSERONCLICK + 'anonymous()');

anonymous()是编辑器内部约定的执行入口。在 IE8 的混杂模式下，eval出来的代码运行在一个特殊作用域里，this和事件对象还能兜住；IE9 之后页面默认进入标准模式，eval的间接调用语义变了，anonymous()拿不到事件上下文，点击处理静默失败——不报错，就是没反应，这种“黑匣子”式的表现最耗人。

改法是把标准模式下的执行入口换成onclick(event)，并且用浏览器版本判断把新旧两条路径分开。这里有个容易忽略的细节：这段代码在编辑器里通常出现两次（不同页面各注入一份），只改一处，另一半按钮照样点不动。

2.3 文档模式：IE9 之后不再默认给你 IE7 的 DOM

第三个断层是文档模式。IE9 起默认按标准模式渲染，document.all被弱化、attachEvent让位给addEventListener、window.event在部分场景下拿不到。这套编辑器大量依赖document.all和attachEvent，它不是“写错了”，是当年就照着 IE7 的 DOM 写的。

不改代码硬扛，唯一的办法是让浏览器用 IE7 的文档模式渲染页面，也就是X-UA-Compatible: IE=EmulateIE7。这句 meta 一加，IE9/IE10/IE11 会切回 IE7 的渲染与脚本行为，document.all、attachEvent、window.event全部回来，编辑器那套老逻辑重新成立。

提示：文档模式和 UA 字符串是两件事，但在 IE 上是联动的。IE9/IE10/IE11 进入 IE7 文档模式后，navigator.userAgent会回落成带MSIE 7.0的形式，这恰好让 2.2 节里那段版本判断重新走上老分支。理解这一点，后面排查“为什么有的页面改了有效、有的没效”才不会绕圈。

3. 覆盖还是手改：先看清四个文件各管什么

资源给了两条路径，一条是整包覆盖，一条是手动改四行代码。很多人图快直接覆盖，结果站点后台菜单顺序变了、投稿流程节点丢了——因为覆盖包是按“原版未改动”的文件做的，你的站点只要被二次开发过，覆盖就等于把那些改动冲掉。这一章先把两条路径的边界划清楚，再决定动手方式，顺序反了就是给自己找麻烦。

3.1 两条路径的适用边界

判断标准只有一条：这四个文件你有没有动过。没动过，覆盖最省事；动过任何一处，甚至只是改过一句提示语，都建议手改。

覆盖前必须备份，这不是客套话。备份范围不只是被覆盖的那四个文件，还包括同目录下的同名.bak、Admin目录的整层结构，以及数据库里跟后台菜单相关的配置表——文件回退了但配置没回退，后台照样进不去。

3.2 一次到位的备份动作

老站点的目录往往十几年没整理过，备份不要用“复制粘贴到桌面”这种方式。走命令行，把校验也一并做掉。

# 假设站点根目录为 /srv/site，后台目录为 /srv/site/admin # 备份到带时间戳的目录，避免多次备份互相覆盖 STAMP=$(date +%Y%m%d%H%M) mkdir -p /srv/backup/$STAMP # 备份编辑器主文件和后台入口文件 cp -p /srv/site/editor.asp /srv/backup/$STAMP/ cp -p /srv/site/admin/admin_article.asp /srv/backup/$STAMP/ cp -p /srv/site/admin/admin_index.asp /srv/backup/$STAMP/ cp -p /srv/site/user/user_article.asp /srv/backup/$STAMP/ # 记录原始文件的大小与修改时间，回退时用来核对是否真的还原了 ls -l /srv/backup/$STAMP/ > /srv/backup/$STAMP/manifest.txt

cp -p的-p保留时间戳和权限，老站点的 ASP 文件常被人用不同账号上传过，权限不一致会导致 IIS 匿名账户读不了；manifest.txt是后悔药，回退时对一眼大小就知道有没有还原到位。Windows 环境把cp -p换成xcopy /K /O /Y，思路一样。

3.3 四个文件的职责划分

改动清单不长，但要清楚每个文件改的是哪一层，出问题时才好定位。

会员中心那个文件经常被漏掉，因为后台能用了大家就以为完事，结果投稿用户那边还是白板。四个文件、两类改动：一类改脚本（只在一个文件里），一类加 meta（三个文件各加一行）。

4. Editor.asp 的两处改造：UA 解析和工具栏事件

Editor.asp是核心，也是唯一需要动 JavaScript 的文件。整个改造只涉及两处：开头附近的版本号解析，和后面的事件绑定判断。改的时候用记事本打开，保存时务必选 ANSI 编码——这个文件是 GB2312 环境下跑的，存成 UTF-8 会带 BOM，ASP 输出中文立刻变乱码，这个坑后面还会专门讲。

4.1 先定位，再替换：版本号解析

用查找功能搜BrowserInfo.MajorVer，能找到两行紧挨着的赋值：

// 改造前：在 IE10 下拿到的 MajorVer 是 1，在 IE11 下直接抛异常 BrowserInfo.MajorVer = navigator.appVersion.match(/MSIE (.)/)[1]; BrowserInfo.MinorVer = navigator.appVersion.match(/MSIE .\.(.)/)[1];

把这两行注释掉或删除，换成基于userAgent的完整匹配：

// 改造后：取完整版本号，并对 IE11 的 Trident 标识做兜底 var ua = navigator.userAgent.toLowerCase(); if (ua.match(/msie ([\d.]+)/)) { // IE10 及以前：UA 里保留 MSIE 10.0 这类标识 BrowserInfo.MajorVer = ua.match(/msie ([\d.]+)/)[1]; } else if (ua.match(/trident\/7\.0/) && ua.match(/rv:11\.0/)) { // IE11：UA 里没有 MSIE，只能靠 Trident/7.0 + rv:11.0 两个标识联合判定 BrowserInfo.MajorVer = "11"; } else { // 非 IE 或其他情况，给一个安全默认值，避免后续取值 undefined BrowserInfo.MajorVer = "0"; }

三个参数点值得说清楚。([\d.]+)抓的是完整数字串，IE10 拿到的就是"10"，不再是"1"；trident\/7\.0和rv:11\.0必须同时判，因为单看Trident/7.0会把部分兼容模式也误判成 IE11；最后那个"0"兜底看着多余，实际上很关键——MajorVer后面会被拿去做数值比较，undefined参与比较大小时行为不确定，给个明确的0反而让老代码走“低版本兼容分支”，这正是我们想要的。

MinorVer在很多版本里没被真正用到，删掉不影响，但如果文件后段有引用，补一行BrowserInfo.MinorVer = "0";就行，别留着undefined。

4.2 事件绑定：两处一样的代码都要改

继续查找YUSERONCLICK，会命中两处完全相同的语句。这两处分别对应编辑器在不同页面上下文里的注入逻辑，必须一起改，改一处等于没改。

// 改造前：只在 IE7 的混杂模式语义下成立 if (element.YUSERONCLICK) eval(element.YUSERONCLICK + 'anonymous()');

// 改造后：按文档模式分流，标准模式下用 onclick(event) 传事件对象 if (ua.match(/msie (7|8|9|10|11|12)\./) != null || ua.match(/trident\/7\.0/)) { if (element.YUSERONCLICK) { eval(element.YUSERONCLICK + "onclick(event)"); } } else { if (element.YUSERONCLICK) { eval(element.YUSERONCLICK + "anonymous()"); } }

改动的逻辑是把“新旧执行入口”的判定条件从浏览器版本扩展到文档模式。原资源里只写了/MSIE (7|8|9|10|11|12)\./i，问题在于 IE11 的 UA 里压根没有MSIE，这个正则匹配不到，代码会掉进else走anonymous()，仍然失效。所以后面那个|| ua.match(/trident\/7\.0/)不是画蛇添足，是补上 IE11 的缺口。

(7|8|9|10|11|12)里的12是当年给后续版本预留的位置，现在看属于“留着无害”的写法。分组顺序也讲究：7|8|9|10|11里1开头的分支排在前面时，正则会在MSIE 10.上先试1，发现后面不是.再回溯到10，能匹配成功；写成(10|11|7|8|9)可读性更好，但结果一样。

改完这两处，Editor.asp就结束了。别急着测，先把 meta 那三处加上，四件事一起改完再统一验证，否则你会分不清是脚本生效了还是文档模式救的场。

5. 文档模式那根救命稻草：三处 meta 的加法与验证

脚本改对了只解决“版本号认不出”和“事件入口选错”两个问题，编辑器里依赖document.all的那部分仍然需要 IE7 的文档模式。这一章把三个文件的 meta 加法写清楚，重点是 ASP 拼接里的引号转义和静态 HTML 的区别，这两处写错都很隐蔽。

5.1 Admin 两个文件：ASP 拼接中的双引号要写两遍

后台这两个文件是 ASP 动态输出的，X-UA-Compatible不能直接写死在 HTML 里，得用Response.Write拼出去。查找：

Response.Write "<meta http-equiv='Content-Type' content='text/html; charset=gb2312'>" & vbCrLf

在这一行下面插入：

' 通知 IE8 及以上版本使用 IE7 兼容模式渲染后台页面 Response.Write "<meta http-equiv=""X-UA-Compatible"" content=""IE=EmulateIE7"" >" & vbCrLf

VBScript 字符串里没有反斜杠转义，双引号要写成两个""才能输出一个。写成"X-UA-Compatible"会直接语法错误，页面报 500，这时候你以为是改坏了，其实是少写了一个引号。另一种常见错法是写成""IE=EmulateIE7""外层再包一层，输出后 content 变成带引号的字符串，IE 直接忽略这条 meta。

Admin_Article.asp和Admin_Index.asp两处都要加，一处是文章编辑页本身，一处是后台框架主入口。框架页的文档模式决定了 iframe 内页面的默认模式，只改内页不改框架，效果会打折扣。

5.2 会员中心：静态模板里直接写 meta

User_Article.asp是另一套写法，meta 是静态 HTML，查找：

<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />

在下面插入一行：

<!-- 会员中心投稿页同样回落到 IE7 文档模式，注意这一行必须在使用任何脚本之前 --> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

静态写法不需要转义，双引号直接写。位置很关键：这条 meta 必须出现在<head>内、任何<script>之前，IE 只认文档头部靠前的一段（早期版本有 1024 字节的窗口限制），放到</head>前面基本就失效了。有些老模板的 head 里先塞了一大段内联脚本，这时把 meta 提到最前面就行。

5.3 用 F12 验证文档模式，别靠肉眼猜

改完必须打开 F12 工具确认文档模式，而不是只看“能不能点”。IE10/IE11 的 F12 里，“文档模式”一栏显示IE7 标准或IE5 文档模式(quirks)说明 meta 生效了；显示IE11 默认说明没生效。

如果显示的是IE5 文档模式(quirks)而布局错乱，把IE=EmulateIE7换成IE=7试试：EmulateIE7尊重页面 doctype，IE=7则强制用 IE7 标准模式，不看 doctype。两种写法各有适用面，老 ASP 页面没有 doctype 的居多，EmulateIE7落到 quirks 反而是最接近当年运行环境的状态。

注意：IE 的兼容性视图站点列表优先级高于 meta。如果这台机器曾经为站点手动添加过“在兼容性视图中显示”，F12 里的模式可能被列表覆盖，测试前先在工具菜单里把该站点从列表移除。

6. 改完还是点不动：五条排查记录

这套改动看起来只有四行代码，实际现场出问题的比例不低，原因多数不在代码本身，而在缓存、覆盖范围和多入口。下面五条按“最常见→最隐蔽”排，遇到问题照着往下走，别跳步。

6.1 改了文件，刷新后毫无变化

现象：文件时间戳是新的，代码确实改了，浏览器刷新后表现和改之前一模一样。

原因：三层缓存叠在一起。ASP 页面本身会被 IIS 输出缓存，站点如果是多台服务器做负载，你只改了一台；浏览器端 IE 对Editor.asp这种静态化程度高的页面缓存很顽固。

解决：先关掉所有 IE 窗口（不是关标签页），清空临时文件；服务端回收对应应用程序池，让 ASP 重新编译；多机环境逐台比对文件大小和修改时间，manifest.txt这时候就派上用场了。改完立刻按 Ctrl+F5 强刷，别用普通刷新。

6.2 后台能编辑了，会员中心投稿还是白板

现象：管理员发文一切正常，普通会员点“投稿”进编辑器仍然空白。

原因：后台和会员中心是两套入口，加载的编辑器外壳不是同一个文件。后台走Admin_Article.asp，会员中心走User目录下的User_Article.asp，meta 只加了后台那两处。

解决：补上User_Article.asp的 meta，位置在 Content-Type 那一行下面。同时确认会员中心那套模板里有没有另起一个 iframe 加载编辑器——如果有，iframe 内部的页面也得有自己的 meta，父页面的声明不会继承进去。

6.3 IE11 下后台正常，个别页面按钮仍然没反应

现象：大部分页面编辑器可用，切到某个特定栏目或某类文章时，工具栏又变哑巴。

原因：编辑器的入口脚本可能被那个页面单独引入了一次，或者该页面在 iframe 里加载了独立的Editor.asp，而 iframe 内的文档没有继承父页面的文档模式，仍以 IE11 标准模式运行，ua.match(/msie .../)匹配不到，走了anonymous()分支。

解决：确认Editor.asp自身也输出了X-UA-Compatible。如果它只被当组件引入、不输出完整 HTML 头，就在引入它的那个外层页面统一加；或者保留 4.2 节里补的trident\/7\.0判断，让 IE11 即使没回落文档模式也能走对分支。两条路选一条，双保险也不冲突。

6.4 覆盖之后，后台菜单少了、投稿流程断了

现象：编辑器好了，但后台左侧菜单少了几项，或者投稿文章的审核节点不见了。

原因：覆盖包里的文件是按出厂状态准备的，站点之前的二次开发（菜单项、权限节点、字段扩展）全在被覆盖的文件里，一起被冲掉了。

解决：立刻从备份还原，改用 4.x 的手改法，只动那四行代码。还原时注意 ASP 文件的权限，xcopy /O或cp -p保留下来的权限如果和 IIS 匿名账户不匹配，页面会报 401 而不是显示内容。

6.5 修改后页面中文变乱码

现象：编辑器能用了，但后台的提示文字、按钮文字变成方块或问号。

原因：用记事本另存时选了 UTF-8，文件开头被写入 BOM，而Editor.asp是 GB2312 环境，ASP 解析器把 BOM 当正文输出，页面前面多出三个不可见字符，charset 声明失效。

解决：重新用记事本打开，另存为时编码选 ANSI，覆盖保存。改之前可以先看文件属性，原文件如果是 ANSI，改完必须还是 ANSI。用 VS Code 的话，右下角编码切到GB2312再保存，别用UTF-8 with BOM。

7. 上线前走一遍：UA 打印、三档回归和一个降级预案

改完直接交付是最容易翻车的做法，因为编辑器能不能用，光看“点得动”不够，还要确认它在不同文档模式下都稳定。我一般会在后台登录页临时贴一段 UA 打印脚本，十行不到，一眼就能判断当前机器到底跑在什么模式里：

// 临时贴在后台登录页底部，交付前删掉 (function () { var ua = navigator.userAgent; var mode = document.documentMode || 'unknown'; console.log('UA:', ua); console.log('documentMode:', mode); // 7 表示已回落到 IE7 文档模式 console.log('MSIE 命中:', /msie ([\d.]+)/i.test(ua)); console.log('Trident 命中:', /trident\/7\.0/i.test(ua)); }());

documentMode是最直接的判据：显示7说明 meta 生效了；显示11说明页面根本没回落，这时候别怀疑编辑器脚本，先回去查 meta 的位置和引号。控制台里MSIE 命中为false而Trident 命中为true，就是典型的 IE11 标准模式，需要 4.2 节那个trident兜底。

回归测试至少走三档：把 F12 的文档模式手动切到IE7、IE9、IE11各点一遍编辑器——工具栏加粗、插入图片、插入表格、源码切换这四个动作最能暴露问题，因为它们分别走了事件绑定、弹窗、DOM 操作和脚本注入四条路径。三档都能过，再交给编辑人员试用。

最后留一个降级预案。这类老站点的最终归宿都是换编辑器或换平台，但在那之前，IE=EmulateIE7是成本最低的续命方案。如果哪天发现某个 IE 版本怎么调都不行，先看这台机器有没有被加进兼容性视图站点列表——列表的优先级高于 meta，会把你所有的声明盖掉。我自己就吃过一次亏：在一台测试机上折腾了两个小时，最后发现是半年前为了别的系统手动加过列表项。从那以后我每次动这类站点，都先把兼容性视图列表清一遍再开始测。希望帮到你。

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