为什么是“​"被注入到我的 HTML 中? [英] Why is "​" being injected into my HTML?
问题描述
您可以在此处(查看源代码)查看问题.
You can see the issue here (look in source).
有趣的是，它不是源代码的问题.仅适用于控制台(以及 Firebug).
Interesting, it is not an issue in source. Only with the console (Firebug as well).
我在名为 test.html 的文件中有以下标记:
I have the following markup in a file called test.html:
<!DOCTYPE html>
<html>
<head>
<title>Test Harness</title>
<link href='/css/main.css' rel='stylesheet' type='text/css' />
</head>
<body>
<h3>Test Harness</h3>
</body>
</html>
但在 Chrome 中，我看到:
But in Chrome, I see:
<!DOCTYPE html>
<html>
<head>
</head>
<body>
"​
"
<title>Test Harness</title>
<link href='/css/main.css' rel='stylesheet' type='text/css' />
<h3>Test Harness</h3>
</body>
</html>
看起来 ̢ 是零宽度空间，但是是什么导致了它?我正在使用带有 UTF-8 编码的 Sublime Text 2 和带有 Jinja2 的 Google App Engine(但 Jinja 只是加载 test.html).有什么想法吗?
It looks like ̢ is a zero width space, but what is causing it? I am using Sublime Text 2 with UTF-8 encoding and Google App Engine with Jinja2 (but Jinja is simply loading test.html). Any thoughts?
提前致谢.
推荐答案
是源码的问题.您提供的 live example 以以下字节开头(即，它们出现在 < 之前).!DOCTYPE html>): 0xE2 0x80 0x8B.这可以看到，例如通过在显示格式"下选择十六进制"，使用 Rex Swain 的 HTTP 查看器.还要注意 验证 使用 W3C 标记验证器的页面提供的信息表明文档开头有一些非常错误的地方，尤其是消息第 1 行，第 1 列:非在没有先看到文档类型的情况下找到空格字符."
It is an issue in the source. The live example that you provided starts with the following bytes (i.e., they appear before <!DOCTYPE html>): 0xE2 0x80 0x8B. This can be seen e.g. using Rex Swain’s HTTP Viewer by selecting "Hex" under "Display Format". Also note that validating the page with the W3C Markup Validator gives information that suggests that there is something very wrong at the start of the document, especially the message "Line 1, Column 1: Non-space characters found without seeing a doctype first."
验证器和 Chrome 工具中会发生什么 - 以及例如在 Firebug 中 – 字节 0xE2 0x80 0x8B 被视为字符数据，它隐式启动 body 元素(因为字符数据不能有效地出现在 head 元素中或之前)，暗示它前面有一个空的 head 元素.
What happens in the validator and in the Chrome tools – as well as e.g. in Firebug – is that the bytes 0xE2 0x80 0x8B are taken as character data, which implicitly starts the body element (since character data cannot validly appear in the head element or before it), implying an empty head element before it.
当然，解决方案是删除这些字节.浏览器通常会忽略它们，但您不应该依赖此类错误处理，并且字节会阻止有用的 HTML 验证.您如何删除它们，以及它们最初是如何到达那里的，取决于您的创作环境.
The solution, of course, is to remove those bytes. Browsers usually ignore them, but you should not rely on such error handling, and the bytes prevent useful HTML validation. How you remove them, and how they got there in the first place, depends on your authoring environment.
由于页面被声明(在 HTTP 标头中)为 UTF-8 编码，这些字节代表 零宽度空间 (U+200B) 字符.它没有可见的字形和宽度，因此即使浏览器将其视为 body 元素开头的数据，您也不会注意到视觉呈现中的任何内容.符号 ​ 是它的字符引用，大概是浏览器工具用来指示通常不可见字符的存在.
Since the page is declared (in HTTP headers) as being UTF-8 encoded, those bytes represent the ZERO WIDTH SPACE (U+200B) character. It has no visible glyph and no width, so you won’t notice anything in the visual presentation even though browsers treat it as being data at the start of the body element. The notation ​ is a character reference for it, presumably used by browser tools to indicate the presence of a normally invisible character.
生成 HTML 文档的软件可能是为了插入 零宽度无间断空间 (U+FEFF) 代替.这本来是有效的，因为根据特殊约定，UTF-8 编码的数据可能以此字符开头，也称为字节顺序标记 (BOM) 出现在数据的开头.使用 U+200B 而不是 U+FEFF 听起来像是软件不太可能犯的错误，但是如果人们想到字符的 Unicode 名称，他们可能会误以为那样.
It is possible that the software that produced the HTML document was meant to insert ZERO WIDTH NO-BREAK SPACE (U+FEFF) instead. That would have been valid, since by a special convention, UTF-8 encoded data may start with this character, also known as byte order mark (BOM) when appearing at the start of data. Using U+200B instead of U+FEFF sounds like an error that software is unlikely to make, but human beings may be mistaken that way if they think of the Unicode names of the characters.
这篇关于为什么是“&#8203;"被注入到我的 HTML 中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
