用过富文本编辑器的人应该会遇到过这类似的问题，就是在我对富文本上的文字进行保存的时候，有2种方式，一
种是纯文本信息，如：“今天我写了一个博客”，而另一种就是纯html格式，如：<p>“今天我写了一个博客”</p>。
有的时候我们为了方便对文本信息的处理可能会将编辑的内容保存成html格式存放到数据库，这样可以方便我们的后续操作，比如原来的一些样式不会变，但你存string字符串格式获取到文本后就得重新编排了，所以很显然html格式很实用。
但是，问题来了。我们存html格式的数据会存在一个验证问题，如下：
参考网上众多案例分析，以asp.net为例，有这样做的：
validateRequest="false"
也有这样做的：修改web.config文件:
<configuration> <system.web> <pages validateRequest="false" /> </system.web> </configuration>
web.config里面加上
<system.web> <httpRuntime requestValidationMode="2.0" /> </system.web>
然而我发现这并没有什么卵用
1.首先我用的是MVC模式，可能环境不一样这样做的效果貌似行不通
2.项目文件大了有的东西不是说改就能改的，何况4.0或者4.5的程序改成2.0的是要冒一点风险性的
3.不安全。
关于不安全这一点我的理解是，存在这个异常（问题/bug）绝非是偶然的，用哲学的话来讲叫存在即合理，说白了这里之所以提示具有潜在的危险值应该是开发工具的一个智能检测，像上面提到的，存html格式的文本信息的时候“<p>“今天我写了一个博客”</p>”是这样的，里面包含特殊字符，如“<>”尖括号。这样的值在某些时候对于数据库可能是致命的，众所周知的就是SQL注入式攻击，一般在处理添加数据的时候都会有验证来防止这个，但是文本编辑器处理的文本多了问题也就来了。
说到这里你可能想到解决办法了，既然注入式攻击是从添加的时候做正则验证来避免的，那么这里是不是也可以这样？
由于文本编辑器在输入值的时候是不带hml标记的，只有取值的时候你才知道那些标记是怎样回事，因此这里用正则之类的验证不合理，综合以上种种方法的优劣性，我换了一种方式实现数据的存取，就是对获取的字符串进行编码和解码处理！
编码：
存放到数据库中的字符串样例：
解码：
编码解码简化样例：
var html="<p>今天写了一篇长长的博客</p>";//需要编码的字符串
var htmlEscape=escape(html);//编码
//----存放到数据库----
//----从数据库取出----用变量htmlSQL接收
var htmlUnEscape=unescape(htmlSQL);//解码
//---然后alert弹窗测试，和原来的值一样，但是最开始的那个问题解决了.....虽然写了很多，但解决问题也就2行代码，以上侧重思路。
Sakura，2015.7.8号编制