textarea无法阻止非法字符输入，需用input事件实时清洗并服务端双重校验。前端清洗应覆盖粘贴、IME等所有路径，服务端须按输出上下文选择转义策略，禁用strip_tags等不安全方法。

textarea 本身不阻止任何字符输入，所谓“防止”只能靠 JavaScript 实时拦截或服务端强制清理。浏览器不会替你过滤控制符、零宽空格、编码实体或组合字符——这些正是绕过前端校验的常见手段。

用 input 事件监听并清洗值，不是 keydown 或 change

只有 input 事件能覆盖粘贴、拖入、自动填充、IME 输入（如中文拼音上屏）等全部路径。其他事件要么漏掉粘贴，要么在组合输入未完成时就触发，导致 iOS/Android 上光标错乱或内容丢失。

• 对 textarea 绑定 addEventListener('input', handler)，别用内联 oninput
• 清洗逻辑示例：e.target.value = e.target.value.replace(/[\u0000-\u001f\u007f-\u009f\u200b-\u200f\u2028-\u202f]/g, '') —— 去掉控制字符、零宽空格、行分隔符
• 如果需保留换行但禁用富文本，加 .replace(/]*>/g, '')（仅作预处理，不能替代后端净化）
• 清洗后不调用 setSelectionRange() 的话，iOS 下光标会跳到开头，用户继续输入就覆盖前面内容

服务端必须重做清洗，且按输出位置选择策略

前端改 value 只影响当前页面 DOM，抓包重放、禁用 JS、curl 提交原始数据，都会绕过所有前端逻辑。服务端拿到的永远是原始字节流。

• 若输出到纯文本上下文（如

  {{ content }}

  

  DeepBI DHTML 页面生成器

  生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

  下载
  ），用 htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，缺参数会导致单引号逃逸
• 若输出到 HTML 属性（如
  ），htmlspecialchars 不够，得用上下文专用转义，比如 htmlentities($str, ENT_QUOTES | ENT_HTML5, 'UTF-8') 并额外校验是否含双引号
• 若允许有限 HTML（如评论支持 、），必须用白名单库（如 PHP 的 HTMLPurifier、Python 的 bleach.clean()），禁用 strip_tags() —— 它不检查
• 数据库存储前不要删掉所有特殊字符，否则无法还原语义；应保留原始输入 + 记录清洗动作（如 “移除了 U+200B”），用于人工复核

别信 pattern 或 maxlength 能防特殊字符

pattern 属性只在调用 reportValidity() 或原生表单提交时校验，既不阻止输入，也不修改 value；maxlength 按 UTF-16 码元计数，一个 emoji 可能占 2 个长度，而零宽字符根本不算长度。

• 对粘贴进来的 <script></script> 完全无效
• maxlength="100" 挡不住 100 个 \u200b（零宽空格），它们不占长度但能破坏渲染或绕过规则
• 移动端键盘类型切换（如 type="email"）只是提示，不影响实际可输入字符集

真正难处理的是那些“看起来正常”的字符：全角标点、同形字母（如拉丁 a 和西里尔 а）、带组合符的汉字（U+0065 U+0301 → é）。它们在视觉上无异，但 Unicode 码位不同，简单正则匹配会漏掉。这类问题必须靠 Unicode 规范化（NFC/NFD）+ 白名单比对，而不是靠删减。