简介：这份文档面向仍在使用动易 SiteWeaver6.8 建站系统的站长与后台维护人员，针对后台编辑器在 IE9、IE10、IE11 下无法正常加载、无法编辑内容的老大难问题，给出可直接落地的兼容性修复方案。资源包内共 1 个 doc 文件，约 21KB，以图文步骤形式记录了两种处理路径：一是用配套文件直接覆盖 Editor.asp 及 Admin 目录下的相关页面，二是手动修改 Editor.asp、Admin_Article.asp、Admin_Index.asp 三个文件，通过调整浏览器版本识别逻辑并追加 X-UA-Compatible 声明，让编辑器在较新 IE 中恢复可用；文中还附带了会员中心编辑器在 IE10/IE11 下的补充修改办法。目前已有 935 人学习下载，适合不熟悉前端兼容细节、希望按步骤排查修复的运维人员参考，可帮助快速定位问题文件、减少试错成本，并保留覆盖前的备份与回退思路。
1. 后台编辑器点不动：IE9/IE10/IE11 下 SiteWeaver6.8 编辑框失灵的典型现场
后台登录正常，栏目能进，文章列表也能打开，唯独点“添加文章”或“编辑”时，编辑器区域一片空白，工具栏按钮全是灰的，光标点不进正文框，按 F12 控制台里还飘着几行navigator.appVersion.match相关的脚本错误。这个现象在动易 SiteWeaver6.8 上非常典型，只要客户端浏览器升到 IE9、IE10、IE11 就会复现，而换回 IE8 或兼容模式又莫名其妙好了。折腾人的地方在于：服务器没动、权限没动、数据库没动，纯粹是浏览器 UA 变了，老代码里的版本判断直接崩掉，编辑器初始化中断。这篇笔记面向还在维护这类老站点的开发者，把报错触发条件、根因和两套可落地的修法一次讲清，顺带把会员中心编辑器的同类问题一并收掉。
2. 编辑器空白与脚本报错：为什么 IE9/IE10/IE11 一升级就翻车
2.1 根因一：MSIE 版本正则匹配不到新 UA
老版本编辑器在Editor.asp里用navigator.appVersion去抓 IE 主版本号，写法是navigator.appVersion.match(/MSIE (.)/)[1]。这段正则在 IE8 及以前能拿到8，但 IE9/IE10/IE11 的 UA 字符串结构变了，appVersion里不再稳定携带MSIE x.x这种格式，match返回null，紧接着取[1]就抛TypeError: 无法获取未定义或 null 引用的属性"1"。编辑器初始化脚本在第一行就断了，后面的工具栏渲染、iframe 创建全部不执行，表现出来就是编辑框空白、按钮无响应。这不是玄学，是典型的“正则假设了固定 UA 格式”留下的血泪债。
定位方法很简单：在出问题的后台页面按 F12，切到“控制台”，如果看到SCRIPT5007: 无法获取未定义或 null 引用的属性"1"，再配合“脚本”面板搜索MSIE，基本就能锁定Editor.asp里那两行版本判断。另一种验证方式是在控制台直接执行：
// 在 IE9/IE10/IE11 控制台执行，观察返回值 navigator.appVersion.match(/MSIE (.)/) navigator.userAgent.toLowerCase().match(/msie ([\d.]+)/)前者返回null，后者在 IE9/IE10 下能拿到版本号，IE11 下则要看具体 UA 是否还带msie字样——这也是为什么修法里要同时配合X-UA-Compatible把文档模式压回 IE7，双保险。
2.2 根因二：YUSERONCLICK 事件绑定方式在新 IE 下失效
第二处坑更隐蔽。编辑器里有一段if (element.YUSERONCLICK) eval(element.YUSERONCLICK + 'anonymous()');，这是老式的事件挂载写法，依赖 IE 特有的anonymous()调用约定。IE9 以后脚本引擎对eval拼接和事件对象传递的处理变了，anonymous()不再按预期触发，工具栏按钮的点击事件绑不上，表现就是“按钮能看见但点了没反应”。这段代码在Editor.asp里出现两处，只改一处仍然会残留问题，必须两处都替换。替换逻辑是：检测到 IE7 到 IE12 时走onclick(event)分支，其余浏览器保留原anonymous()分支，这样既修了新 IE，也不破坏老环境和其他内核浏览器。
2.3 根因三：缺少 X-UA-Compatible，文档模式被强制拉高
即便脚本改对了，Admin_Article.asp和Admin_Index.asp输出的页面头里没有X-UA-Compatible声明，IE9/IE10/IE11 会按最高文档模式渲染，老后台的表格布局、iframe编辑器和一堆 IE 专有属性在新文档模式下行为不一致，编辑器照样可能显示异常。常见做法是在Content-Type那行Response.Write下面补一行IE=EmulateIE7，把文档模式压回编辑器能正常工作的版本。会员中心的User_Article.asp是纯 HTML 头，补法略有不同，直接在meta Content-Type下面加静态meta即可。
2.4 修法一：覆盖文件，最快恢复
文件包里已经备好改过的Editor.asp、Admin目录下的Admin_Article.asp和Admin_Index.asp。操作顺序是：先把原文件整份备份到站点目录之外（我一般会打一个带日期的压缩包，后悔药先备好），再用包内文件对应覆盖。覆盖后关闭所有 IE 窗口，清一次缓存，重新登录后台验证编辑器是否可编辑。这条路适合不想逐行改代码、只想尽快恢复的场景，缺点是如果站点此前对这几个文件做过二次定制，覆盖会把定制内容冲掉，所以备份和比对不能省。
2.5 修法二：手动改三个文件，可控可回溯
手动修改只动三个文件，共四行代码，适合需要保留原有定制的站点。第一步改Editor.asp，用记事本打开，查找：
BrowserInfo.MajorVer = navigator.appVersion.match(/MSIE (.)/)[1] ; BrowserInfo.MinorVer = navigator.appVersion.match(/MSIE .\.(.)/)[1] ;把这两行注释掉（行首加//）或直接删除，替换为：
// 改用 userAgent 统一取版本，兼容 IE9/IE10/IE11 var ua = navigator.userAgent.toLowerCase(); BrowserInfo.MajorVer = ua.match(/msie ([\d.]+)/)[1];这里ua.match(/msie ([\d.]+)/)抓的是msie后面的完整版本串，[1]取第一个捕获组；相比原来的单字符匹配，能覆盖9.0、10.0这类带小数的写法。注意 IE11 的 UA 默认可能不带msie，所以必须配合后面的文档模式声明一起用，单改这一处不够。
接着在同一文件里查找if (element.YUSERONCLICK) eval(element.YUSERONCLICK + 'anonymous()');，这段有两处，都要改成：
// IE7~IE12 走 onclick(event)，其余保留原逻辑 if(navigator.appVersion.match(/MSIE (7|8|9|10|11|12)\./i)!=null){ if (element.YUSERONCLICK) eval(element.YUSERONCLICK + "onclick(event)"); }else{ if (element.YUSERONCLICK) eval(element.YUSERONCLICK + "anonymous()"); }判断条件里把 7 到 12 都列上，是为了让 IE9/IE10/IE11 统一走新分支；i标志忽略大小写，避免 UA 大小写差异导致漏判。两处都改完，工具栏事件才能正常挂上。
第二步改Admin_Article.asp和Admin_Index.asp，查找：
Response.Write "<meta http-equiv='Content-Type' content='text/html; charset=gb2312'>" & vbCrLf在它下面加一行：
Response.Write "<meta http-equiv=""X-UA-Compatible"" content=""IE=EmulateIE7"" >" & vbCrLfVBScript 里双引号要写成两个双引号转义，& vbCrLf保证换行输出，位置必须在Content-Type之后、</head>之前，否则声明不生效。
第三步处理会员中心：改User目录下的User_Article.asp，查找静态头<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />，在其下面加：
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />这是纯 HTML 文件，不需要 VBScript 转义，直接写标准meta即可。三处改完，关闭 IE、清缓存、重开后台和会员中心分别验证。
3. 改完仍然空白或按钮无响应：五类高频翻车点逐个排
3.1 现象：覆盖后编辑器还是空白，控制台无报错
原因多半是浏览器缓存了旧的Editor.asp输出或旧 JS，IE 的缓存策略在老站点上尤其顽固。解决：关闭全部 IE 进程，用“Internet 选项 → 删除”清掉临时文件和 Cookie，或者用 InPrivate 窗口重新登录后台验证。若仍空白，检查覆盖时文件路径是否对上了Admin子目录，常见错误是把Admin_Article.asp放到了根目录。
3.2 现象：工具栏出来了，但点“加粗”“插入图片”没反应
原因是对YUSERONCLICK那段只改了一处，另一处仍是anonymous()。解决：在Editor.asp里全局搜索YUSERONCLICK，确认两处都替换成带MSIE (7|8|9|10|11|12)判断的新写法，保存后清缓存重试。
3.3 现象：后台正常，会员中心编辑器依旧不能编辑
原因是只改了后台三个文件，漏了User_Article.asp。解决：按 2.5 第三步补X-UA-Compatible声明，注意这个文件是静态 HTML，写法与 ASP 输出不同，别把 VBScript 的转义双引号抄进去。
3.4 现象：改了Editor.asp后其他浏览器编辑器反而异常
原因是版本判断分支写错，把非 IE 浏览器也带进了onclick(event)分支。解决：确认判断条件是navigator.appVersion.match(/MSIE (7|8|9|10|11|12)\./i)!=null，只有命中 IE7~IE12 才走新分支，其余保持anonymous()，不要图省事把else删掉。
3.5 现象：文档模式声明加了，但页面仍按 IE11 标准渲染
原因是meta位置不对，放在了Content-Type之前，或者被后面的meta覆盖。解决：确保X-UA-Compatible紧跟Content-Type输出，且在head内靠前位置；用 F12 的“文档模式”菜单确认当前实际模式是否已变为 IE7 标准。
4. 快速定位这类老编辑器兼容问题的排查顺序
遇到“后台编辑器在某个 IE 版本下失灵”，我一般按固定顺序走，避免东改一处西改一处。第一步看控制台报错，null取属性、match相关错误直接指向版本正则；第二步在控制台手动执行navigator.appVersion.match(/MSIE (.)/)和navigator.userAgent.toLowerCase().match(/msie ([\d.]+)/)，对比返回值，确认是不是 UA 格式变化导致；第三步用 F12 的“文档模式”看当前渲染模式，判断是否缺X-UA-Compatible；第四步全局搜索YUSERONCLICK，数一数出现次数，确认是否两处都改；第五步区分后台与会员中心，分别验证，避免漏文件。
| 排查动作 | 观察点 | 对应结论 |
|---|---|---|
| 控制台报错 | null取[1] | 版本正则失配，改Editor.asp |
| 控制台执行 UA 匹配 | 返回null或版本串 | 确认 UA 格式变化 |
| F12 文档模式 | 显示 IE11 标准而非 IE7 | 缺X-UA-Compatible |
搜索YUSERONCLICK | 出现 2 处 | 两处都要替换 |
| 后台与会员中心分别测 | 仅会员中心异常 | 补User_Article.asp |
验证通过的标准不是“看起来能点”，而是：编辑器 iframe 正常加载、工具栏按钮点击有响应、正文能输入并保存成功、会员中心同样可编辑。改完后我会把三个 ASP 文件和User_Article.asp的修改点记进站点维护日志，下次再遇到同类老系统升级浏览器，直接按这份清单过一遍，比从头猜快得多。从那以后我每次动这类老后台的编辑器文件前，都强制先打备份包、再对照 UA 匹配结果改，不再凭感觉覆盖。希望帮到你。
本文还有配套的精品资源，点击获取
