简介：动易SiteWeaver6.8后台编辑器在IE9、IE10、IE11下无法正常编辑，是维护老站点的常见难题。这份方案面向动易站点管理员与二次开发人员，给出两种修复路径：一是直接覆盖Editor.asp、Admin_Article.asp、Admin_Index.asp等文件，便于快速搞定；二是手动修改，明确写出需查找的原始代码位置、删除或注释方式，以及新增的兼容代码，同时提醒操作前先做好备份。两种方法都围绕编辑器核心文件展开，避免盲目替换带来的风险。除后台外，文档还补充了会员中心编辑器在IE10/IE11下不能浏览的处理方法，通过添加X-UA-Compatible元标记让会员中心也能正常编辑。全包仅有1个doc文件，压缩包大小21KB，步骤清晰、可直接照做。目前已有934人学习下载，对于仍在维护SiteWeaver6.8系统的技术用户，是一份小巧实用的排错参考。

1. 还在被 IE 卡住后台？动易 SiteWeaver 6.8 编辑器兼容问题到底卡在哪

打开后台想改个文章，结果编辑器一片空白、按钮点了没反应、或者干脆报错“对象不支持此操作”。如果你用的是动易 SiteWeaver 6.8 这套老系统，浏览器一旦升级到 IE9、IE10、IE11，这类问题几乎是必然的。原因不复杂：SiteWeaver 6.8 是十多年前的产品，它内置的富文本编辑器交互方式还停留在 IE6/IE7 时代，而 IE9 开始微软把 DOM 行为和 JS 引擎全面重写了，老编辑器里的不少写法在新版本浏览器里直接被判了“不支持”。

这条兼容问题的价值在于：它不只是动易一个产品的问题，凡是那个时代基于 IE6 写的老 CMS、老 OA、老后台，遇到新浏览器都是同一套病根。也就是说，你在这套系统上验证通的思路和改法，放到其他同年代系统上一样能复用。本文不绕弯子，直接给你一套可落地的排查和修复路径，从浏览器模式设置、脚本写法调整到组件替换，按步骤推着走，新手照着做能解决，老手也能在边界条件上省点时间。

2. IE9–IE11 对老后台到底做了什么：理解兼容性问题的三个层级

2.1 浏览器模式与文档模式：为什么 IE11 反而更难搞

IE 从 IE8 开始引入了“浏览器模式”和“文档模式”两套独立的概念。浏览器模式决定的是 UA 字符串和条件注释怎么解释，文档模式决定的是页面用哪个渲染引擎和 JS 引擎来跑。SiteWeaver 6.8 后台页面的 HTML 头部如果只写了content="text/html; charset=utf-8"而没有显式声明 X-UA-Compatible，IE9/IE10 默认按“最新标准模式”渲染，IE11 更是直接把老 IE 专属的attachEvent、document.all这类的写法全部当作不支持处理。

先看你的页面到底被浏览器当成了哪个文档模式。在页面上按 F12 打开开发者工具，切到“仿真”或者“Emulation”面板，看“文档模式”这一栏的值。常见做法是在后台入口页和编辑器载入页的<head>区域强制加入：

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />

注意这里有个坑：IE=edge是让 IE 用最高版本模式渲染，但对应到 IE11 就是标准模式，老编辑器可能反而更跑不起来。所以在这个场景下，更实际的做法是用：

<meta http-equiv="X-UA-Compatible" content="IE=10" />

或者视编辑器情况降到IE=9、IE=8。逻辑说明：这一行是在告诉浏览器“虽然你是 IE11，但请用 IE10（或 IE9/IE8）的渲染内核和 JS 引擎来解析这个页面”。参数说明：content的值可选IE=5、IE=7、IE=8、IE=9、IE=10、IE=edge，值越小越接近老 IE 行为，同时安全性越差。实际调的时候不要一上来就IE=7，优先从IE=10开始递减，能跑通就不要再往下降了。

如果加了 meta 之后 F12 仿真面板显示的文档模式还是 Edge 或 11，说明没生效。常见原因有两个：一是页面被服务端加了响应头X-UA-Compatible且优先级高于 meta；二是页面里有<!DOCTYPE html>声明，加上 meta 放在 head 里的位置太靠后，IE 只认 head 里最靠前的声明。

2.2 从 URL 到脚本：找出真正报错的代码位置

强制文档模式只解决了“浏览器用老模式解析”的问题，但代码本身的兼容问题还在。打开 F12 的“控制台”面板，看报错信息，最常见的几类如下。

SCRIPT438: 对象不支持“attachEvent”属性或方法。这是经典问题——IE9 开始attachEvent被移除，统一用addEventListener。SiteWeaver 6.8 的编辑器脚本里到处是element.attachEvent('onclick', fn)这种写法。修法很多，但不要一篇篇改，直接在后台全局脚本里加一个兼容垫片：

if (!window.addEventListener) { window.addEventListener = function(type, listener, useCapture) { window.attachEvent('on' + type, listener); }; } if (!Element.prototype.addEventListener) { Element.prototype.addEventListener = function(type, listener, useCapture) { this.attachEvent('on' + type, listener); }; }

代码逻辑：第一段给 window 对象补上 addEventListener，第二段给所有 DOM 元素补上。这样原本调用element.addEventListener的代码在 IE8 及以下环境自动走回 attachEvent。参数说明：useCapture在老 IE 的 attachEvent 里没有对应概念，这里直接忽略即可，对编辑器这类场景够用。如果脚本里还有attachEvent调用但你没改到的，建议再加一层反向垫片。

SCRIPT5009: 未定义“console”。老后台如果忘了清理调试代码，在 IE9 下没开 F12 时 console 对象不存在，一执行console.log就中断。这个最简单：

if (!window.console) { window.console = { log: function(){}, info: function(){}, warn: function(){}, error: function(){}}; }

SCRIPT5022: 类型不匹配或者SCRIPT87: 参数无效。这类大多出现在表单操作里，比如编辑器内容赋值用了document.frames['content']或者document.all。IE11 不支持对document.all做条件判断的写法，会直接跳出循环。

处理思路是三层：第一层 meta 控制文档模式，第二层垫片补 API，第三层针对具体报错逐点改。前两层覆盖了绝大多数场景，别一上来就沉到第三层的代码海洋里。

2.3 编辑器与后台框架的耦合：为什么只修编辑器还不够

SiteWeaver 6.8 的后台用了 frameset 框架结构，左侧菜单栏、顶部功能栏、右侧内容区是三个独立的页面。文档模式不一致的情况下，编辑器所在页面的模式即使改对了，其他 frame 里的脚本照样可能在加载时抛错，导致编辑器初始化失败。

一个排查要点：在 F12 控制台里点了报错之后，看错误发生的页面 URL 是哪个 frame。编辑器白屏但如果菜单和列表正常，问题几乎都在编辑器 frame 自身；如果整个后台错乱，那就要考虑所有 frame 页面统一加 meta。

一个操作习惯：后台入口页、编辑器页、列表页三个文件的 head 区全部加上同样的 X-UA-Compatible 声明，不要只加编辑器一个页面。很多人在编辑器页改了半天发现没用，其实是结果被父框架的文档模式“带偏”了。IE 的文档模式继承逻辑是子 frame 跟随父 frame，父框架没声明，子框架里声明了也可能被覆盖。

3. 一文搞懂 SiteWeaver 6.8 编辑器结构：动手前先把文件摸清楚

3.1 后台编辑器目录：哪些文件在管界面，哪些在管逻辑

动易 SiteWeaver 6.8 的编辑器不是独立产品，它是后台集成的一个组件，文件散落在Admin目录下。常见结构是：

Admin/ Editor/ editor.js # 编辑器核心逻辑 editor.html # 编辑器界面框架 dialog/ # 弹窗类组件 lang/ # 语言包 skin/ # 皮肤样式 Inc/ Admin.js # 后台公共脚本 Function.js # 公共函数库

开始动手之前先把editor.js和editor.html两个文件各备份一份。后面所有操作失败要回滚时，有备份省大量时间。

editor.html是编辑器的宿主页面，工具栏、编辑区、状态栏的 DOM 都在这里；editor.js管初始化和交互逻辑。兼容问题 80% 出在editor.js，但那句关键 meta 要加在editor.html里，因为页面文档模式是由 HTML 入口决定的，JS 文件本身不决定渲染模式。

文件清单和各自角色的参照： | 文件 | 作用 | 兼容问题高发区 | | --- | --- | --- | | editor.html | 编辑器宿主页面，加载脚本和样式 | 缺 X-UA-Compatible 声明 | | editor.js | 编辑器核心逻辑，DOM 操作、事件绑定、内容读写 | attachEvent、document.all、createElement | | Admin.js | 后台公共脚本，弹窗、菜单、列表逻辑 | 与编辑器脚本冲突 | | Function.js | 公共函数集 | 部分工具函数依赖老 IE API |

实际排查时，先看editor.html的文档模式，再打开editor.js搜三个关键词：attachEvent、document.all、createElement。搜出来的结果数基本就是你要改的工作量上限。

3.2 先备份还是先排查：一次不会翻车的操作顺序

整体操作顺序建议这样：

1. 备份整个Admin/Editor目录和Admin/Inc/Admin.js。
2. 给editor.html加 X-UA-Compatible meta，刷新验证编辑器能不能出来。
3. 如果还报错，打开 F12 控制台，记录第一个报错的位置，直接在源码里改那一处，刷新再看下一个报错。
4. 每改一处就刷新一次，不要攒一堆再验证，否则新旧问题混在一起很难定位。

这套顺序强调“一次只动一个变量”。常见问题是有人同时改了 meta、换了脚本、还动了样式，结果编辑器从白屏变成错乱，根本说不清是哪个改动引起的。

3.3 黑匣子一样的后台公共脚本：Admin.js 里的隐患

SiteWeaver 6.8 的后台公共脚本里有一段典型的 IE 老写法：

var isIE = document.all ? true : false;

这句话在 IE11 标准模式下document.all依然存在，所以isIE为 true，但实际上 IE11 已经不是“老 IE”了，后续代码里针对 IE 的分支逻辑全部走错。修法是把判断改成能力检测而不是浏览器探测：

var isIE = /msie|trident/i.test(navigator.userAgent);

这个改法保留了对 IE 的判断意图，但把范围限定在 UA 字符串确实带有 IE 标识的情况。IE11 的 UA 里带 Trident，所以依然能识别为 IE。参数说明：/msie|trident/i中i是忽略大小写，msie匹配 IE10 及以下，trident匹配 IE11。如果后续还支持 Edge（非 Chromium 版），Edge 的 UA 也带 Trident，逻辑依然成立。条件注释也是同类问题：

<!--[if IE]> <script src="ie_only.js"></script> <![endif]-->

这类条件注释在 IE10 起就被移除了，里面的脚本直接不加载。所以如果你发现后台某些功能在 IE11 下静默失效，检查一下是不是有脚本靠条件注释加载的。

4. 不写一行代码的抢救方案：先试试以兼容模式运行这个站点

4.1 本地打开后台：用“兼容性视图设置”快速验证问题

如果只是本地维护站点的管理员，最简单的方式是让 IE 针对这个站点自动切换到兼容性视图。打开 IE 的“工具 > 兼容性视图设置”，把你后台的域名添加进去。

这一步本质上就是给所有页面强制加了一个IE=7的文档模式头。好处是零成本，坏处是IE=7模式太老，部分现代浏览器特性会失效，而且改动是对整个站点生效的。只作为验证手段来用：如果兼容性视图下编辑器完全正常，说明问题确实只在文档模式，不需要动代码；如果兼容性视图下依然报错，说明代码本身有硬伤，必须往下走改脚本。

4.2 企业环境：用组策略或注册表预设兼容性列表

如果公司是域环境，要给多台机器统一设置，逐台手动添加不现实。常见做法有两种：一是配置企业兼容性列表（Enterprise Mode），通过组策略分发site-list.xml；二是直接下发注册表项：

Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\BrowserEmulation] "CompatibleViewList"=hex:00

不过注册表方式维护性差，不如直接用 IE 的企业模式策略来得干净。还有一个更省事的场景：如果服务器上已经装了 IIS 的 URL Rewrite 模块，可以直接在后端加响应头：

<system.webServer> <httpProtocol> <customHeaders> <add name="X-UA-Compatible" value="IE=10" /> </customHeaders> </httpProtocol> </system.webServer>

这个配置加到站点根目录的web.config里，对所有后台页面统一生效，比每个 html 文件加 meta 省事得多。注意：如果后台页面有动态输出的情况（比如 ASP 页面），自定义响应头方式依然有效，因为它是在 HTTP 层注入的，不受页面编码影响。参数说明：value="IE=10"可替换为IE=9或IE=8，实际以编辑器能跑通的最低要求为准。

4.3 企业模式与文档模式的优先级：哪个先生效

微软对 X-UA-Compatible 的生效优先级有正式定义：HTTP 响应头优先于 meta 标签。也就是说，如果你既在 web.config 里加了响应头，又在页面 head 里加了 meta，以 HTTP 响应头为准。反过来，IE 的企业模式列表优先级高于页面设置，组策略分发的兼容列表一旦包含这个站点，页面里的 meta 就不再生效。

实操中建议：企业模式只用来兜底，具体页面还是以 meta 为主，这样单个页面的可控性最强。两类方式并存时，排查文档模式为何不对，先确认这两条链路。

5. 动真格修代码：编辑器本身的 3 个必调参数与对应改法

5.1 参数一：编辑器初始化方式的兼容分支

SiteWeaver 6.8 编辑器初始化时有一段典型的 IE 判断：

var editor = null; if (window.attachEvent) { editor = new Editor_IE(); } else { editor = new Editor_Std(); }

IE11 依然支持window.attachEvent吗？不支持。但这里用的是window.attachEvent而不是document.all，所以 IE11 在标准模式下会走else分支，进而调用Editor_Std()。如果这个构造器本身没实现完整或者还有老 IE 依赖，编辑器照样白屏。

修正位置不是调这段分支，而是确保Editor_Std()本身在 IE11 下没有 API 依赖问题。真正要查的是编辑器 DOM 结构构建方式，看它用的是document.createElement还是element.innerHTML。前者在新老 IE 下表现基本一致，后者如果拼的是带style属性的 HTML 字符串，IE9+ 对部分 CSS 写法解析和 IE8 不同，会导致编辑器界面错位但功能正常。

5.2 参数二：iframe 内容读写与 designMode

SiteWeaver 6.8 的编辑器基于 iframe 实现，iframe.contentWindow.document.designMode = 'on'是让编辑区可编辑的核心操作。IE9 之后对contentWindow.document的访问限制更严格，跨域情况下直接报权限错误。

一个典型的写法问题：编辑器初始化时页面还没完全加载完就尝试访问 iframe 的 contentWindow。IE11 对时序更敏感，常见修复是等 iframe 的onload事件触发后再执行初始化：

editorFrame.onload = function() { var doc = editorFrame.contentWindow.document; doc.designMode = 'on'; doc.open(); doc.write('<html><head></head><body></body></html>'); doc.close(); };

逻辑说明：doc.open()、doc.write()、doc.close()这三个方法组合是把编辑区 iframe 先清空再写入一个干净的空白 HTML 文档。参数说明：designMode设为'on'表示整个文档可编辑，设'off'则恢复只读。如果编辑器需要初始内容，在write的 HTML 字符串里直接拼进去。注意write会清空当前文档，所以不能先 write 后 designMode，顺序必须是先开 designMode 再操作文档流。

5.3 参数三：工具栏按钮的兼容写法

工具栏按钮的点击事件在 IE11 下的失效是另一种典型情况。老代码里常见这种写法：

btn.onclick = function() { editor.execCommand('bold'); };

这段问题在于execCommand在 IE9+ 中对部分命令的行为不一致。比如bold、italic这类基本命令没问题，但removeFormat和insertHTML在新老 IE 下差异明显。insertHTML在 IE11 标准模式下可能不生效，换用pasteHTML又只在老 IE 里存在。

通用方案是封装一层：

function insertHtml(html) { var range, node; if (window.getSelection) { // 标准浏览器 var selection = window.getSelection(); range = selection.getRangeAt(0); node = document.createElement('div'); node.innerHTML = html; var frag = document.createDocumentFragment(); while (node.firstChild) { frag.appendChild(node.firstChild); } range.insertNode(frag); } else if (document.selection) { // 老 IE var sel = document.selection.createRange(); sel.pasteHTML(html); } }

逻辑说明：优先走getSelection+Range标准接口，拿不到再用document.selection兜底。这里在 IE11 标准模式下走的是第一个分支，因为window.getSelection存在且可用。参数说明：html是要插入的 HTML 字符串；getRangeAt(0)取当前选区，如果选区为空可能抛异常，调用前先判断selection.rangeCount > 0。createDocumentFragment是为了把字符串拆成节点后一次性插入，保证插入内容不超过选区范围。

这一处改完，工具栏里的“插入代码”“插入表格”这类功能在 IE11 下基本就回来了。

6. 避坑指南：SiteWeaver 6.8 编辑器兼容性调整的 5 条踩坑实录

6.1IE=edge不等于“最好”，反而可能让编辑器彻底罢工

现象：加了<meta http-equiv="X-UA-Compatible" content="IE=edge" />之后，编辑器整个区域变成空白，比不加还严重。

原因：IE=edge强制 IE11 以最高标准模式渲染。老编辑器代码里有大量老 IE 专属写法，在标准模式下全部被判无效，初始化在第一步就崩了。

解决：改成明确指定IE=10或更低版本。如果IE=10还不行，逐级降到IE=9、IE=8，但不要降过 7，IE=7下现代 CSS 几乎全废，后台界面会错乱到没法用。

6.2 后台入口页改了，编辑器 iframe 还是老样子

现象：后台主框架页面已经加了 meta，编辑器 iframe 加载后仍然白屏。

原因：iframe 内部的 HTML 文档是独立加载的，它的文档模式由它自己的响应头或 meta 决定，父框架的 meta 不会自动传递到子框架。

解决：把同样的 meta 加到editor.html文件头部。更省事的是在 web.config 里用自定义响应头统一注入，这样所有子 frame 都拿到同一个声明。

6.3document.all判断在 IE11 下直接误判

现象：IE11 下后台部分脚本行为异常，但控制台不报错，查了半天发现是走了错误的代码分支。

原因：document.all在 IE11 中依然存在但被标记为“非标准”，if (document.all)判断结果为 true，而代码作者本意是“只有老 IE 才走这个分支”。

解决：把这类判断替换成if (/msie|trident/i.test(navigator.userAgent))。如果只是判断“是不是 IE”，用 UA 里的 Trident 特征；如果要判断“是不是老 IE 的 API 环境”，用if (document.all && !window.addEventListener)做双重约束才准确。

6.4 条件注释加载的脚本在 IE10+ 完全消失

现象：后台功能“时好时坏”——某些脚本引用的函数偶尔定义，偶尔未定义，刷新几次结果不同。

原因：脚本是通过<!--[if IE]>条件注释加载的，IE10 起条件注释被废弃，整个 script 标签被当作注释不执行。看起来像偶发，实际是稳定的不加载。

解决：把<!--[if IE]>...<![endif]-->包裹的脚本挪出来直接写在页面里，或者改成 JS 动态加载：if (/msie|trident/i.test(navigator.userAgent)) { document.write('<script src="..."><\/script>'); }。注意闭合 script 标签时写成<\/script>，避免 HTML 解析器提前截断。

6.5 编辑器能打开但点按钮没反应

现象：编辑器界面正常显示，文本也能输入，但工具栏的加粗、斜体、插入链接全部没反应。

原因：按钮点击事件绑的是mousedown，而 IE11 下mousedown会先于focus触发。编辑器失焦后选区被清空，再执行execCommand时没有选区可操作，命令直接失效。

解决：按钮按下时先保存选区：

var savedRange = null; editorFrame.contentWindow.document.addEventListener('mouseup', function() { var sel = editorFrame.contentWindow.getSelection(); if (sel.rangeCount > 0) { savedRange = sel.getRangeAt(0).cloneRange(); } });

点按钮执行命令时，先恢复选区再执行：

if (savedRange) { var sel = editorFrame.contentWindow.getSelection(); sel.removeAllRanges(); sel.addRange(savedRange); } editorFrame.contentWindow.document.execCommand('bold', false, null);

逻辑说明：在mouseup时把选区快照存到变量里，点按钮时先恢复选区再执行命令，避免失焦导致的操作对象丢失。参数说明：cloneRange()复制一份范围对象，避免后续 DOM 变化把原对象弄失效；execCommand的第二个参数false表示不显示 UI，第三个参数传 null 或具体值取决于命令类型。

7. 进阶：不换编辑器的情况下还能做最后一件事

7.1 用 Console 快速验证“是不是编辑器本身的问题”

如果你在考虑换编辑器，但不确定兼容问题到底是 SiteWeaver 6.8 自身还是浏览器环境，先做一个隔离实验：在 F12 控制台手动创建一个新编辑器实例。

比如直接执行：

var frame = document.createElement('iframe'); frame.id = 'test_editor'; document.body.appendChild(frame); frame.contentWindow.document.designMode = 'on'; frame.contentWindow.document.open(); frame.contentWindow.document.write('<html><body><p>test</p></body></html>'); frame.contentWindow.document.close();

如果手动创建的 iframe 编辑区可以正常聚焦和输入，说明浏览器环境没问题，问题在 SiteWeaver 的编辑器初始化逻辑；如果手动创建的 iframe 也无法聚焦，说明你的 IE 环境本身还有安全策略或组策略限制。

这个测试的价值在于把“系统问题”和“环境问题”切分开，排查路径直接缩短一半。

7.2 一台 32 位 Windows 7 老机器当“标尺”

IE9 到 IE11 的兼容问题，最有意思的一点是：你没法在 IE11 上完整模拟 IE8 的行为，F12 仿真模式只是“模拟”，不是“真实”。所以有条件的团队，保留一台装了 Windows 7 和 IE8 的旧机器当基准环境，验证“原始代码在这台机器上是否正常”。如果基准环境下编辑器正常，说明代码原始状态是好的，问题确实由浏览器升级引起；如果基准环境也不正常，说明动易本身的编辑器在这个版本就有 bug，浏览器因素只是放大镜。

这台基准机器不要装任何更新补丁，保持 IE8 不动。同理，装一台 IE11 的 Win10 机器做目标环境。两相对照，改动效果一眼可知。

7.3 替换编辑器的备选思路：留后路但不急着做

如果代码实在修不动，SiteWeaver 6.8 又必须继续用，最后一条路是替换编辑器组件。常见方案是找一个支持 IE8+ 的轻量编辑器，比如 UEditor 1.4.3 或类似同时期产品，通过改后台编辑器调用接口来替换。

但这条路要做评估：SiteWeaver 6.8 的文章内容、图片上传接口、缩略图生成这些功能是和编辑器深度耦合的，换编辑器等于换一套上传和回显逻辑，工作量远大于修兼容。所以非迫不得已不推荐，只当作“实在不行的后悔药”。如果真走到这步，保留原编辑器文件不删除，先让新编辑器和老编辑器共存，功能验证通过再切换默认调用，这样翻车还能秒回滚。

7.4 习惯沉淀：每次 F12 关掉前，先看一眼文档模式

这轮兼容问题折腾完，养成一个习惯：每次打开后台先按 F12，切到“控制台”看有没有红色报错，切到“仿真”看文档模式是不是你预期的值。文档模式不对，后面所有操作都是白费力气；文档模式对了，后续功能报错才有排查价值。这个动作熟练后只需要五秒钟，但能帮你省掉大量“明明改对了却不生效”的困惑。

我的习惯是改完代码之后，在下班前用 IE11 把后台所有常用操作过一遍，包括新增文章、上传图片、插入代码、修改发布时间。因为兼容问题往往不是一处，而是多处隐藏在交互路径里。过一遍之后把操作清单写在便签上贴在显示器边框，下次升级或换浏览器，照着同一个清单回归一遍。前后两轮对照，哪些页面有问题、哪些功能正常，一清二楚。希望帮到你。

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