简介这份文档面向仍在使用动易 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. 动易 SiteWeaver6.8 后台编辑器在 IE9/IE10/IE11 下打不开先看清这套老环境的版本账上周又碰到一台跑了七八年的老站后台登录进去文章编辑区一片空白光标点不进去工具栏按钮全是灰的。站长说换了几台电脑都一样IE 升到 11 就这样了。这不是浏览器坏了是动易 SiteWeaver6.8 这套 2008 年前后的 ASP 系统前端编辑器还在用navigator.appVersion.match(/MSIE (.)/)这种只认个位版本号的老写法IE9 之后 UA 串变了正则匹配直接拿到undefined编辑器初始化就断在那儿。这类站点在不少学校和单位的内容后台里还活着装不好不是不能用是编辑功能整个瘫掉只能看不能改。这篇就按我实际处理的顺序把版本判断、文件备份、两种改法、缓存清理和验证一条条走完适合还在维护这套系统的运维和开发者照着复现。2. 动手前的环境盘点IE 版本、文件位置和备份策略2.1 先确认浏览器版本和文档模式很多人一上来就改代码改完发现没效果回头一看浏览器还停在 IE8 兼容视图里。动手前先在出问题的机器上确认两件事IE 的实际版本以及页面当前跑的文档模式。按 F12 打开开发者工具在控制台里敲一行// 输出当前 IE 的真实版本号和文档模式 console.log(navigator.userAgent); console.log(document.documentMode);navigator.userAgent里会带MSIE 9.0、MSIE 10.0或Trident/7.0; rv:11.0这样的标识IE11 已经不再用 MSIE 字样这也是老正则失效的根因。document.documentMode告诉你页面实际按哪个模式渲染如果是 7 或 8说明站点已经通过 meta 声明降级了这时候编辑器能不能用取决于降级后的脚本是否还兼容。我一般会把这两个值记下来改完再对比一次确认文档模式确实落到了预期值。版本对照上这套系统的兼容边界大致是这样IE 版本UA 标识特征老正则匹配结果编辑器表现IE8MSIE 8.0正常拿到 8可编辑IE9MSIE 9.0拿到 9但后续分支未覆盖编辑区空白IE10MSIE 10.0正则只取一位拿到 1初始化中断IE11Trident/7.0; rv:11.0匹配不到 MSIE报错完全不可编辑这张表是我踩过几次之后整理的IE10 那一行尤其坑正则MSIE (.)只抓一位数字10 被截成 1脚本以为你在用 IE1后面所有分支全走错。2.2 定位要改的文件并做整目录备份动易 SiteWeaver6.8 的后台文件结构比较固定这次涉及的文件分布在两处根目录下的Editor.asp以及Admin文件夹里的Admin_Article.asp、Admin_Index.asp。如果会员中心也要修还要动User文件夹里的User_Article.asp。改之前先把这几个文件连同所在目录整体复制一份放到站点根目录之外的备份目录命名带上日期# 在站点根目录执行把待改文件备份到同级 backup 目录 mkdir -p ../backup_20240115/Admin ../backup_20240115/User cp Editor.asp ../backup_20240115/ cp Admin/Admin_Article.asp Admin/Admin_Index.asp ../backup_20240115/Admin/ cp User/User_Article.asp ../backup_20240115/User/这里用cp而不是直接改是因为 ASP 文件一旦改错一个引号整个后台可能 500有备份就能整文件回滚比逐行撤销快得多。备份目录放在 Web 根之外避免被直接访问到。我一般还会顺手记一下改之前的文件修改时间回滚时好确认版本。提示备份不要只备份单个文件Admin目录里可能有同名的包含文件整目录复制最稳妥。2.3 确认站点编码和编辑工具这套系统是 GB2312 编码的老 ASP用记事本直接改容易在保存时被转成 UTF-8 带 BOM导致页面头部多出乱码甚至 ASP 解析报错。常见做法是用支持编码选择的编辑器打开保存时明确选 ANSI 或 GB2312。如果手头只有记事本改完一定要检查文件头有没有多出不可见字符最直接的办法是改完先在一个测试文件上验证再动正式文件。这一步看着琐碎但编码翻车的概率比代码写错还高。3. 两种改法怎么选整包覆盖与手动改四行代码3.1 整包覆盖的适用场景和操作顺序如果手上有现成的修改包里面已经包含改好的Editor.asp、Admin_Article.asp、Admin_Index.asp最省事的就是覆盖。操作顺序不能反先停掉对后台的访问再备份再覆盖最后清缓存验证。覆盖命令大致如下# 假设修改包解压在 patch 目录站点根目录为当前目录 cp patch/Editor.asp ./ cp patch/Admin/Admin_Article.asp patch/Admin/Admin_Index.asp ./Admin/覆盖前务必确认修改包对应的系统版本就是 SiteWeaver6.8不同小版本的Editor.asp里函数名和变量可能有差异拿错包覆盖会出现编辑器加载了但保存报错的情况。覆盖后不要急着让用户用先自己用 IE11 打开后台发一篇测试文章确认能编辑、能保存、能正常显示再放开。整包覆盖的优点是快缺点是你不知道包里到底改了什么后续再遇到类似问题不好排查所以我一般覆盖完还会把关键几行对照看一下。3.2 手动修改 Editor.asp 的版本识别逻辑手动改的核心就三处文件、四行代码。第一处是Editor.asp里的浏览器版本识别。用编辑器打开搜索这段BrowserInfo.MajorVer navigator.appVersion.match(/MSIE (.)/)[1] ; BrowserInfo.MinorVer navigator.appVersion.match(/MSIE .\.(.)/)[1] ;这两行的毛病前面说过只认一位版本号IE10 被截成 1IE11 干脆匹配不到。处理方式是把它们注释掉或删掉换成基于userAgent的匹配// 用 userAgent 统一提取 IE 主版本号兼容 IE9/10/11 var ua navigator.userAgent.toLowerCase(); BrowserInfo.MajorVer ua.match(/msie ([\d.])/)[1];这里[\d.]会把9.0、10.0整体抓出来IE11 虽然 UA 里没有msie但配合后面要加的X-UA-Compatible声明页面会以 IE7 模式渲染UA 里仍会带msie 7.0所以这段逻辑能兜住。参数上要注意MajorVer后续被用来做分支判断赋值必须是字符串或能隐式转换的数字别在这里做parseInt之外的额外处理否则老代码里的比较会失配。3.3 修改 Editor.asp 里的事件绑定分支同一个文件里还有一处要改搜索if (element.YUSERONCLICK) eval(element.YUSERONCLICK anonymous());注意这段代码在文件里出现两次两处都要改。原因是老编辑器给元素绑点击事件时用了anonymous()这种 IE 私有写法IE9 之后事件模型变了继续用会报错或事件不触发。改成按版本分流// IE7-IE12 走标准事件参数其余浏览器保留原逻辑 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()); }这段的意思是只要是 IE7 到 IE12就用onclick(event)把事件对象传进去其他情况维持anonymous()。正则里(7|8|9|10|11|12)覆盖了这套系统可能遇到的版本区间i忽略大小写。改的时候两处都要替换只改一处会出现部分按钮能点、部分按钮没反应的现象这种半好半坏的状态最难查。3.4 给后台页面加 X-UA-Compatible 声明第二、三处文件是Admin_Article.asp和Admin_Index.asp。打开后搜索Response.Write meta http-equivContent-Type contenttext/html; charsetgb2312 vbCrLf在这行下面加一行强制页面按 IE7 模式渲染Response.Write meta http-equivX-UA-Compatible contentIEEmulateIE7 vbCrLfIEEmulateIE7的作用是让 IE9/10/11 用 IE7 的文档模式解析页面这样老编辑器的 DOM 操作和事件写法都能按原逻辑跑。注意 VBScript 里双引号要写成两个双引号转义 vbCrLf是补换行别漏掉否则输出的 HTML 会和下一行粘在一起。两个文件都要加Admin_Index.asp是后台框架页Admin_Article.asp是文章编辑页只加一个会出现框架能开、编辑区还是空的情况。3.5 会员中心编辑器的补充修改如果会员中心在 IE10/IE11 下也不能编辑还要改User文件夹里的User_Article.asp。这个文件是纯 HTML 输出不是 VBScript 拼接所以写法不同。搜索meta http-equivContent-Type contenttext/html; charsetgb2312 /在下面加meta http-equivX-UA-Compatible contentIEEmulateIE7 /这里直接用 HTML 标签不需要Response.Write包裹。改完同样要清缓存再验证。会员中心和后台是两套入口很多人只改了后台会员投稿还是坏的排查时容易误判成没改成功。4. 改完不生效怎么排查五个高频翻车点4.1 现象改完编辑器还是空白控制台报正则错误原因通常是Editor.asp只改了一处事件绑定或者版本识别那两行没删干净老正则还在跑。解决方式是全文搜索MSIE (.)和anonymous()确认该注释的都注释了、该替换的都替换了尤其注意两处YUSERONCLICK是否都改到。改完在 IE 里按 CtrlF5 强刷别用普通刷新。4.2 现象页面能打开但样式全乱中文变乱码这是编码被改坏了。用记事本保存 GB2312 文件时很容易被转成 UTF-8导致 ASP 输出的中文和 meta 声明不一致。解决方式是重新用原备份覆盖换支持编码选择的编辑器重改保存时明确选 ANSI。已经乱码的文件不要试图在乱码基础上修直接回滚重来更快。4.3 现象后台正常会员中心仍然不能编辑只改了Admin下的文件漏了User_Article.asp。按 3.5 节补上 meta 声明即可。另外确认会员中心访问的是不是同一个站点目录有些站把会员中心单独部署改错目录也会出现这个现象。4.4 现象IE11 下偶尔能编辑刷新后又不行多半是缓存没清干净或者X-UA-Compatible声明位置不对。这个 meta 必须出现在 HTML 头部靠前的位置如果被其他输出挤到后面IE 会忽略它。检查Admin_Article.asp里那行Response.Write是否紧跟在 Content-Type 之后中间不要插入其他输出。清缓存时把 IE 的临时文件、Cookie 和站点数据都清一遍再重开。4.5 现象覆盖修改包后后台直接 500修改包版本和当前系统不匹配或者覆盖时文件权限变了。先用备份整文件回滚确认后台恢复再核对修改包对应的版本号。ASP 报 500 时把 IE 的「显示友好 HTTP 错误信息」关掉能看到具体是哪一行出错比盲猜快。5. 装完怎么验证跑通三步确认法和我的固定习惯改完不能只看「页面打开了」就算完我一般走三步确认。第一步在 IE11 里打开后台文章编辑页F12 看document.documentMode是否变成 7控制台没有红色报错第二步实际新建一篇测试文章输入中文、加粗、插入图片、保存再回列表点开确认内容完整第三步换一台没访问过该站点的机器用 IE10 再走一遍排除缓存干扰。三步都过才算这套环境真的跑通。验证时可以用一段小脚本快速确认编辑器对象是否初始化成功在编辑页控制台执行// 检查编辑器核心对象和文档模式是否就绪 console.log(documentMode:, document.documentMode); console.log(editorReady:, typeof Editor ! undefined);documentMode应为 7editorReady应为true。如果documentMode还是 11说明 meta 声明没生效回头查 3.4 节那行代码的位置和转义。如果editorReady是false重点查Editor.asp的版本识别和事件绑定两处。验证项预期结果不通过时先查文档模式7meta 声明位置、缓存编辑器对象已定义Editor.asp 版本识别中文输入保存内容完整文件编码会员中心编辑可编辑User_Article.asp这套系统太老改一次能管很久但每次动之前我都会把备份和验证走全。从那以后我每次改这类 ASP 老站都强制先备份整目录、改完用两台不同 IE 版本各验一遍再让用户上手。希望帮到你。本文还有配套的精品资源点击获取
