Question

在工作中，我们偶然发现Bugzilla创建HTML输出导致行太长，因为浏览器没有破坏行。这是在Chrome上发生的，但在Firefox 3.5上却没有，所以我们并不在乎。但Firefox 4的行为就像Chrome一样，所以我们必须找到另一种解决方法。

一个例子是：

<html>
  <body>
    <pre>
      Lorem ipsum dolor sit amet, consetetur sadipscing elitr,&#013;sed diam nonumy eirmod tempor invidunt ut labore et&#013;dolore magna aliquyam erat, sed diam voluptua. At vero eos&#013;et accusam et justo duo dolores et ea rebum. Stet clita kasd&#013;gubergren, no sea takimata sanctus est Lorem ipsum dolor sit&#013;amet.&#013;
    </pre>
  </body>
</html>

服务器仅使用CR作为换行符，这是非常罕见的并且通常的替代方案（CR + LF，只有LF）正常工作，因此解决此问题的正确方法是告诉Bugzilla服务器使用其中一个换行符方法。无论如何，我很好奇为什么会这样不起作用，忽略换行符似乎是浏览器的“正确”方式。

另外，我使用Greasemonkey脚本（this one的修改版本）为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是否是在<pre>内处理这类换行符的“正确”方法？
为什么这个Greasemonkey脚本有效？

Answer 1

是的，HTML RFC将换行符定义为： http://www.w3.org/TR/html401/struct/text.html#line-breaks

换行符定义为回车符（＆amp;＃x000D;），换行符（＆amp;＃x000A;）或回车符/换行符对。所有换行符都构成了空格。

但是，裸车回程极为罕见。我并不感到惊讶它不起作用。但从技术上讲，我会说FF4和Chrome出了问题。

不确定为什么你的greasemonkey脚本正常工作。我的猜测是让el.innerHTML将CR转换为CR-LF或LF。

Answer 2

GM脚本有效，因为很明显，JS会在写入DOM时动态地将CR（\r）转换为LF（\n）。

见this test at jsFiddle。注意第二行末尾的CR（十进制13）如何转换为LF（十进制10）。

仅使用CR作为预标记内的换行符不起作用

2 个答案: