JavaScriptとVB.NETの文字列の長さが異なるのはなぜですか？

Question

JavaScriptでマルチラインtextareaを一定の長さ（JS：.substring(0, x)）にトリミングし、そのフィールドがポストバックされると、VB.NETの長さをチェックすると、JavaScriptのトリム長より長い長さが見つかるVB：.Length > x）。

私はすでにこれが改行の問題であると判断しましたが、誰もそれほど長い時間をかけて答えを見つける必要がないことを確認したかったのです（明らかにalso applies to some implementations of JSP）。

ASP.NETスキーム全体のどこかで、 "\ n"（vbLf）の行が "\ r \ n"（vbCrLf）の行に分かれて複数行の値がマッサージされていますブレークこの改行の違いは、長さが一致しない理由です。 （正規表現は、おそらくにそれを行うことができますが）ここではVB.NETでそれに対処する簡単な方法は次のとおりです。

潜在的な重複に自分自身を開き、まだミスに簡単にそれを残すだろうVB.NETでそれを処理

SomeString = SomeString.Replace(vbCrLf, vbCr) 

誰かが別のものを追加したときのこの論理。textarea; JavaScriptで処理することも同じことができます。この方法で改行を処理するVB.NET/ASP.NETを維持する方法がいくつかありますか、これを非問題にする良い方法がありますか？このベストプラクティスの質問に対する答えは、この質問に対する正解であることは間違いありません。

Answer 1

犯人はSystem.Web.dllの内部型のようです。 System.Web.HttpMultipartContentTemplateParser。リフレクターを使って、私はこのコードを見つけました。

private bool GetNextLine() 
{ 
    int num = this._pos; 
    this._lineStart = -1; 
    while (num < this._length) 
    { 
     if (this._data[num] == 10) 
     { 
      this._lineStart = this._pos; 
      this._lineLength = num - this._pos; 
      this._pos = num + 1; 
      if ((this._lineLength > 0) && (this._data[num - 1] == 13)) 
      { 
       this._lineLength--; 
      } 
      break; 
     } 
     if (++num == this._length) 
     { 
      this._lineStart = this._pos; 
      this._lineLength = num - this._pos; 
      this._pos = this._length; 
     } 
    } 
    return (this._lineStart >= 0); 
} 

いくつかの魔法の数字、特に10と13に注意してください。これらはvbLfとvbCrです。これは、投稿から来る生のバイトを処理していると私には思われます、そして 'a線'はvbLf（10）で終わるものとみなされます。

生のバイトが解析されると（ParsePartDataメソッドも参照）、vbcrとvblfのcompexitiesが削除されています。

最後に、CrLFをLFに置き換えても安全だと思います。

Answer 2

UNIX OSの行末とWindows OSの行末の比較にようこそ。

IISには、何らかの種類のHTTP要求フィルタがありますか、それとも入ってきても要求を変更しない構成オプションがありますか？それは最高の答えでしょう。

それ以外の場合は、検索と置換が最適です。