僅使用CR作為預標記內的換行符不起作用

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腳本（此版本的修改版本）為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

換行符定義為回車符（＆＃x00D;），換行符（＆＃x000A;）或回車符/換行符對。 所有換行符構成空白區域。

然而，光禿禿的回車是非常罕見的。 我並不感到驚訝它不起作用。 但從技術上講，我會說FF4和Chrome出錯了。

不確定為什么你的greasemonkey腳本工作正常。 我的猜測是el.innerHTML將CR轉換為CR-LF或LF。

Answer 2

GM腳本有效，因為顯然JS在寫入DOM時動態地將CR（ \\r ）轉換為LF（ \\n ）。

在jsFiddle看到這個測試。 注意第二行末尾的CR（十進制13）如何轉換為LF（十進制10）。

僅使用CR作為預標記內的換行符不起作用

問題描述

2 個解決方案

解決方案1
3 2011-05-06 20:43:47

解決方案2
3 已采納 2011-05-06 21:12:59

僅使用CR作為預標記內的換行符不起作用

問題描述

2 個解決方案

解決方案1 3 2011-05-06 20:43:47

解決方案2 3 已采納 2011-05-06 21:12:59

解決方案1
3 2011-05-06 20:43:47

解決方案2
3 已采納 2011-05-06 21:12:59