问题描述
有人知道浏览器是否保证不会将类型为 Text 的DOM Node 解释为HTML？
Does anyone know whether a DOM Node of type Text is guaranteed not be interpreted as HTML by the browser?
更多详细信息。
背景
我正在为朋友建立一个简单的网络评论系统，我一直在考虑XSS攻击。我不认为过滤或转义HTML标签是一个非常优雅的解决方案 - 很容易产生一个过滤器的卷积。根本的问题是，我想保证，对于某些内容（即随机未经身份验证的网络用户POST的内容），浏览器永远不会尝试解释或运行内容。
I'm building a simple web comment system for a friend, and I've been thinking about XSS attacks. I don't think filtering or escaping HTML tags is a very elegant solution--it's too easy to come up with a convolution that will slip past the filter. The fundamental issue is that I want to guarantee that, for certain pieces of content (i.e. the content that random unauthenticated web users POST), the browser never tries to interpret or run the content.
平原（文字）开始
想到的第一个想法就是使用 Content-Type：text / plain ，但这必须适用于整个页面。您可以在页面的中间放一个明文 IFRAME ，但这很丑，如果用户点击框架，就会产生焦点问题。
The first thought that came to mind is just to use Content-Type: text/plain, but this has to apply to a whole page. You can put a plaintext IFRAME in the middle of a page, but it's ugly, and it creates focus problems if the user clicks into the frame.
innerText / textContent / JQuery
事实证明，有一些浏览器专用（<$ c $ IE中的c> innerText ，FF，Safari等中的 textContent ）设置时需要创建单个文本节点。
It turns out that there are some browser-specific (innerText in IE, textContent in FF, Safari, etc.) attributes that, when set, are required to create a single Text node.
JQuery尝试通过实现单个函数 text（val）来避免浏览器特定属性的差异跳过浏览器特定的属性，并直接转到 document.createTextNode（text），您可以猜到，创建一个 Text 节点。
JQuery tries to avoid the difference in browser-specific attributes, by implementing a single function text(val) that skips the browser-specific attributes and goes directly to document.createTextNode(text), which, as you can guess, creates a Text node.
W3 DOM 文本 Node s
W3 DOM Text Nodes
所以我认为这是接近我想要的，看起来不错 - Text 节点不能有子节点，它似乎不能被解释为HTML。但是我从官方文件中肯定不是100％。
So I think this is close to what I want, it looks good--Text nodes can't have children, and it appears like they can't be interpreted as HTML. But I am not 100% sure from the official docs.
- 接口
节点： - 界面
文本： -
textContent： http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent
- Interface
Node: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1950641247 - Interface
Text: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1312295772 textContent: http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent
textContent 中的部分特别令人鼓舞，因为它表示on设置，也不执行解析，输入字符串被视为纯文本内容。但这是所有文本节点或仅设置 textContent 的节点的基础？这可能看起来像是一个笨蛋，但这可能很重要，因为IE不支持 textContent （见上文）。
The part from textContent is particularly encouraging, because it says "on setting, no parsing is performed either, the input string is taken as pure textual content." But is this fundamental to all Text nodes, or only nodes on which you set textContent? This probably seems like a dumb quibble, but it might be important because IE doesn't support textContent (see above).
回到初始问题
任何人都可以确认/拒绝将工作？也就是说，w3 DOM兼容的浏览器将永远不会将 Text 节点解释为HTML，无论内容如何？
Can anyone confirm/reject that this will work? That is, that a w3 DOM compliant browser will never interpret a Text node as HTML, no matter what the content? I'd be extremely grateful to have this tormenting little uncertainty resolved.
谢谢你的时间！
推荐答案
是的，这是确定的，只要浏览器不是，该浏览器将会出现严重的缺陷。一个文本节点，除了文本之外，将是一个矛盾。通过使用document.createTextNode（some string）;并附加该节点，字符串保证被呈现为文本。
Yes, this is confirmed, to the extent that for what ever browser it wasn't, that browser would have a serious defect. A text node that rendered anything but text would be a contradiction. By using document.createTextNode("some string"); and appending that node, the string is guaranteed to be rendered as text.
这篇关于DOM文本节点是否保证不被解释为HTML？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！