企业官网建设流程全解析

简介：针对动易 SiteWeaver6.8 后台编辑器在 IE9、IE10、IE11 下无法正常编辑的问题，这份文档提供了完整的升级与修复方案。内容以手动修改方式为主线，覆盖 Editor.asp、Admin_Article.asp、Admin_Index.asp 三个关键文件，附具体代码替换与注释说明；同时补充会员中心 User_Article.asp 的兼容性修复，便于站长在处理后台和会员端编辑器时对照操作。资源为 1 个 doc 说明文件，约 21KB，文档结构清晰，先讲覆盖备份，再分步列出代码位置与新增语句，并提醒修改后清除缓存，排错思路比较完整。已有 934 人学习下载，适合使用 SiteWeaver6.8 并受浏览器兼容问题困扰的站长、网站维护人员参考。

1. SiteWeaver6.8后台编辑器在IE9-11下白屏：问题不在编辑器本身

维护SiteWeaver6.8这类老ASP站的人，大概率都被后台编辑器在IE9、IE10、IE11下突然白屏坑过。编辑器工具栏加载不出来，进不了源代码模式，后台其他页面都正常，唯独所有带编辑框的页面一律失效。反直觉的是，问题根源不在编辑器本体，而在编辑器初始化脚本对IE版本号的解析方式——IE9之后UA字符串变了，老代码判断“这是不是IE”的逻辑直接断裂。这篇笔记把修复文件和原理一起讲清楚，适合还在维护旧CMS的开发者、二次开发人员，以及需要让老系统在新环境里继续跑的一线实施者。

2. 为什么旧编辑器在IE9+失效：UA嗅探、事件模型与文档模式的三个断裂点

2.1 BrowserInfo.MajorVer的正则陷阱：从MSIE 8到MSIE 10/11

打开Editor.asp，前半段有一段浏览器环境解析脚本，负责把当前浏览器的主版本号、次版本号解析进BrowserInfo对象，后续编辑器初始化会拿着这个对象判断该启用哪些功能。原始写法是：

BrowserInfo.MajorVer = navigator.appVersion.match(/MSIE (.)/)[1] ; BrowserInfo.MinorVer = navigator.appVersion.match(/MSIE .\.(.)/)[1] ;

这个正则在IE6/7/8时代没有问题，它期待UA里出现“MSIE 7.0”“MSIE 8.0”这样的片段，.匹配MSIE后面的一个数字作为主版本号。到了IE9、IE10，UA字符串变成“Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)”，“MSIE (.)”仍能匹配到数字，但只匹配一位——IE9主版本是9，是一位数，到这里还没炸。真正出问题的是IE10和IE11：IE11标准模式下，UA里已经没有“MSIE”字样，只剩“Trident/7.0”，match()返回null，[1]直接抛异常，整个脚本中断，编辑器初始化就停在了半路。

// IE8 的 UA 片段 "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)" // IE9 的 UA 片段 "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" // IE11 标准模式的 UA 片段 "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0)"

提示：IE9/10/11在不同文档模式下的UA并不相同。IE11在兼容性视图下会模拟IE8/9的UA，“MSIE”又会出现，这也是很多人“换个模式就能用”的原因。

2.2 YUSERONCLICK的分支判断：事件对象从哪来

Editor.asp里还有一段绑定HTML编辑器控件事件响应的代码，原始写法长这样，并且在整个文件里出现了两处：

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

这段代码的含义是：如果DOM元素上有YUSERONCLICK属性，就执行属性里存的函数名加上“anonymous()”。在IE8及更早版本里，这种写法可以拿到一个全局匿名调用的上下文，配合事件冒泡工作。但IE9开始事件模型变了，直接执行“anonymous()”时，事件对象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()"); }

逻辑说明：先用/MSIE (7|8|9|10|11|12)\./i判断当前UA是否带IE标识，带的话走新分支，把“onclick(event)”作为函数体执行，event由调用上下文传递，符合IE9-11的事件模型；不带IE标识（比如其他浏览器，或IE11标准模式）就走老的“anonymous()”路径。参数说明：(7|8|9|10|11|12)覆盖IE7到IE12，其中12是给未来版本留的余量，正则末尾的\.匹配版本号后的小数点，目的是排除“MSIE 1.x”这类无效片段。

这个改动很小，但要求两处同时改。YUSERONCLICK是编辑器控件暴露的私有接口，文档从未公开，开发者当年只是照着老代码复制粘贴，所以官方迟迟没适配新版浏览器也可以理解。

2.3 X-UA-Compatible与EmulateIE7：用文档模式换回兼容现场

除了脚本判断，编辑器初始化还依赖页面的文档模式。IE9开始，浏览器默认以标准模式渲染页面，而SiteWeaver6.8后台页面是GB2312编码、HTML 4.01时代产物，大量内联脚本和旧控件按IE6/7的渲染规则写死。要让编辑器控件顺利加载，常见做法是通过meta标签把页面的文档模式强制切到IE7：

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

这个meta的含义是：告诉IE内核，用IE7的兼容模式解析当前页面，包括CSS盒模型、脚本引擎、控件初始化逻辑。它放在charset声明之后、其他meta之前最有效。这个标签只影响IE内核，Chrome和Firefox会忽略。

提示：后台的Admin_Article.asp和Admin_Index.asp是ASP服务端输出页面，meta标签需要用Response.Write在服务端打印出来，不是手写在HTML静态区。这就是手动修复时，给ASP文件添加的是一行Response.Write而不是直接粘贴meta标签的原因。

3. 覆盖安装：三文件备份、替换与快速回滚

3.1 文件清单与目录对应关系

修复文件包里的内容比较精简，核心就三个文件加一个目录结构：Editor.asp放在网站根目录（和后台入口同级），Admin/Admin_Article.asp和Admin/Admin_Index.asp放在Admin目录下。覆盖前先对照目录，常见做法是把整个包解压后，按压缩包里的目录结构原样覆盖到网站根目录，Windows下直接拖进去，提示“替换”就选“全部”。

需要确认文件名的对应关系。SiteWeaver6.8的不同补丁版本里，Admin_Article.asp在不同模块下可能有变体，比如后台启用多文章模型时可能叫Admin_Article_Product.asp、Admin_Article_News.asp之类。以浏览器实际调用的文件名为准：在后台文章管理页右键查看源代码，搜索editor或fckeditor，看脚本引用的是哪个文件。

前三项是处理后台，第四项处理会员中心。如果站点只在后台做内容管理、会员中心不开放投稿，第四项可以暂时不处理。

3.2 备份与替换操作步骤

覆盖前不要跳过备份。我一般会先做整站打包，或者至少把Admin目录整体复制一份：

# 在服务器IIS站点的物理路径下执行（Windows CMD） cd D:\wwwroot\mysite mkdir D:\backup\sweaver_fix_20241009 xcopy Admin D:\backup\sweaver_fix_20241009\Admin /E /I /Y xcopy Editor.asp D:\backup\sweaver_fix_20241009\Editor.asp /Y

参数说明：/E复制子目录和空目录，/I在目标不存在时自动建目录，/Y覆盖同名文件不提示。如果服务器禁止命令行操作，用FTP客户端下载这三个文件到本地也行，但注意下载模式选“二进制”，不要用“ASCII”模式，避免换行符被转换导致ASP文件解析异常。备份目录名带日期，以后排查时能快速定位。

备份完成后，把文件包里的Editor.asp、Admin文件夹原样覆盖过去。覆盖后第一件事不是马上去写文章，而是重新登录后台，进一次文章编辑页。若编辑器工具栏显示出来，说明替换生效。如果还是白屏，先别继续折腾，回到备份目录把原文件还原，按第4章的手动修改方式一步步来。

3.3 覆盖后验证与回滚路径

覆盖安装的实际风险在于，文件包里的版本不一定和你线上运行的版本完全一致。SiteWeaver6.8发布多年，有的站打过自定义补丁，直接覆盖后后台可能出现功能差异。覆盖完除了验证编辑器，还要顺手点一遍后台的栏目管理、附件管理、模板管理这几个高频入口，确认脚本输出没有因为文件版本差异报缺函数或缺变量。

验证清单按顺序过：

• 后台登录页是否正常
• 文章编辑页编辑器工具栏是否完整渲染
• 图片上传、插入表格、源代码模式三个按钮是否可用
• 保存文章后列表展示是否正常

任一环节异常，回滚路径很简单：把备份的三个文件原路径复制回去。但要注意，如果覆盖包处理文件时把Admin目录里其他文件也带进去了，就只能靠整站备份回滚。这也是为什么每次改动老系统之前，先做整站打包而不是只备份个别文件——多花一分钟，省掉一晚上的心理负担。

3.4 覆盖包与手动修改的边界：什么时候必须自己动手

覆盖安装适合大多数场景，前提是线上文件没经过深度定制。如果你在Editor.asp里加过自定义上传逻辑，或Admin_Index.asp里改过后台布局，直接覆盖会把定制内容冲掉。这时即使备份了也恢复不了定制逻辑，只能改走手动修改路线——手动方式只动几行代码，对现有配置的破坏面最小。

判断标准很简单：用对比工具（Beyond Compare这类）把线上的三个文件和修复包里的同名文件做一次二进制对比，差异只在数十行以内，说明是可覆盖的通用修复；差异过大或者线上文件比修复包新，就用手动方式。覆盖和手动修改的最终效果一致，差异在操作粒度：覆盖是全量替换，手动是定点补丁。

4. 手动修改：Editor.asp、Admin与会员中心的精确落地

4.1 Editor.asp第一处：版本号解析代码的替换

用记事本或代码编辑器打开根目录的Editor.asp，搜索“BrowserInfo.MajorVer”定位脚本段。把旧两行注释掉或删除，替换为新代码：

// 旧代码（注释掉或删除） // BrowserInfo.MajorVer = navigator.appVersion.match(/MSIE (.)/)[1] ; // BrowserInfo.MinorVer = navigator.appVersion.match(/MSIE .\.(.)/)[1] ; // 新代码 var ua = navigator.userAgent.toLowerCase(); BrowserInfo.MajorVer = ua.match(/msie ([\d.]+)/)[1];

逻辑说明：第一行先把完整的userAgent转成小写存进变量，避免后续多次取UA时大小写处理不一致；第二行用/msie ([\d.]+)/匹配“msie 9.0”“msie 10.0”“msie 11.0”这样的片段，[\d.]+一次匹配多位版本号和小数点，[1]取第一个捕获组作为主版本号。

参数说明：这段替换只接管了主版本号，MinorVer（次版本号）的解析被略过。SiteWeaver编辑器的脚本里，次版本号只在一两处做特性判断，实测不赋值不影响编辑器加载。如果后续有其他脚本依赖MinorVer，可以补一行BrowserInfo.MinorVer = ua.match(/msie [\d.]+\.([\d.]+)/)[1];，但常规修复不需要。

留意这段脚本放在<script language="javascript">标签下，是纯JS环境，不要多加ASP标签。修改完用IE直接打开Editor.asp无法预览，必须通过后台入口加载。

4.2 Editor.asp第二处：YUSERONCLICK的防御性分支

搜索“YUSERONCLICK”，定位编辑器控件的事件绑定点。原文强调这个代码在文件里出现两处，都要改。把原代码：

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

整体替换为：

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()"); }

逻辑说明：判断当前UA是否带“MSIE 7.”到“MSIE 12.”标识，命中则走“onclick(event)”分支，让事件对象显式传入函数体；未命中走老逻辑。两处代码所在上下文不同，但改动完全相同。执行完Ctrl+F搜索YUSERONCLICK，确认剩余匹配为零，才算改干净。

常见误操作是改第一处时把第二处漏掉，或者改完只验证了后台文章编辑，没验证后台首页的编辑器入口。两处对应不同业务页面，漏一处就会在某个入口继续白屏。

4.3 Admin_Article.asp与Admin_Index.asp：注入X-UA-Compatible

这两个文件是ASP服务端页面，修改方式和Editor.asp的纯JS环境不同。打开Admin/Admin_Article.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"" >" & vbCrLf

逻辑说明：这行ASP代码在服务端向页面输出meta标签，强制IE内核以IE7兼容模式渲染当前页面。双引号写成""是因为ASP字符串里双引号需要用两个双引号转义。Admin_Index.asp同样处理，搜索同一行Response.Write，在下面追加同样一行。两个文件独立，忘改任何一个，对应页面就继续白屏。

4.4 User_Article.asp：会员中心编辑器的同步修复

会员中心的编辑器挂在User目录下，对应User/User_Article.asp。它和后台页面不同，meta是静态写在HTML里的。找到：

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

在这行下面加一行：

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

注意User_Article.asp里的meta是直接写死的，不需要Response.Write包装。加了这行后，会员登录状态下进入文章发布页，编辑器在IE10、IE11下就能正常加载。如果会员中心还涉及其他带编辑器的页面，比如评论、留言管理，用同样的方式在对应文件的charset meta下补一行即可。

5. 避坑排查：改完仍白屏的几个高频现场

5.1 现象：改完刷新后台，编辑器还是空白

原因：浏览器缓存。IE对asp页面有时会缓存页面脚本，旧版Editor.asp的JS已被浏览器存进内存，关掉页面重开也不会重新拉取。很多情况下“修改不生效”不是改错了，而是根本没加载到新文件。

解决：关闭所有IE窗口，打开“Internet选项-常规-删除浏览历史记录”，勾选临时文件和Cookie，删除后重新打开后台。再做一次硬刷新：按住Ctrl键点击刷新按钮，或按Ctrl+F5。这条操作放在所有排查的第一步，成本最低。

5.2 现象：后台文章编辑正常，会员中心登录后还是白屏

原因：只改了后台的三个文件，漏了User/User_Article.asp。编辑器在后台和会员中心是两套页面，后台加载Admin目录下的脚本，前台加载User目录下的脚本。后台的修复解决不了前台的问题。

解决：按第4.4节补上会员中心的meta，同时确认会员中心引用的是同一个Editor.asp还是自己的编辑器脚本。如果会员中心用独立脚本，参考4.1和4.2的方式把UA解析和YUSERONCLICK分支都改一遍。改完清缓存、重新登录会员中心验证。

5.3 现象：覆盖文件后，后台登录页面布局乱了

原因：覆盖包里的Admin_Article.asp/Admin_Index.asp是修复版本，但线上文件被改动过，比如后台栏目结构、自定义工具栏配置都写在原文件里，覆盖后这些配置丢失或与数据库不一致。

解决：立即回滚备份的三个文件，改走手动修改路线。手动方式只添加几行代码，对已有配置的破坏面可忽略。如果已经覆盖了一段时间、数据库里新增了内容，回滚前先确认表结构没变。SiteWeaver的页面文件不存业务数据，回滚文件不会丢数据，只是界面恢复。

5.4 现象：用记事本改完，ASP页面报错或顶部输出乱码

原因：记事本保存时把GB2312编码的ASP文件存成了UTF-8带BOM，ASP解释器读到BOM头会输出非法字符，页面顶部多出一行“?”或空白行，严重点的整个页面报500错误。

解决：记事本打开文件后，通过“文件-另存为-编码”选择“ANSI”再覆盖原文件；或者用支持编码选择的编辑器打开，把编码设为“GB2312”再保存。用Windows 10/11自带记事本改老ASP文件时，默认保存是UTF-8，必须手动切ANSI。改完看文件大小，正常文件比原文件大几十字节就有BOM嫌疑。

5.5 现象：IE下正常了，Edge浏览器还是不能编辑

原因：Edge新版默认走Chromium内核，不读X-UA-Compatible标签。SiteWeaver6.8的编辑器控件本就是为IE设计，Chromium下无法通过简单meta修复完整功能。

解决：把Edge切换到IE模式。地址栏进入Edge设置，在“默认浏览器”里找到“Internet Explorer兼容性”，选择“允许在IE模式下重新加载网站”，对后台地址手动开启IE模式。这个方案复用本文的修复成果，不用额外改代码。如果站点长期要维护，建议直接让编辑人员固定用IE模式访问后台，把这个入口存成桌面快捷方式。

6. 验证与进阶：让旧编辑器在更多页面下稳定工作

6.1 用F12开发者工具验证文档模式

修复完成后，打开IE开发者工具（F12），切到“仿真”选项卡，查看“文档模式”字段。如果meta生效，文档模式显示为“7（默认）”；如果显示“Edge”或“11”，说明meta没生效，回到第4章检查meta是否落在charset之后。

再验证UA字符串：IE11标准模式下UA没有MSIE，只有Trident/7.0。这时Editor.asp里的新正则匹配不到“msie”也没关系，YUSERONCLICK分支走的是else的“anonymous()”，文档模式是IE7，编辑器也能正常工作。两条修复路径互相兜底，不会因为一条失效导致全部瘫痪。

6.2 进阶：给更多管理页面补上兼容头

后台如果还有其他带编辑框的页面，例如自定义表单、投票管理、专题维护，这些页面不在覆盖包范围内。打开对应ASP文件，搜索charset=gb2312的meta输出行，参照第4.3节在下面补一行Response.Write的X-UA-Compatible。

站点如果启用了https，注意meta标签里的内容不会影响SSL握手，但IE模式下访问https页面时，确认证书没有过期提示。IE兼容模式对证书错误处理比现代浏览器严格，会直接拦截页面。

我的习惯是每次修完站点，把改动过的文件在本地保留一份备份目录，命名为“_fixed_IE9_11”，里面放原始文件、修改后文件、变更说明三样。从那以后每次接手旧CMS维护，我先做这一步：把涉及的文件备份好，再动手改代码。多留一手，出问题时就多一条路，希望帮到你。

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