Ich hatte mich lange darum gekümmert, also habe ich es endlich recherchiert und dir diesen langwierigen Grund gegeben, warum die Dinge so sind, wie sie sind.
Aus der Spezifikation :
Section 11.9.4 The Strict Equals Operator ( === )
The production EqualityExpression : EqualityExpression === RelationalExpression
is evaluated as follows:
- Let lref be the result of evaluating EqualityExpression.
- Let lval be GetValue(lref).
- Let rref be the result of evaluating RelationalExpression.
- Let rval be GetValue(rref).
- Return the result of performing the strict equality comparison
rval === lval. (See 11.9.6)
Nun gehen wir zu 11.9.6
11.9.6 The Strict Equality Comparison Algorithm
The comparison x === y, where x and y are values, produces true or false.
Such a comparison is performed as follows:
- If Type(x) is different from Type(y), return false.
- If Type(x) is Undefined, return true.
- If Type(x) is Null, return true.
- If Type(x) is Number, then
...
- If Type(x) is String, then return true if x and y are exactly the
same sequence of characters (same length and same characters in
corresponding positions); otherwise, return false.
Das ist es. Der Operator "Triple Equals", der auf Zeichenfolgen angewendet wird, gibt "true" zurück, wenn die Argumente genau dieselben Zeichenfolgen sind (gleiche Länge und gleiche Zeichen an entsprechenden Positionen).
Dies ===funktioniert auch in den Fällen, in denen wir versuchen, Zeichenfolgen zu vergleichen, die möglicherweise aus verschiedenen Quellen stammen, von denen wir jedoch wissen, dass sie letztendlich dieselben Werte haben - ein Szenario, das für Inline-Zeichenfolgen in unserem Code häufig genug ist. Wenn wir beispielsweise eine Variable mit dem Namen connection_statehaben und wissen möchten, in welchem der folgenden Zustände ['connecting', 'connected', 'disconnecting', 'disconnected']sie sich gerade befindet, können wir die direkt verwenden=== .
Aber es gibt noch mehr. Knapp über 11.9.4 gibt es einen kurzen Hinweis:
NOTE 4
Comparison of Strings uses a simple equality test on sequences of code
unit values. There is no attempt to use the more complex, semantically oriented
definitions of character or string equality and collating order defined in the
Unicode specification. Therefore Strings values that are canonically equal
according to the Unicode standard could test as unequal. In effect this
algorithm assumes that both Strings are already in normalized form.
Hmm. Was jetzt? Extern erhaltene Saiten können und werden höchstwahrscheinlich eine seltsame Unicodey sein, und unsere Sanftheit ===wird ihnen nicht gerecht. In kommt localeComparezur Rettung:
15.5.4.9 String.prototype.localeCompare (that)
...
The actual return values are implementation-defined to permit implementers
to encode additional information in the value, but the function is required
to define a total ordering on all Strings and to return 0 when comparing
Strings that are considered canonically equivalent by the Unicode standard.
Wir können jetzt nach Hause gehen.
tl; dr;
Um Strings in Javascript, verwenden Sie zu vergleichen localeCompare; Wenn Sie wissen, dass die Zeichenfolgen keine Nicht-ASCII-Komponenten enthalten, da es sich beispielsweise um interne Programmkonstanten handelt, ===funktioniert dies ebenfalls.
JavaScript case insensitive string comparisonauf stackoverflow.com/questions/2140627/…