从数据库字段取值设置TextArea值的实现方案是否存在问题

我有一个用于存储消息的数据库，其中消息字段长度为640个字符。此前我尝试通过substr($Message,0,110)子串截取与拼接的方式处理该字段内容，最终决定改用Textarea组件实现，但遇到了需要插入数据库中已存储的消息来更新现有文本的问题。我查阅了相关在线帮助资料，其中给出的解答并不完全具备说服力。经过数小时的尝试调试，我找到了如下可正常运行的实现方式：

<textarea name="MessageA" id="MessageA" rows="8" cols="80">' . $MessageA . '</textarea>

我清楚该方案无法兼容处理特殊字符，但看起来实现逻辑十分简单，请问这种实现技术是否存在问题？

这种写法问题非常大，绝对不能放到生产环境用，核心问题有两个：

• 存在高危XSS注入漏洞：你直接把未做任何转义的变量拼到HTML标签里，只要$MessageA里出现</textarea>字符串，当前textarea会被直接提前闭合，后续如果跟着恶意脚本（比如<script>...</script>），会被浏览器直接解析执行。攻击者可以靠这个偷用户登录凭证、篡改页面内容、冒用用户身份操作，属于最严重的Web安全漏洞之一。
  举个最直观的例子：如果数据库里存的消息是</textarea><script>alert('你的站点被打了')</script>，你这段代码跑起来页面直接弹弹窗，换成偷Cookie、发恶意请求的代码就是实打实的安全事故。别觉得只有外部攻击者会搞事，哪怕是正常用户误输入了带</textarea>的内容，都能直接把你整个页面结构冲烂。
• 内容显示错乱：就算没有恶意内容，只要存储的文本里有&、<、>、单双引号这类HTML特殊字符，浏览器会把它们当成HTML语法的一部分解析，不会原样显示你存的内容，比如存的优惠&活动 <截止到本周>会显示成乱码，甚至把后面的表单、页面元素全搞错位。

你觉得这写法“能正常运行”，纯粹是测试的时候用的内容刚好没踩中上述雷区，属于碰运气的写法，只要碰到一次特殊内容就会出问题。

正确写法和你原来的实现复杂度几乎没差，只要在输出变量到HTML页面前做一次HTML实体转义就行。PHP里直接用内置的htmlspecialchars函数，记得开引号转义、指定UTF-8编码：

<textarea name="MessageA" id="MessageA" rows="8" cols="80"><?php echo htmlspecialchars($MessageA, ENT_QUOTES, 'UTF-8'); ?></textarea>

转义之后不管内容里有什么特殊字符、闭合标签，都会被转换成不会被浏览器解析的纯文本，既不会冲坏页面结构，也能彻底堵上XSS的风险，完全没必要为了省一行转义的代码冒风险。

内容的提问来源于stack exchange，提问作者John Watt