简介面向JSP开发者的eWebEditor在线文本编辑器v0.1.4修改版由吕海鹏优化用于在网页中嵌入富文本编辑能力解决CMS、博客、后台管理等场景下的内容排版与多媒体插入需求。压缩包共264个文件以gif图标资源、css样式表、htm示例页面、class/jar后端组件为主配合jsp调用示例与js配置脚本整体约796KB结构紧凑便于直接部署到Java Web项目中使用。已有170人学习下载。通过解压包内示例可快速理解编辑器前后端交互方式掌握用JavaScript调用API、在编辑页面上传图片并插入正文、通过Bean完成文件上传与远程图片抓取等典型操作同时内置HTML源码编辑与超链接、邮件链接功能便于实现更精细的排版控制。修改版在稳定性与编辑性能上做了优化适合需要轻量级在线文本编辑功能的JSP项目开发者参考集成也可作为研究富文本编辑器与JSP后端协同实现的入门素材。1. eWebEditor v0.1.4 For JSP 还能打老组件解决老问题但要会用对接手过老 Java 后台的人大概都碰过这类需求公告要图文混排新闻要传附件但前端团队没人有空给你搭一套现代富文本。eWebEditor 在线文本编辑器 v0.1.4 For JSP 就是为这种场景生的——一个解压就能用的富文本组件服务端是 JSP/Java浏览器端不用装任何插件。这个版本号看起来老但对于内网 OA、政府机关后台、传统企业管理系统这类不追求前端工程化的项目它反而是最快能落地的方案。网上能搜到的相关资源基本都是这个 v0.1.4 的 JSP 压缩包所以写这篇把部署流程、参数配置和坑一次性讲清楚。这篇文章适合正在维护老项目的开发也适合想快速给业务系统加编辑器的人——用对了姿势它比新框架可靠得多。2. 把 ewebeditor014jsp.rar 跑起来解压、放置、三个必须检查的配置2.1 先摸清压缩包结构JSP 组件不是扔进 lib 就完事很多人第一次拿到 ewebeditor014jsp.rar习惯性解压后把文件夹往 WEB-INF/lib 里丢结果页面白屏然后开始怀疑包有问题。这个组件不是 jar 包它是一套完整的 Web 资源JSP 页面、JavaScript 脚本、样式表、上传处理程序和示例页面。它需要被当作静态资源加动态脚本的混合体来部署。在 Linux 服务器上解压 rar 文件一般得装 unrar 工具# CentOS / Ubuntu 安装 unrar二选一按你的系统来 sudo yum install unrar # CentOS sudo apt install unrar # Ubuntu # 解压到 webapp 根目录 unrar x ewebeditor014jsp.rar /usr/local/tomcat/webapps/myproject/解压后你会看到主目录ewebeditor里面大概有script、style、image、uploadfile这类子目录还可能带一个ewebeditor.jsp或ewebeditor.htm作为编辑器壳页面以及若干示例页面。这里的uploadfile目录就是默认的文件上传落盘位置。关键点整个ewebeditor目录要和WEB-INF平级放在 webapp 根目录下而不是塞进WEB-INF里。WEB-INF下的资源客户端无法直接访问你把编辑器壳页面放进去浏览器加载 iframe 时直接 404这是最常见的初装翻车原因。另外压缩包里自带的示例页面不要直接拿去当业务页面用它的价值是给你参考接入方式。真实项目里你只需要把ewebeditor目录拷贝到项目对应位置再按下一节的方式写你自己的页面。2.2 用 iframe 方式把编辑器嵌进业务页面eWebEditor 的 JSP 版最常见、最稳的接入方式是 iframe组件本身是一个独立页面业务页面用 iframe 把它嵌进来表单提交时再从 iframe 里取回编辑后的 HTML。这种方式的好处是和宿主页面完全隔离样式不互相污染也不用担心组件里的 JavaScript 和你页面里的框架冲突。下面是一个最小可用的接入页面公告编辑就是这种结构% page pageEncodingUTF-8 % !DOCTYPE html html head meta charsetUTF-8 title公告编辑/title /head body form idnoticeForm actionsaveNotice.jsp methodpost !-- 隐藏域真正提交给后端的 HTML 内容 -- input typehidden namecontent idcontent / !-- 编辑器 iframesrc 指向组件里的编辑器外壳页面 -- iframe src${pageContext.request.contextPath}/ewebeditor/ewebeditor.jsp?idcontentstylecoolblue ideditorFrame width99% height420 frameborder0/iframe button typesubmit保存/button /form script document.getElementById(noticeForm).onsubmit function () { var frameWin document.getElementById(editorFrame).contentWindow; var html frameWin ? frameWin.document.body.innerHTML : ; document.getElementById(content).value html; }; /script /body /html这段代码里iframe 的src有多个参数。idcontent是告诉编辑器把内容同步到哪个元素这个值要和隐藏域id对应上stylecoolblue是皮肤名不同版本自带皮肤名称不一样常见的有coolblue、gray、standard具体以你解压出来的 style 目录里的文件名为准。width和height控制编辑器外壳尺寸按业务页面布局调整。表单提交钩子里从iframe.contentWindow.document.body.innerHTML取编辑内容填回隐藏域这个同步动作必须在提交前完成否则后端收到的就是空字符串。这套 iframe 接入方式对新手最友好出了问题只需要盯两个地方iframe 的 URL 是否 404以及提交时能否拿到内容。不依赖任何构建工具拷到老项目里改改路径就能用。2.3 上传目录与 web.xml让图片和附件真正能落盘编辑器能打字了但图片传不上去系统就等于残废。这里要处理两件事给上传目录一个真实可写的物理路径以及让 webapp 能通过 URL 访问到这个目录下的文件。常见做法是目录独立在项目外部避免将来重新部署时把上传文件冲掉这与把上传目录直接放在 webapp 里的方式比安全性也更好。如果你的组件默认把文件写到ewebeditor/uploadfile而且你想保持这个结构那就在 web.xml 里做一个路径映射把外部目录映射成这个 URLweb-app !-- 把真实磁盘路径映射到 /ewebeditor/uploadfile文件不随应用重部署清空 -- servlet servlet-nameUploadFileMapping/servlet-name servlet-classorg.apache.catalina.servlets.DefaultServlet/servlet-class /servlet servlet-mapping servlet-nameUploadFileMapping/servlet-name url-pattern/ewebeditor/uploadfile/*/url-pattern /servlet-mapping /web-app上面的写法是利用容器自带的 DefaultServlet把 URL 交给容器去磁盘上找对应文件。url-pattern里的路径前缀决定了外部访问方式例如你的项目上下文是/oa那图片地址就是/oa/ewebeditor/uploadfile/xxx.jpg。实际项目中更稳妥的做法是在 Tomcat 的 Context 里配Context docBase/data/upload/ewebeditor path/ewebeditor/uploadfile/这样文件物理存储在/data/upload与应用本身分离。部署完一定要检查三个点第一上传目录在操作系统层面必须有写权限Linux 下执行chmod -R 775 uploadfile注意属主要和 Tomcat 运行用户一致不然上传时 Java 会抛FileNotFoundException或返回失败第二确认uploadfile目录真实存在于磁盘上不要想当然认为编辑器会自动创建第三确认路径映射里的 URL 前缀和你在编辑器中配置的上传路径一致。这三项里任何一项不对结果都是上传失败或者图片裂图而且报错信息往往不够直观。3. 编辑器参数怎么调上传白名单、工具按钮、样式结构三块高频配置3.1 上传行为限制文件类型与大小别让编辑器变成文件上传后门老编辑器的上传功能往往默认放得很开这对内网系统是隐患。你需要找到组件里的上传配置文件把可上传类型限制到业务真正需要的范围。不同小版本的配置结构不完全一样有的用 properties 文件有的是 JSP 里的一个 JavaBean 属性还有的把这些参数做进了数据库表。但无论形式怎么变关键参数就那几项这里给一个常见的配置对象示意// 编辑器上传配置示意键名以你包内实际文件为准 { uploadDir: /ewebeditor/uploadfile, // 上传落盘目录 allowExt: [jpg, jpeg, png, gif, pdf, doc, docx], maxSize: 2048, // 单文件上限单位 KB即 2MB isRename: 1 // 1服务端重命名0保留原始文件名 }allowExt就是白名单。业务上只做图片就留图片类型需要附件再单独加pdf/doc/docx/xls。强烈不建议加exe/jsp/php这类可执行文件后缀也不要图省事把*放进白名单——组件上传接口一旦能被外部直接访问这就是一个挂后门的入口。maxSize设成 2048 还是 4096 取决于服务器带宽和磁盘给用户一个明确的上限提示比让用户传一个大文件卡死服务要好得多。isRename这个参数建议直接设 1服务端自动生成时间戳加随机串的文件名既避免了中文文件名可能引发的乱码问题也能防止同名文件互相覆盖。上传配置改完后验证方法很简单传一张 jpg 和传一个 exe前者成功后者被拒再传一个超出大小上限的文件看是否有明确提示。这三个用例过了上传这块基本就稳了。3.2 工具按钮裁剪隐藏用不到的按钮减少误操作默认工具栏往往塞满了从字体到 flash 的一整排按钮但实际业务里用不到那么多。按钮多了用户误操作的概率就大而且一些系统管理员压根不想让业务人员上传 flash。裁剪按钮一般是通过编辑器初始化参数里的toolbar数组控制下面按常见的按钮名称写法给你示意// 按业务裁剪工具栏以下按钮名称为常见叫法具体以组件脚本为准 var toolbarConfig [ [bold, italic, underline, forecolor], // 加粗、斜体、下划线、字体颜色 [insertorderlist, insertunorderlist, blockquote], // 有序/无序列表、引用 [link, unlink], // 插入链接、取消链接 [removeformat, selectall, cut, copy, paste] // 清除格式、全选、剪切、复制、粘贴 ];toolbar是一个二维数组每个内层数组对应工具栏上的一组分隔区块。如果你把image按钮从数组里移除用户界面上插入图片的入口就会消失——但这不代表别人不能通过接口直传文件所以上传白名单仍然要单独收紧。同理flash、attachment附件、table表格这类按钮按业务需求取舍。注意有些版本的按钮名称是中文别名比如字体颜色而不是forecolor你在实际包里的初始化脚本中能看到一份默认的完整数组照抄然后删减即可不要凭感觉写。裁剪工具栏的意义不只是界面干净。对内网系统来说一个用不到的flash上传按钮背后就是一个没打补丁的解析入口业务上不需要就该拿掉。这个原则叫最小功能集对老组件尤其适用。3.3 多实例与样式一页多个编辑器不打架一个页面上同时出现两个编辑器很常见比如文章编辑页既有标题输入框又有内容编辑区或者一个表单里有正文和摘要两个富文本。用 iframe 接入方式处理多实例时核心原则是每个 iframe 的id参数必须唯一否则表单提交时两个隐藏域拿到的是同一个编辑器的内容。!-- 两个编辑器的 id 分别是 content1 和 content2 -- iframe src${pageContext.request.contextPath}/ewebeditor/ewebeditor.jsp?idcontent1stylecoolblue ideditorFrame1 width100% height320 frameborder0/iframe input typehidden namecontent1 idcontent1 / iframe src${pageContext.request.contextPath}/ewebeditor/ewebeditor.jsp?idcontent2stylegray ideditorFrame2 width100% height320 frameborder0/iframe input typehidden namecontent2 idcontent2 /隐藏域的id要和 URL 里的id参数完全一致提交时逐个frame.contentWindow取内容。样式方面两个编辑器可以共用同一个皮肤也可以一个站内信用一个灰主题、一个公告用一个蓝主题只需要改style参数指向风格目录里不同的 CSS 文件即可。主题的个性化调整通常是覆盖组件的 CSS找一个与style参数同名的样式文件改里面的边框色、按钮底色和工具栏背景。多实例还有一个隐藏坑iframe 高度不一致时浏览器滚动条会很难看。生产环境里我一般把所有实例高度统一并在外层包一个固定宽度的 div这样排版最稳。4. 避坑与排查JSP 版 eWebEditor 的五个翻车现场4.1 中文文件名上传后变成问号和乱码现象用户上传一张项目流程图.jpg服务器目录里文件名变成一串问号或者页面显示图片裂图刷新后偶尔又好了。在旧版 Tomcat 下这种情况出现概率很高。原因老组件的上传逻辑直接采用浏览器原始文件名落盘没有做字符编码归一化。Tomcat 7 及以下版本对 URL 和请求体的默认编码是 ISO-8859-1中文名在转换过程中直接损毁。这属于典型的文件存上了但名字坏了。解决不要跟编码较劲直接让服务端重命名把isRename配置设为 1。如果你必须保留原始文件名那就把原始文件名单独存数据库字段磁盘上仍然用时间戳加随机数命名展示时读数据库还原。这个方案兼容 Tomcat 6 到 Tomcat 9我后来一直这么用再没出过乱码。4.2 保存后换行和段落格式全丢了现象编辑的时候段落清楚、有缩进有换行保存后再打开所有文字挤成一大坨p标签和br全没了。原因常见的有两处。第一你在把编辑器内容塞进隐藏域之前做了一次字符串替换比如用replace(\n, br)恰恰把编辑器的段落标签弄坏了第二后端接收时用了request.getParameter而忘了设置request.setCharacterEncoding(UTF-8)中文没乱码但特殊字符被改动。其实 HTML 里的换行逻辑本身不依赖\n你处理它纯属多此一举。解决提交时原样取 HTML入库时原样存回显时原样输出任何环节都不要对换行符做全局替换。如果页面上需要展示纯文本摘要那就在后端另写一个方法把 HTML 标签剥掉再截断而不是反过来往 HTML 里加换行。4.3 Linux 上部署后上传 404Windows 上却正常现象本地 Windows 开发一切正常打包丢到 Linux 服务器后编辑器页面能打开但一上传就 404或者某张图片直接访问 URL 显示 404。原因Windows 文件系统不区分大小写Linux 区分。压缩包里的实际文件名如果是EwebEditor.jsp你页面上写的是/ewebeditor/ewebeditor.jspWindows 下能匹配Linux 下直接找不到。还有一类原因是上传目录在target或build这种构建目录里你在 IDE 里跑是好的部署到服务器时目录根本没有被打进发布包。解决部署后用ls逐个核对组件目录下的文件名全部统一为小写。把上传目录独立到 webapp 外部用前面 2.3 节说的 Context 映射方式暴露 URL从根上避开文件在构建目录里被清空的问题。这个是老组件维护最典型的踩坑点每次换服务器都会有人再犯一次。4.4 与 Spring MVC 的请求路径相互拦截现象项目里配了 Spring MVC且DispatcherServlet映射的是/接入编辑器后iframe 加载的编辑器页面被打回 404甚至报框架错误。原因DispatcherServlet映射根路径意味着所有请求都先进 Spring 的处理器映射。组件内部的 JSP 请求没有对应的 ControllerSpring 找不到处理器就返回 404有些配置下还直接把编辑器页面的源码当接口响应内容处理了。解决最省事的方案是把 Spring MVC 的映射改成后缀匹配例如*.do或*.action这只影响新写的接口方法控制器类不受影响。如果你不能动全局映射就在web.xml里给编辑器路径单独加一个 servlet 映射优先级高于 DispatcherServlet 的/。相比之下我一般建议优先调整后缀映射因为它一劳永逸且老系统的业务接口本来也用后缀风格居多。4.5 图片能传上去但页面里永远看不到现象上传提示成功了服务器目录里也能看到文件但编辑器和前台页面里图片始终裂图审查元素发现 img 的 src 指向一个 404 地址。原因配置的上传路径和页面引用的 URL 不一致。一种情况是编辑器把文件写到了物理路径如D:/upload/但页面拼的却是相对路径如/ewebeditor/uploadfile/另一种情况是你把上传目录放在了WEB-INF下文件确实在但客户端 HTTP 访问WEB-INF永远被拒绝。解决明确一个规则——上传时用绝对物理路径写文件展示时用 URL 路径读文件两者通过映射打通。如果你不想做映射那就把上传目录保持在 webapp 根目录下保证http://ip:port/项目名/ewebeditor/uploadfile/文件名能直接访问到。检查时先手动访问一下图片 URL能打开就说明 URL 没问题问题在编辑器拼地址的后台逻辑。5. 回显与入库存储原始 HTML 输出白名单过滤的固定套路编辑器的内容最终落到数据库再从数据库回显到页面上这个环节看似简单却是安全风险最高的一段。早期接这个组件时我也图省事后端拿到 HTML 直接out.print结果被扫出一堆存储型 XSS 漏洞后来把输出流程固化成一套固定套路才算消停。第一步入库时存编辑器返回的原始 HTML字段用TEXT或MEDIUMTEXT不要截断也不要做清洗。任何清洗都应该发生在输出端因为存储端的职责是保真一旦你在存储前处理数据就不可逆了。第二步输出端不要直接out.print先过一道白名单过滤标签放行p/br/img/a/blockquote/span/div/font这几个属性只放行src/href/alt/width/height/targetScript、iframe、object、embed 这类全部剥掉。用正则做快速过滤可以这样兜底public static String safeHtml(String html) { if (html null || html.isEmpty()) { return ; } // 第一轮剥掉高危标签 html html.replaceAll((?is)script.*?/script, ) .replaceAll((?is)iframe.*?/iframe, ) .replaceAll((?is)object.*?/object, ) .replaceAll((?is)embed.*?/embed, ); // 第二轮删除 on* 事件属性 html html.replaceAll((?i)\\son\\w\\s*\\s*(\[^\]*\|[^]*|[^\\s]), ); // 第三轮去掉 javascript: 伪协议 html html.replaceAll((?i)javascript:, ); return html; }这个方法只能当保底正则不是解析 HTML 的正道。项目里如果允许引入依赖推荐用 jsoup 的白名单模式新版本是Safelist老版本叫Whitelist把允许的标签和属性显式声明出来比正则严谨得多。这些年维护老系统的教训就是编辑器的内容是用户可控的输出前不过滤等于把页面钥匙交出去。现在我的所有项目里富文本内容输出必须走统一的过滤方法业务代码里不允许出现裸的out.print(html)。希望这套习惯能帮到你少踩一些坑。本文还有配套的精品资源点击获取