仅使用 CR 作为前置标记内的换行符不起作用
在工作中，我们偶然发现 Bugzilla 创建 HTML 输出，导致行太长，因为浏览器没有换行。 这种情况发生在 Chrome 上，但没有发生在 Firefox 3.5 上，所以我们并不关心。但 Firefox 4 的行为就像 Chrome 一样，因此我们必须找到另一种解决方法。
一个例子是：
<html>
<body>
<pre>
Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
sed diam nonumy eirmod tempor invidunt ut labore et
dolore magna aliquyam erat, sed diam voluptua. At vero eos
et accusam et justo duo dolores et ea rebum. Stet clita kasd
gubergren, no sea takimata sanctus est Lorem ipsum dolor sit
amet.
</pre>
</body>
</html>
服务器仅使用 CR 作为换行符，这是非常不常见的，并且通常的替代方案（CR+LF，仅 LF）可以正常工作，因此解决此问题的正确方法是告诉 Bugzilla 服务器使用其中之一换行方法。无论如何，我很好奇为什么会这样 不起作用，忽略换行符似乎是浏览器的“正确”方法。
另外，我使用 Greasemonkey 脚本发现了一个奇怪的 Chrome 和 FF 4 本地解决方法（修改版本 这个）：
var els = document.getElementsByTagName("*");
for(var i = 0, l = els.length; i < l; i++) {
var el = els[i];
el.innerHTML = el.innerHTML;
}
这似乎对页面没有影响，但是使用这个脚本，换行符突然显示正确。
所以我的问题是：
- Chrome/FF 4 方式是处理
内此类换行符的“正确”方式吗？ - 为什么这个 Greasemonkey 脚本有效？
At work, we stumbled upon Bugzilla creating HTML output that led to lines much too long because the browser didn't break the lines.
This was happening on Chrome, but not on Firefox 3.5, so we didn't really care. But Firefox 4 behaves just like Chrome, so we had to find another workaround.
An example is:
<html>
<body>
<pre>
Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
sed diam nonumy eirmod tempor invidunt ut labore et
dolore magna aliquyam erat, sed diam voluptua. At vero eos
et accusam et justo duo dolores et ea rebum. Stet clita kasd
gubergren, no sea takimata sanctus est Lorem ipsum dolor sit
amet.
</pre>
</body>
</html>
The server is using only CR as a linebreak which is very uncommon and the usual alternatives (CR+LF, only LF) work correctly, so the right way to fix this is to tell the Bugzilla server to use one of these linebreak methods. Anyway, I'm curious why this
doesn't work and ignoring the linebreaks seems to be the "correct" way for browsers.
Also, I found a strange local workaround for Chrome and FF 4 using a Greasemonkey script (modified version of this one):
var els = document.getElementsByTagName("*");
for(var i = 0, l = els.length; i < l; i++) {
var el = els[i];
el.innerHTML = el.innerHTML;
}
It seems this would've no effect on the page, but with this script, linebreaks suddenly are showing correctly.
So my questions are:
- Is the Chrome/FF 4 way the "correct" way to handle these kinds of linebreaks inside
<pre>? - Why is this Greasemonkey script working?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
GM 脚本之所以有效，是因为显然 JS 在写入 DOM 时动态地将 CR (
\r) 转换为 LF (\n)。请参阅jsFiddle 上的此测试。请注意第 2 行末尾的 CR（十进制 13）如何转换为 LF（十进制 10）。
The GM script works because apparently JS converts CR's (
\r) to LF (\n), dynamically on writes to the DOM.See this test at jsFiddle. Notice how the CR (decimal 13), at the end of the 2nd line, gets converted to LF (decimal 10).
是的，HTML RFC 将换行符定义为：
http://www.w3.org/TR/html401/struct /text.html#换行符
然而，裸露的回车符极为罕见。我并不惊讶它不起作用。但从技术上讲，我认为 FF4 和 Chrome 是错误的。
不知道为什么你的greasemonkey脚本可以工作。我的猜测是，获取 el.innerHTML 是将 CR 转换为 CR-LF 或 LF。
Yes, the HTML RFC defines a line break as:
http://www.w3.org/TR/html401/struct/text.html#line-breaks
However, a bare carriage return is extremely rare. I'm not surprised it doesn't work. But technically, I'd say that FF4 and Chrome are in the wrong.
Not sure why your greasemonkey script is working. My guess is that getting el.innerHTML is converting CR to CR-LF or LF.