4

在工作中，我们偶然发现了 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 脚本（此脚本的修改版本）为 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;
}

似乎这对页面没有影响，但是使用此脚本，换行符突然正确显示。

所以我的问题是：

  1. Chrome/FF 4 方式是处理内部此类换行符的“正确”方式<pre>吗？
  2. 为什么这个 Greasemonkey 脚本有效？
4

2 回答 2

3

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

换行符定义为回车符 ( )、换行符 ( ) 或回车符/换行符对。所有换行符构成空白。

然而，一个简单的回车是极其罕见的。我并不惊讶它不起作用。但从技术上讲，我会说 FF4 和 Chrome 是错误的。

不知道为什么你的greasemonkey 脚本有效。我的猜测是获取 el.innerHTML 是将 CR 转换为 CR-LF 或 LF。

于 2011-05-06T20:43:47.710 回答
3

GM 脚本之所以有效，是因为显然 JS在写入 DOM 时动态地将 CR ( \r) 转换为 LF ( )。\n

在 jsFiddle看到这个测试。注意第二行末尾的 CR（十进制 13）如何转换为 LF（十进制 10）。

于 2011-05-06T21:12:59.577 回答