web-dev-qa-db-ja.com

JSオブジェクトのキー（文字列）の長さに制限はありますか？

そのため、キーがid（int）で値が文字列であるオブジェクトがある場合がありました。しかし、ほとんどの場合、文字列に基づいてidを検索することに気づいたので、それを逆にして文字列をキーにし、値をidにすることにしました。そのため、各項目を調べて値を比較する代わりに、var id = storage[text];。以下は、私たちがしたことの例です。

古い実装の例を次に示します。

var storage = {
  0 : null,
  1 : "Hello",
  2 : "world!",
  3 : "How are you?"
}

新しい実装の例を次に示します。

var storage = {
  "null" : 0,
  "Hello" : 1,
  "world!" : 2,
  "How are you?" : 3
}

現在、文字列がキーであり、同じ文字列に対して同じIDを取得しても問題ないことを理解しています。しかし、現在、文字列は非常に大きくなる可能性があります（わずかな可能性がありますが、おそらく文字列ごとに最大1KB）、JSまたはAndroid

また、この実装には欠点がありますか？私はこれまでのところ問題に気づいていませんが、あなたは決して知りません。

javascriptandroidandroid-webviewjavascript-objects
65
Sherzod

私はこれを少し研究しました。

MDNはサイレント 問題については、仕様もそうです（ ES5 、 ES6 ）。彼らは、プロパティアクセサが資格のない文字列でなければならないことだけを述べています。つまり、仕様に関する限り制限はありません。それは驚くことではありません。

ブラウザがどのように処理するかは別の問題です。 テスト を設定し、多くのブラウザーで実行しました。 Chrome 40（デスクトップ）、Chrome 40（Android 5.1）、Firefox 36、Opera 27、IE9 +で対処可能最大2のプロパティ名を持つ27 文字。 Safari 8（OS X Yosemite）は2のプロパティ名も処理できます30 文字。

IE以外のすべてのブラウザーでは、プロパティの最大長は文字列の最大長と同じです。 IE9 +は、最大2文字列の長さを処理できます30 文字。ただし、オブジェクトキーの制限は2です。27 他のブラウザと同様に、文字。

IE8とiOSのSafariでは、テストコードが原因でメモリの問題が発生したためと考えられます。

一言で言えば、極端な場合でも、長いプロパティ名を使用しても安全です。文字列自体がブラウザが処理できる範囲内にある限り、プロパティ名としても使用できます。

74
hashchange

いいえ、文字列の長さに制限はなく（メモリに収まる限り）、実装も問題ないようです。それらを「向きを変えた」配列を持つことは、実際には非常に一般的です。ブール値。キーとしての文字列について：文字列は特定のアドレスに格納される不変のシンボルであり、実際に配列のインデックスとして使用されるのは、文字列自体ではなく、そのアドレス（別名、別名参照）です。

31
Ridcully

ECMAScript 2016では、この質問に対する決定的な答えが得られたようです。 string.lengthのMDN Webドキュメント によると：

ECMAScript 2016（ed。7）は、2 ^ 53-1要素の最大長を確立しました。以前は、最大長は指定されていませんでした。

これは、 ECMAScript®2016 Language Specification でも指定されています。

文字列型は、最大長2までの0個以上の16ビット符号なし整数値（「要素」）のすべての順序付きシーケンスのセットです。53-1要素。

3
Francis Bartkowiak