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

どうやら JSは DOM への書き込み時に動的にCR の ( \r) を LF ( ) に変換するため、GM スクリプトが機能します。\n

jsFiddle でこのテストを参照してください。2 行目の末尾にある CR (10 進数の 13) が LF (10 進数の 10) に変換されることに注目してください。

于 2011-05-06T21:12:59.577 に答える
3

はい、HTML RFC は改行を次のように定義しています: http://www.w3.org/TR/html401/struct/text.html#line-breaks

改行は、キャリッジ リターン ( )、ライン フィード ( )、またはキャリッジ リターンとライン フィードのペアとして定義されます。すべての改行は空白を構成します。

ただし、裸のキャリッジ リターンは非常にまれです。うまくいかなくても不思議ではありません。しかし厳密には、FF4 と Chrome は間違っていると思います。

グリースモンキー スクリプトが機能している理由がわかりません。私の推測では、el.innerHTML を取得すると、CR が CR-LF または LF に変換されます。

于 2011-05-06T20:43:47.710 に答える