posted by Justin August 21st, 2007.No Comments
var get = YAHOO.util.Dom.get;例如<textarea id=”xx”> <><></textarea>
这时候, var a = get(‘xx’).value;
这个a中的内容是<><> ，就是说<>被转义了。 同样，input option中的value有同样的问题。
如果 var b = get(‘xx’).innerHTML;
这个b中的内容是 <><> ， 就是说，<>被转义了
根据上面的情况， value中出现<><> ， JS是无法区分是HTML转义符还是真的<>。
具体问题：在HTML编辑器中，用户在所见即所得情况下直接输入<>会被转义， 而编辑器生成的HTML代码是不转义的（HTML嘛，转义了就不是HTML了）
那么，当用户编辑这些内容的时候， 从数据库中直接取出， 放入textarea中，编辑器是无法区分真的HTML还是用户期望展现的<>。
再具体点就是，存入数据库中的数据是这样的<font size=+2>a<strong>b</strong></font>
那么当用户用编辑器存储这些内容的时候，变成了<font size=+2>a<strong>b</strong></font>完了， 编辑器失去意义了。
解决方案一： 建立一个隐藏的div, 编辑器初始化的时候， 从DIV中取数据。
但是这样的话， 一来DIV中的HTML情况不可预测，可能造成页面错位或者脚本错误。二来实现方法变得复杂。
观察了几款编辑器，都没有做这样的处理，就是说我刚开始冒出来的点子肯定是很烂的。
后来上taobao去晃了晃，发现是对写入textarea中的内容做了如下转义。把<> 转成 &lt;>
问题迎刃而解。原理是对内容进行了一次HTML转义，由于value对转义的处理机制，真的标签会被还原， 而&lt;这样的内容被还原成了<
另外，在input option的value也可以做同样的处理。
第二节：velocity向javascript传输内容。我另开个帖子吧， 嘿嘿。
好了，主要内容结束。
讲个附加问题， 就是互联网一直存在的用户在表单中输入HTML的问题， 一般来说，网站都不会允许用户输入的HTML展现在前端。
我推荐的处理方式是， 用户输入什么，就向数据库存什么，不做转义，保证原始数据的真实性。
在输出的时候针对script, value, innerHTML做不同的转义输出。 情况各有不同。
这个转义相信很多网站都做了， 我是在想， 是否在velotity或者JAVA中就事先做好取数据的接口。通过三种不同的方式来取，或者在生成HTML代码的时候，根据所在标签位置不同，架构直接对内容进行转义，就不要每个地方去转一下了。