简介：eWebEditor 在线文本编辑器 v0.1.4 for JSP 是一款面向 Java Web 开发者的富文本编辑组件，由吕海鹏修改优化，适用于 JSP 网站后台中的文章发布、商品描述、论坛回帖等场景，解决普通 textarea 无法直观排版和插入多媒体的问题。压缩包共 264 个文件，以 gif 图标（186 个）和 css 样式（27 个）为主，前者用于编辑器按钮与界面元素，后者负责整体外观和布局；另含 htm 示例页面、jsp 集成演示、class 与 jar 后端类库、js 脚本及 xml 配置，整体仅 796KB，轻量易部署。目前该资源已有 170 人浏览学习。包内提供完整接入范例和目录结构，开发者可对照 jsp 示例快速部署，通过 API 调用实现文字格式化、图片上传、远程图片抓取、超链接插入和 HTML 源码编辑；吕海鹏修改版针对上传处理类与请求封装做了调整，提升了稳定性和中文兼容性，方便直接集成到内容管理类 JSP 项目，也适合作为二次开发基础。
1. 老项目里没人维护的 eWebEditor，反而值得你会部署
先说个反直觉的结论：eWebEditor 0.1.4 是十多年前的在线文本编辑器，已经没人给它发新版本，但现在依然有大量老 JSP 系统跑着它。接手这类系统，第一反应是“换掉”，可业务数据都在旧正文里，迁移成本往往比想象高。这一版 eWebEditor For JSP 打包结构简单、依赖少，你只要理解它“iframe 编辑区 + 隐藏 textarea 同步”这一套机制，部署、调参、排错都能稳稳拿下。适合以下人群：维护老后台的工程师、要把旧系统做功能增补再交付的项目组，以及想低成本给内部工具补一个富文本编辑能力的新手。它不新，但不代表不能用。
2. 先看穿它的底细：iframe 编辑区与 textarea 同步机制
老一代在线编辑器有一个共同的设计：编辑区不是表单里的输入框，而是一个内嵌的 iframe 页面。eWebEditor 0.1.4 也是这么做的。你在页面上看到的一整块工具栏和可编辑白底区域，实际是从另一个 JSP 页面加载进来的独立文档。表单里真正参与提交的，是一个隐藏的 textarea。我在排查老系统问题时，遇到最多的情况就是开发者只看到了 iframe，忘了 textarea，结果后台永远收不到正文。这一章先把这套机制讲透，后面所有配置和踩坑才有落脚点。
2.1 它不是一个输入框：一个带工具栏的 iframe 页面
eWebEditor 的页面结构可以拆成三块理解：外层承载页、iframe 编辑器页、隐藏 textarea。外层承载页就是你自己的表单 JSP，iframe 通过 src 指向 ewebeditor 目录下的编辑器页面，并带上 id、style 等参数。textarea 放在表单里，但默认隐藏，它的作用有两个：一是作为后台接收正文的字段容器，二是在页面加载时把数据库里的旧内容灌进编辑区。
编辑区内部的 HTML 操作，依赖浏览器原生的 document.execCommand 方法。加粗、斜体、插入链接、设置字体大小，本质都是对 iframe 内文档执行 execCommand 命令。这个机制老，但兼容性思路是清楚的：图片上传、文件上传这类需要服务端参与的操作，编辑器页会单独发请求到上传处理接口，拿到 URL 后再往编辑区里插入 img 或 a 标签。
这一代的取值和赋值也很直接：赋值用 setHTML，取值用 getHTML。问题在于这些方法定义在 iframe 的 window 对象上，你在外层页面不能直接 document.getElementById("content1").value，必须跨 iframe 调用。理解了这个结构，你就知道为什么网上那些“提交后内容为空”的帖子，答案基本都是没同步 textarea，而不是编辑器坏了。
2.2 部署进 webapp：解压、改名、避开 WEB-INF
拿到 ewebeditor014jsp.rar 这种包，第一件事不是打开源码看，而是把它当作一个独立的 web 应用部署到 Tomcat 的 webapp 目录下。常见做法是先解压到临时目录，确认解压出来的顶层目录名，再改成一个简短、不带版本号的名字，例如 ewebeditor。目录名太长，后续所有引用路径都会跟着长，报错时排查也麻烦。
# 解压到临时目录，再整体挪进 webapp mkdir -p /opt/tomcat/webapps/ewebeditor unrar x ewebeditor014jsp.rar /opt/tomcat/webapps/ewebeditor/ # 如果你只有 7z，也可以这样解 # 7z x ewebeditor014jsp.rar -o/tmp/ewebeditor_tmp # mv /tmp/ewebeditor_tmp /opt/tomcat/webapps/ewebeditor解压后常见的包内结构大概是：一个编辑器主 JSP 页面、包含样式和工具配置的目录、处理上传的 JSP 或 Servlet、若干 JS 和 CSS。我没法替你确认 rar 包里的具体文件名，但判断方法很简单：在 webapp 下访问http://localhost:8080/ewebeditor/，能看到目录列表或测试页，说明解压和部署基本成功。
有两个位置要注意。第一，整个 ewebeditor 目录必须放在 webapp 根下或平行于 WEB-INF，不能塞进 WEB-INF 里面，否则 Tomcat 默认不会把 WEB-INF 下的资源当作可直接访问的静态页面。第二，目录名不要带点和空格，也不要和工程项目同名，老版本编辑器对相对路径的解析很敏感，目录一复杂，iframe src 很容易拼错。
2.3 最小初始化：一段 JSP 代码把编辑器拉起来
部署完成后，用一段最小的 JSP 页面验证编辑器能不能出界面。这个验证页只做三件事：放一个 iframe、放一个隐藏 textarea、写一段 beforeSubmit 做提交前同步。
<%@ page contentType="text/html;charset=UTF-8" language="java" %> <html> <head> <title>eWebEditor 最小部署验证</title> </head> <body> <form name="frmArticle" action="/article/save" method="post" onsubmit="return beforeSubmit();"> <!-- 编辑器承载区：真正的内容在这个 iframe 页面里 --> <iframe id="editorFrame" src="<%=request.getContextPath()%>/ewebeditor/ewebeditor.jsp?id=content1&style=coolblue" width="100%" height="360" frameborder="no" scrolling="no"></iframe> <!-- 实际提交给后台的字段，必须存在 --> <textarea id="content1" name="content1" style="display:none;"></textarea> <input type="submit" value="保存" /> </form> <script> function beforeSubmit() { var frame = document.getElementById("editorFrame"); var win = frame.contentWindow; // 老版本里 getHTML 可能挂在 window 上，也可能挂在 window.editor 上 var html = ""; if (win.editor && typeof win.editor.getHTML === "function") { html = win.editor.getHTML(); } else if (typeof win.getHTML === "function") { html = win.getHTML(); } document.getElementById("content1").value = html; return true; } </script> </body> </html>这段代码里，iframe 的 src 指向编辑器主页面，id=content1 表示编辑器要把内容写入 id 为 content1 的 textarea，style=coolblue 是自带的显示风格。beforeSubmit 在表单提交前触发，先跨 iframe 取出 HTML 内容，赋给隐藏 textarea，这样后台从 request 里拿 content1 就是完整正文。
参数说明：iframe 的 id 只是一个 DOM 标识，和编辑器 id 没有强制绑定关系；真正绑定的是 iframe src 里的 id 参数与 textarea 的 id。style 参数对应编辑器内部的一套皮肤和工具栏配置，不写的话会取默认值。width 和 height 建议直接用 CSS 控制，老版本内部对高度的自适应不算好，最稳妥是给 iframe 一个固定高度。
验证这一步是否跑通，打开浏览器开发者工具，切到 Network 面板，提交表单时看 save 请求的 Form Data 里 content1 是否有值。有值，机制就通了；没值，回到 beforeSubmit 里看跨 iframe 的取值分支是否走对。初次接触这一代编辑器，强烈建议把“iframe 内容 → textarea → 后台 request”这条链路当作第一优先级验证对象，因为它决定了后面所有功能是否可信。
3. 把参数配明白：初始化、上传与提交写回
上一章解决了“编辑器能不能出来”的问题，这一章解决“编辑器按你的需求工作”的问题。老版本编辑器的配置不像现代项目有统一配置文件，参数散落在几个地方：初始化 URL 参数、编辑器内部配置对象、上传处理页面的常量。新人容易在这三处之间来回跳，最后发现改了 A 没生效，原因是 B 那边有同名参数覆盖。我的习惯是先按“初始化参数 → 上传参数 → 提交写回”这个顺序统一过一遍，每改一处都在浏览器里验证一次。
3.1 初始化参数怎么传：id、style、basepath 三件套
eWebEditor 0.1.4 的初始化参数主要通过 iframe src 的 query string 传递。最常见的三个参数是 id、style、basepath。id 决定编辑器往哪个 textarea 写内容，作用等同于一个绑定标识。style 指定编辑器界面风格和工具栏布局。basepath 则告诉编辑器页面的相对路径基准是什么，这参数特别容易被人忽略，一旦部署目录嵌套过深，编辑器内部加载 JS、CSS、图标全部会错位。
| 参数 | 作用 | 典型值 | 备注 |
|---|---|---|---|
| id | 绑定目标 textarea 的 id | content1 | 必须与页面里 textarea 的 id 完全一致 |
| style | 编辑器风格与工具栏方案 | coolblue / standard | 对应包内 style 配置目录，值不存在时会回退默认 |
| basepath | 编辑器资源的路径基准 | /ewebeditor | 不传时按相对路径解析，目录深了必出问题 |
| width | 编辑区宽度 | 550px 或 100% | 老版本对百分比支持一般，建议直接设像素 |
| height | 编辑区高度 | 360px | 不设可能塌成一行 |
basepath 的生产环境写法，我一般直接写成绝对路径：basepath=<%=request.getContextPath()%>/ewebeditor。这样无论是开发环境部署在根目录，还是生产环境挂在某个子应用下，编辑器内部资源都能稳定加载。另一个容易被坑的点是 style 的值要对应包内真实存在的风格目录，否则编辑器页面会报一堆 JS 错误，界面出不来。判断是否生效，直接看 Network 面板里编辑器页面额外加载的 CSS 和 JS 是否 200。
3.2 上传参数：BaseDir、扩展名白名单与大小上限
图片上传和附件上传是这套编辑器里最常被二次调整的部分。上传的请求和保存正文不是同一个链路，它由编辑器 iframe 内部发起，保存接口一般是一个独立的 JSP 或 Servlet，通过 form 提交或 AJAX 发送文件，然后返回一个可访问的 URL，编辑器再用这段 URL 往正文里插图片标签。
配置上传时，重点盯三处：上传根目录、允许的扩展名、文件大小上限。老版本里这些值常见写在上传处理 JSP 顶部的常量或 request 参数里。以图片上传为例，常见配置结构是这样的：
<% // 上传根目录：相对于 webapp 部署根，不要以 / 开头 String baseDir = "/upload/"; // 允许的扩展名白名单，注意小写 String[] allowExt = {"jpg", "gif", "png", "bmp", "jpeg"}; // 单个文件大小上限，单位字节，这里是 2MB long maxSize = 2 * 1024 * 1024; // 按日期分子目录，方便后续管理和清理 String subDir = new java.text.SimpleDateFormat("yyyyMMdd").format(new java.util.Date()); String uploadPath = application.getRealPath(baseDir + subDir); File dir = new File(uploadPath); if (!dir.exists()) { dir.mkdirs(); } %>这段代码的逻辑是：在 webapp 根下建立 upload 目录，再按日期分子目录，把上传文件落到upload/20250101/xxx.jpg这种结构里。allowExt 做白名单校验，maxSize 做大小限制。这里有三个容易忽略的细节。第一，baseDir 不要以斜杠开头，application.getRealPath 拼接的是相对于 webapp 根的路径，写死了容易在改部署位置时找不到目录。第二，扩展名校验一定要转小写，用户传 .JPG 和 .jpg 在 Windows 上没问题，Linux 上就会翻车。第三，目录创建时机应当在接收文件前完成，而不是等写入时报错再补建。
上传后返回给编辑器的内容是一段可访问的图片 URL，我看到的项目里有人直接返回相对路径如/upload/20250101/xxx.jpg，有人返回完整 URL。这里建议统一用相对路径，配合前端的域名部署，迁移环境时不用改库里的正文数据。
3.3 提交前写回 textarea：标准写法与验证方法
上一章给了最简单的 beforeSubmit 写法。实际项目里，正文往往还需要做进一步加工，比如清洗危险标签、压缩连续空行、给图片补样式。我的建议是不要把这些逻辑全塞进 beforeSubmit，而是写一个独立的处理函数，只做一件事：把 iframe 里的 HTML 取出来，加工后写回 textarea。
function syncEditorToForm() { var frame = document.getElementById("editorFrame"); var win = frame.contentWindow; var html = getEditorHTML(win); // 常见清洗场景：去掉编辑器自动加的冗余 class html = html.replace(/\sclass="[^"]*"/gi, ""); // 相对图片路径补全为绝对路径，避免正文单独展示时丢图 html = html.replace(/src="\/(upload\/)/g, 'src="' + window.location.origin + '/$1'); document.getElementById("content1").value = html; } function getEditorHTML(win) { if (win.editor && typeof win.editor.getHTML === "function") { return win.editor.getHTML(); } if (typeof win.getHTML === "function") { return win.getHTML(); } return ""; }这个写法比直接取值的版本多做了两件事：去掉无用 class，避免后台管理系统里每个正文 div 都挂着编辑器生成的样式类；给图片路径补全协议和域名，让正文在站外展示或单独输出时不会图片全部 cracked。验证方法很直接：在 Chrome 里编辑一段带图片的文字，点击保存，看 Network 面板里提交的 Form Data 中 content1 的值。如果 content1 里是干净的 HTML 且图片 src 完整，说明同步逻辑生效。
还有一类坑值得在这里提前说：编辑过程中不要在外层页面用 DOM 操作直接改动 textarea 的 value。textarea 只是同步的出口，不是内容的本体。你在 textarea 上赋值，编辑器 iframe 里的内容并不会跟着变。反过来，如果页面加载时想给编辑器预填内容，要找编辑器 iframe 的 setHTML 方法，而不是把内容写进 textarea。新手最容易在这两处搞反方向。
4. 部署与使用避坑：5 条高频排查记录
这一章写的都是我在老系统排查里反复遇到的真实问题，每一条都完整记录“现象 → 原因 → 解决”。如果你遇到的情况不在列表里，也可以按同样的思路拆：先确认是前端问题还是服务端问题，再确认是取值问题还是上传问题，最后再动代码。老版本编辑器报错信息普遍不友好，现象和根因往往隔着两层，直接看报错字符串容易带偏方向。
4.1 表单提交后后台拿到空字符串
现象：编辑器里明明写了字，点保存，后台收到的正文是空串。这个问题的出现率在新手接手老系统时排第一。原因几乎都是 beforeSubmit 没写，或者写了但取值方法不对。iframe 内容不会自动进表单，这是设计如此，不是 bug。解决：在表单的 onsubmit 里调用同步函数，把 getHTML 的返回值赋给 textarea。取值分支要兼容 window.editor.getHTML 和 window.getHTML 两种形态，我见过同一套代码在不同机器上走不同分支的情况。
4.2 图片上传成功但页面 404
现象：选择图片后，编辑器提示上传成功，但正文里插入的图片在浏览器里打不开，Network 显示 404。原因通常有两个方向：一是上传根目录路径配错，文件没落到 webapp 可访问的目录里；二是返回的 URL 是相对路径，但页面部署在子应用下，图片 URL 少拼了上下文路径。解决：先手动在浏览器访问上传返回的 URL，确认文件能不能直接打开。能打开，问题在 URL 拼写；打不开，去检查上传根目录和 application.getRealPath 的拼接结果。我一般会在上传处理 JSP 里临时输出一段“真实保存路径 + 访问 URL”的日志，比对一次就清楚哪一段出了问题。
4.3 中文乱码：三处编码不一致
现象：编辑器显示正常，保存正文后，数据库里中文全部变成问号或乱码。这个问题在这套 JSP 编辑器上尤其常见，因为老版本默认按 GBK 系编码走，而新项目普遍用 UTF-8。解决要查三处：页面本身 charset、上传处理 JSP 的 request 编码、数据库连接串的 characterEncoding。三个地方必须一致，我建议统一切到 UTF-8，并显式在 filter 或每个 JSP 开头设置 request.setCharacterEncoding("UTF-8")。注意，不要只改页面 charset，那只能解决显示，解决不了传输和入库。
4.4 HTTPS 下样式丢失与弹层错位
现象：系统从 HTTP 迁到 HTTPS 后，编辑器工具栏图标加载不出来，上传图片的弹层位置偏移。原因是老版本编辑器页面上有不少写死的绝对资源路径，协议是 http://，在 HTTPS 页面里被浏览器拦截。解决：全局搜索编辑器目录下所有包含 http:// 的硬编码，改成相对路径或跟随当前协议。搜索关键词可以限定在 .jsp、.js、.css 文件里，替换后用开发者工具再扫一遍 Mixed Content 报错。这类问题不算复杂，但文件多的时候容易漏，我的做法是先切到 Network 面板过滤 mixed-content 标签，逐个击破。
4.5 二次加载时编辑器内容被清空
现象：第一次打开编辑页有内容，保存后不跳转，再次点击编辑按钮打开同一篇文档，编辑器内容空了。常见原因是页面加载时给编辑器赋值的时机不对。iframe 是异步加载的，外层页面直接在 window.onload 里调 setHTML，很可能 iframe 内部还没初始化完成，方法调用了但没生效。解决：不要在 onload 里直接 setHTML，改为轮询 iframe 内是否暴露了 editor 对象，暴露后再赋值。轮询间隔不用太短，200ms 一次即可，最多等 3 秒，超时就提示加载失败。
function fillEditor(htmlContent) { var frame = document.getElementById("editorFrame"); var timer = setInterval(function () { var win = frame.contentWindow; if (win.editor && typeof win.editor.setHTML === "function") { win.editor.setHTML(htmlContent); clearInterval(timer); } }, 200); }这段轮询代码适合在老系统里做“编辑回显”。注意 setHTML 接收的是完整 HTML 字符串，不是纯文本。如果你从数据库取出来的是转义过的字符串，要先还原成 HTML 再传入，否则页面上会直接显示 p 标签源码。
5. 二开与替换：自定义按钮和老系统改造顺序
5.1 自定义一个“插入本地图片”按钮
老版本编辑器的工具栏本质上是一个配置数组。二开时想加按钮，常见做法是找到工具栏配置文件里按钮定义的位置，追加一个对象，然后在编辑器页面里实现对应的命令逻辑。命令逻辑可以是 execCommand 的封装，也可以是自己写函数操作 iframe 内文档。比如插入本地图片，核心思路是先调上传接口拿到 URL，再用 execCommand 的 insertImage 把图片塞进正文。需要注意，这个 insertImage 是在 iframe 内部的 document 上调用，而不是外层页面。
5.2 老项目里的改造判断顺序
接手一个还在用 eWebEditor 的老系统，先别急着替换。我的判断顺序是：先统计编辑器出现过的页面数量、上传接口的被引用范围、数据库里既有正文的标签复杂度。数量多、库里数据杂，优先保留编辑器、修复痛点；只有两三个页面在用，替换才划算。替换方向也不是非黑即白，可以先保留老编辑器的上传接口，前端换一个现代编辑器组件，复用已有 JSP 接口，减少服务端改动。
按这个思路做完几个老项目后，我的习惯是：不轻易全盘替换，也不硬守老代码，先把“编辑链路”和“存储结构”这两个约束点摸清，再决定投入方向。希望这篇笔记帮你把 eWebEditor 0.1.4 这套老系统看明白，也希望你接手时少踩几个我踩过的坑。
本文还有配套的精品资源，点击获取
