Quel opérateur égal (== vs ===) devrait être utilisé dans les comparaisons JavaScript?

Question

J'utilise JSLint pour parcourir JavaScript, et il renvoie de nombreuses suggestions pour remplacer == (deux signes égaux) par === (trois signes égaux) lors de la comparaison idSele_UNVEHtype.value.length == 0 à l'intérieur d'une instruction if.

Existe-t-il un avantage de performance à remplacer == par ===?

Toute amélioration des performances serait la bienvenue, car de nombreux opérateurs de comparaison existent.

Si aucune conversion de type n'a lieu, y aurait-il un gain de performance par rapport à ==?

Answer 1

L'opérateur identity (===) se comporte de la même manière que l'opérateur d'égalité (==) sauf qu'aucune conversion de type n'est effectuée et que les types doivent être identiques pour être considérés comme égaux.

Référence: Tutoriel Javascript: Opérateurs de comparaison

L'opérateur == comparera pour l'égalité après avoir effectué les conversions de type nécessaires . L'opérateur === fera pas la conversion. Par conséquent, si deux valeurs ne sont pas du même type, === retournera simplement false. Les deux sont également rapides.

Pour citer l'excellent Douglas Crockford JavaScript: les bonnes parties ,

JavaScript comporte deux ensembles d'opérateurs d'égalité: === et !==, et leurs jumeaux diaboliques == et !=. Les bons fonctionnent comme vous le souhaiteriez. Si les deux opérandes sont du même type et ont la même valeur, alors === produit true et !== produit false. Les jumeaux maléfiques font ce qui est juste quand les opérandes sont du même type, mais s’ils sont de types différents, ils tentent de contraindre les valeurs. les règles par lesquelles ils font cela sont compliquées et immuables. Voici quelques cas intéressants:

'' == '0'           // false
0 == ''             // true
0 == '0'            // true

false == 'false'    // false
false == '0'        // true

false == undefined  // false
false == null       // false
null == undefined   // true

' \t\r\n ' == 0     // true

Le manque de transitivité est alarmant. Mon conseil est de ne jamais utiliser les jumeaux maléfiques. Utilisez plutôt === et !==. Toutes les comparaisons que nous venons de montrer produisent false avec l'opérateur ===.

---

Mise à jour:

Un bon point a été soulevé par @ Casebash dans les commentaires et dans @ Phillipe Laybaert'sréponse concernant les types de référence. Pour les types de référence, == et === agissent de manière cohérente (sauf dans des cas particuliers).

var a = [1,2,3];
var b = [1,2,3];

var c = { x: 1, y: 2 };
var d = { x: 1, y: 2 };

var e = "text";
var f = "te" + "xt";

a == b            // false
a === b           // false

c == d            // false
c === d           // false

e == f            // true
e === f           // true

Le cas particulier est lorsque vous comparez un littéral avec un objet dont le résultat est identique, en raison de sa méthode toString ou valueOf. Par exemple, considérons la comparaison d'un littéral de chaîne avec un objet chaîne créé par le constructeur String.

"abc" == new String("abc")    // true
"abc" === new String("abc")   // false

Ici, l'opérateur == vérifie les valeurs des deux objets et renvoie true, mais === voit qu'ils ne sont pas du même type et renvoie false. Laquelle est correcte? Cela dépend vraiment de ce que vous essayez de comparer. Mon conseil est de contourner entièrement la question et de ne pas utiliser le constructeur String pour créer des objets chaîne.

Référence
http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.

Answer 2

Utilisation de l'opérateur == ( Egalité )

true == 1; //true, because 'true' is converted to 1 and then compared
"2" == 2;  //true, because "2" is converted to 2 and then compared

Utilisation de l'opérateur === ( identité )

true === 1; //false
"2" === 2;  //false

En effet, l'opérateur d'égalité == tape la coercition , ce qui signifie que l'interpréteur tente implicitement de convertir les valeurs avant la comparaison.

D'autre part, l'opérateur d'identité === ne fait pas la contrainte de type , et ne convertit donc pas les valeurs lors de la comparaison, et est donc plus rapide (selon This benchmark JS test) car il saute une étape.

Answer 3

Une représentation picturale intéressante de la comparaison d'égalité entre == et ===.

Source: http://dorey.github.io/JavaScript-Equality-Table/

---

var1 === var2

Lorsque vous utilisez === pour le test d'égalité JavaScript, tout est tel quel. Rien n'est converti avant d'être évalué.

---

var1 == var2

Lorsque vous utilisez == pour le test d'égalité JavaScript, des conversions amusantes ont lieu.

Morale de l'histoire:

Utilisez === à moins de bien comprendre les conversions effectuées avec ==.

Answer 4

Dans les réponses ici, je n'ai rien lu sur ce que est égal à . Certains diront que === signifie égal et du même type , mais ce n'est pas vraiment vrai. Cela signifie en fait que les deux opérandes font référence au même objet ou, dans le cas de types , ont la même valeur .

Alors prenons le code suivant:

var a = [1,2,3];
var b = [1,2,3];
var c = a;

var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true

Pareil ici:

var a = { x: 1, y: 2 };
var b = { x: 1, y: 2 };
var c = a;

var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true

Ou même:

var a = { };
var b = { };
var c = a;

var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true

Ce comportement n'est pas toujours évident. L'histoire ne se résume pas à l'égalité et au même type.

La règle est la suivante:

Pour les types de valeur (nombres):
a === b renvoie true si a et b ont la même valeur et sont du même type

Pour les types de référence:
a === b renvoie true si a et b font référence au même objet

Pour les chaînes:
a === b renvoie true si a et b sont des chaînes et contiennent exactement les mêmes caractères

---

Cordes: le cas particulier ...

Les chaînes ne sont pas des types de valeur, mais en Javascript, elles se comportent comme des types de valeur. Elles sont donc "égales" lorsque les caractères de la chaîne sont identiques et de la même longueur (comme expliqué dans la troisième règle).

Maintenant ça devient intéressant:

var a = "12" + "3";
var b = "123";

alert(a === b); // returns true, because strings behave like value types

Mais qu'en est-il de ça?

var a = new String("123");
var b = "123";

alert(a === b); // returns false !! (but they are equal and of the same type)

Je pensais que les chaînes se comportaient comme des types de valeur? Cela dépend de qui vous demandez ... Dans ce cas, a et b ne sont pas du même type. a est de type Object, tandis que b est de type string. Rappelez-vous simplement que créer un objet chaîne avec le constructeur String crée quelque chose de type Object qui se comporte comme une chaîne la plupart du temps .

Answer 5

Permettez-moi d'ajouter ce conseil:

En cas de doute, lisez le spécification !

ECMA-262 est la spécification d'un langage de script dont JavaScript est un dialecte. Bien entendu, dans la pratique, le comportement des principaux navigateurs est plus important qu'une définition ésotérique de la manière dont une chose est supposée être traitée. Mais il est utile de comprendre pourquoi new String ("a")! == "a" .

Laissez-moi vous expliquer comment lire le cahier des charges pour clarifier cette question. Je vois que dans ce très vieux sujet, personne n’a eu de réponse pour cet effet très étrange. Donc, si vous pouvez lire un cahier des charges, cela vous aidera énormément dans votre profession. C'est une compétence acquise. Alors continuons.

La recherche du fichier PDF pour === me conduit à la page 56 du cahier des charges: 11.9.4. L'opérateur Strict Equals (===) , et après avoir parcouru le spécalese, je trouve:

11.9.6 L'algorithme de comparaison d'égalité stricte
La comparaison x === y, où x et y sont des valeurs, produit vrai ou faux . Une telle comparaison est effectuée comme suit:
1. Si le type (x) est différent du type (y), retournez false .
2. Si Type (x) est Non défini, retournez vrai .
3. Si Type (x) est Null, retournez vrai .
4. Si le type (x) n’est pas un nombre, passez à l’étape 11.
5. Si x est NaN , retournez false .
6. Si y est NaN , retourne false .
7. Si x est la même valeur numérique que y, retourne vrai .
8. Si x est +0 et y est −0, retourne vrai .
9. Si x est −0 et y est +0, retourne vrai .
10. Renvoie false .
11. Si Type (x) est une chaîne, retournez true si x et y sont exactement la même séquence de caractères (même longueur). et les mêmes caractères dans les positions correspondantes); sinon, retourne false .
12. Si Type (x) est booléen, retournez vrai si x et y sont tous les deux vrai ou les deux faux ; sinon, retourne false .
13. Renvoie vrai si x et y font référence au même objet ou s'ils se rapportent à des objets joints les uns aux autres (voir 13.1. 2) Sinon, retourne false .

L'étape 11 est intéressante. Oui, les chaînes sont traitées comme des types de valeur. Mais cela n'explique pas pourquoi new String ("a")! == "a" . Avons-nous un navigateur non conforme à ECMA-262?

Pas si vite!

Vérifions les types des opérandes. Essayez vous-même en les enveloppant dans typeof () . Je trouve que new String ("a") est un objet et que l'étape 1 est utilisée: return false si les types sont différents.

Si vous vous demandez pourquoi new String ("a") ne renvoie pas de chaîne, que diriez-vous d'un exercice de lecture d'une spécification? S'amuser!

---

Aidiakapi a écrit ceci dans un commentaire ci-dessous:

De la spécification

11.2.2 Le nouvel opérateur :

Si Type (constructeur) n'est pas Object, lève une exception TypeError.

En d'autres termes, si String ne serait pas de type Object, il ne pourrait pas être utilisé avec le nouvel opérateur.

new renvoie toujours un objet, même pour les constructeurs String . Et hélas! La sémantique des valeurs pour les chaînes (voir l’étape 11) est perdue.

Et cela signifie enfin: new String ("a")! == "a" .

Answer 6

En PHP et JavaScript, il s'agit d'un opérateur d'égalité stricte. Ce qui signifie qu’il comparera à la fois le type et les valeurs.

Answer 7

J'ai testé cela dans Firefox avec Firebug en utilisant un code comme celui-ci:

console.time("testEquality");
var n = 0;
while(true) {
    n++;
    if(n==100000) 
        break;
}
console.timeEnd("testEquality");

et

console.time("testTypeEquality");
var n = 0;
while(true) {
    n++;
    if(n===100000) 
        break;
}
console.timeEnd("testTypeEquality");

Mes résultats (testés cinq fois chacun et moyennés):

==: 115.2
===: 114.4

Je dirais donc que la différence minuscule (plus de 100 000 itérations, rappelez-vous) est négligeable. La performance n'est pas une raison de faire ===. Tapez la sécurité (enfin, aussi sûr que vous allez obtenir en JavaScript), et la qualité du code est.

Answer 8

En JavaScript, cela signifie de la même valeur et du même type.

Par exemple,

4 == "4" // will return true

mais

4 === "4" // will return false 

Answer 9

L'opérateur === est appelé opérateur de comparaison stricte, il ne diffère de l'opérateur ==.

Prenons 2 vars a et b.

Pour "a == b", évaluer à vrai a et b doivent être les même valeur.

Dans le cas de "a === b" a et b doivent être le même valeur et aussi le même type pour qu'il puisse être évalué vrai.

Prenons l'exemple suivant

var a = 1;
var b = "1";

if (a == b) //evaluates to true as a and b are both 1
{
    alert("a == b");
}

if (a === b) //evaluates to false as a is not the same type as b
{
    alert("a === b");
}

en résumé; L'utilisation de l'opérateur == peut donner la valeur true dans les cas où vous ne le souhaitez pas. L'utilisation de l'opérateur === serait donc plus sûre.

Dans le scénario d'utilisation à 90%, le type d'utilisation importe peu, mais il est utile de connaître la différence lorsqu'un comportement inattendu se produit un jour.

Answer 10

Il vérifie si les mêmes côtés sont égaux dans type ainsi que valeur.

Exemple:

'1' === 1 // will return "false" because `string` is not a `number`

Exemple commun:

0 == ''  // will be "true", but it's very common to want this check to be "false"

Un autre exemple courant:

null == undefined // returns "true", but in most cases a distinction is necessary

Answer 11

Pourquoi == est-il si imprévisible?

Qu'est-ce que vous obtenez lorsque vous comparez une chaîne vide "" avec le nombre zéro 0?

true

Oui, c'est bien selon == une chaîne vide et le nombre zéro sont identiques.

Et cela ne s'arrête pas là, en voici un autre:

'0' == false // true

Les choses deviennent vraiment bizarres avec les tableaux.

[1] == true // true
[] == false // true
[[]] == false // true
[0] == false // true

alors plus étrange avec des chaînes

[1,2,3] == '1,2,3' // true - REALLY?!
'\r\n\t' == 0 // true - Come on!

Ça s'empire:

Quand est égal pas égal?

let A = ''  // empty string
let B = 0   // zero
let C = '0' // zero string

A == B // true - ok... 
B == C // true - so far so good...
A == C // **FALSE** - Plot twist!

Laissez-moi répéter ça:

(A == B) && (B == C) // true
(A == C) // **FALSE**

Et ceci est juste le truc fou que vous obtenez avec les primitifs.

C'est un tout nouveau niveau de fou lorsque vous utilisez == avec des objets.

À ce stade, vous vous demandez probablement ...

Pourquoi cela se produit-il?

Eh bien c'est parce que contrairement à "triple égal" (===) qui vérifie simplement si deux valeurs sont identiques.

== fait un tout un tas d'autres choses .

Il a un traitement spécial pour les fonctions, un traitement spécial pour les valeurs NULL, non défini, les chaînes, vous le nommez.

Ça devient plutôt délirant.

En fait, si vous essayez d’écrire une fonction qui fait ce que == ressemble à ceci:

function isEqual(x, y) { // if `==` were a function
    if(typeof y === typeof x) return y === x;
    // treat null and undefined the same
    var xIsNothing = (y === undefined) || (y === null);
    var yIsNothing = (x === undefined) || (x === null);

    if(xIsNothing || yIsNothing) return (xIsNothing && yIsNothing);

    if(typeof y === "function" || typeof x === "function") {
        // if either value is a string 
        // convert the function into a string and compare
        if(typeof x === "string") {
            return x === y.toString();
        } else if(typeof y === "string") {
            return x.toString() === y;
        } 
        return false;
    }

    if(typeof x === "object") x = toPrimitive(x);
    if(typeof y === "object") y = toPrimitive(y);
    if(typeof y === typeof x) return y === x;

    // convert x and y into numbers if they are not already use the "+" trick
    if(typeof x !== "number") x = +x;
    if(typeof y !== "number") y = +y;
    // actually the real `==` is even more complicated than this, especially in ES6
    return x === y;
}

function toPrimitive(obj) {
    var value = obj.valueOf();
    if(obj !== value) return value;
    return obj.toString();
}

Alors qu'est-ce que cela signifie?

Cela signifie que == est compliqué.

Parce que c'est compliqué, il est difficile de savoir ce qui va arriver quand vous l'utilisez.

Ce qui signifie que vous pourriez vous retrouver avec des bugs.

Donc la morale de l'histoire est ...

Rendez votre vie moins compliquée.

Utilisez === au lieu de ==.

La fin.

Answer 12

Diagramme de flux d'exécution Javascript pour l'égalité stricte/Comparaison '==='

Diagramme de flux d'exécution Javascript pour l'égalité/comparaison non stricte '=='

Answer 13

JavaScript ===vs==.

0==false   // true
0===false  // false, because they are of a different type
1=="1"     // true, auto type coercion
1==="1"    // false, because they are of a different type

Answer 14

Cela signifie égalité sans contrainte de type la contrainte de type signifie que JavaScript ne convertit pas automatiquement les autres types de données en types de données chaîne

0==false   // true,although they are different types

0===false  // false,as they are different types

2=='2'    //true,different types,one is string and another is integer but 
            javaScript convert 2 to string by using == operator 

2==='2'  //false because by using === operator ,javaScript do not convert 
           integer to string 

2===2   //true because both have same value and same types 

Answer 15

Dans un script typique, il n'y aura pas de différence de performances. Plus important peut-être le fait que mille "===" soit 1 Ko plus lourd que mille "==" :) profileurs JavaScript peut vous dire s'il y a une différence de performance dans votre cas.

Mais personnellement, je ferais ce que JSLint suggère. Cette recommandation n’est pas là en raison de problèmes de performances, mais parce que la contrainte de type signifie que ('\t\r\n' == 0) est vrai.

Answer 16

L'opérateur de comparaison d'égalité == est source de confusion et devrait être évité.

Si vous DOVE TO vivez avec, souvenez-vous des 3 choses suivantes:

1. Ce n'est pas transitif: (a == b) et (b == c) ne conduit pas à (a == c)
2. c'est mutuellement exclusif à sa négation: (a == b) et (a! = B ) conservent toujours les valeurs booléennes opposées, avec tous a et b.
3. En cas de doute, apprenez par cœur la table de vérité suivante:

TABLEAU DE VÉRITÉ D'OPÉRATEUR ÉGAL EN JAVASCRIPT

• Chaque ligne de la table est un ensemble de 3 valeurs "égales", ce qui signifie que 2 valeurs quelconques entre elles sont égales en utilisant le signe égal ==

** STRANGE: notez que deux valeurs quelconques de la première colonne ne sont pas égales en ce sens. **

''       == 0 == false   // Any two values among these 3 ones are equal with the == operator
'0'      == 0 == false   // Also a set of 3 equal values, note that only 0 and false are repeated
'\t'     == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\r'     == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\n'     == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\t\r\n' == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

null == undefined  // These two "default" values are not-equal to any of the listed values above
NaN                // NaN is not equal to any thing, even to itself.

Answer 17

Oui! Cela compte.

=== opérateur en javascript vérifie la valeur ainsi que le type où l'opérateur == vérifie simplement la valeur (la conversion de type est nécessaire).

Vous pouvez facilement le tester. Collez le code suivant dans un fichier HTML et ouvrez-le dans le navigateur

<script>

function onPageLoad()
{
    var x = "5";
    var y = 5;
    alert(x === 5);
};

</script>

</head>

<body onload='onPageLoad();'>

Vous obtiendrez 'false' en alerte. Modifiez maintenant la méthode onPageLoad() en alert(x == 5); vous obtiendrez true.

Answer 18

Il est peu probable qu'il y ait une différence de performances entre les deux opérations dans votre utilisation. Il n'y a pas de conversion de type à faire car les deux paramètres sont déjà du même type. Les deux opérations auront une comparaison de type suivie d'une comparaison de valeur.

Answer 19

=== L'opérateur vérifie les valeurs ainsi que les types de variables pour vérifier leur égalité.

== l'opérateur vérifie simplement la valeur des variables pour l'égalité.

Answer 20

C'est un test de contrôle strict.

C'est une bonne chose, surtout si vous vérifiez entre 0 et false et null.

Par exemple, si vous avez:

$a = 0;

Ensuite:

$a==0; 
$a==NULL;
$a==false;

Tout retourne vrai et vous ne voudrez peut-être pas cela. Supposons que vous ayez une fonction pouvant renvoyer le 0ème index d'un tableau ou false en cas d'échec. Si vous vérifiez avec "==" false, vous pouvez obtenir un résultat déroutant.

Donc, avec la même chose que ci-dessus, mais un test strict:

$a = 0;

$a===0; // returns true
$a===NULL; // returns false
$a===false; // returns false

Answer 21

JSLint vous donne parfois des raisons irréalistes de modifier des éléments. === a exactement les mêmes performances que == si les types sont déjà identiques.

Il est plus rapide que lorsque les types ne sont pas identiques, auquel cas il n'essaye pas de convertir les types mais renvoie directement un faux.

Donc, IMHO, JSLint peut être utilisé pour écrire du nouveau code, mais une sur-optimisation inutile devrait être évitée à tout prix.

Cela signifie qu'il n'y a aucune raison de changer == en === dans un chèque tel que if (a == 'test') alors que vous le savez parfaitement, un a ne peut être qu'une chaîne.

Modifier beaucoup de code de cette façon fait perdre du temps aux développeurs et aux relecteurs et ne produit rien.

Answer 22

Simplement

== signifie comparaison entre opérandes avectype conversion

Et

=== signifie comparaison entre opérandes sanstype conversion

La conversion de type en javaScript signifie que javaScript convertit automatiquement tous les autres types de données en types de données string.

Par exemple:

123=='123'   //will return true, because JS convert integer 123 to string '123'
             //as we used '==' operator 

123==='123' //will return false, because JS do not convert integer 123 to string 
            //'123' as we used '===' operator 

Answer 23

Un exemple simple est

2 == '2'  -> true, values are SAME because of type conversion.

2 === '2'  -> false, values are NOT SAME because of no type conversion.

Answer 24

Les deux premières réponses à la fois mentionnées == signifie l'égalité et === signifie identité. Malheureusement, cette déclaration est incorrecte.

Si les deux opérandes de == sont des objets, ils sont comparés pour voir s’ils sont le même objet. Si les deux opérandes pointent sur le même objet, l'opérateur égal renvoie true. Sinon, les deux ne sont pas égaux.

var a = [1, 2, 3];  
var b = [1, 2, 3];  
console.log(a == b)  // false  
console.log(a === b) // false  

Dans le code ci-dessus, == et === deviennent faux car a et b ne sont pas les mêmes objets.

Autrement dit: si les deux opérandes de == sont des objets, == se comporte de la même manière que ===, ce qui signifie également identité. La différence essentielle entre ces deux opérateurs concerne la conversion de type. == a une conversion avant de vérifier l’égalité, mais pas ===.

Answer 25

En règle générale, j'utiliserais généralement === au lieu de == (et !== au lieu de !=).

Les raisons sont expliquées dans les réponses ci-dessus et Douglas Crockford est assez clair à ce sujet ( JavaScript: The Good Parts ).

Cependant, il existe une seule exception : == null est un moyen efficace de vérifier si 'est nul ou non défini':

if( value == null ){
    // value is either null or undefined
}

Par exemple, jQuery 1.9.1 utilise ce modèle 43 fois, et le vérificateur de syntaxe JSHint fournit même l'option eqnull relaxante pour cette raison.

De la guide de style jQuery :

Des contrôles d'égalité stricts (===) doivent être utilisés en faveur de ==. La seule exception concerne la vérification de indéfini et null au moyen de null.

// Check for both undefined and null values, for some important reason. 
undefOrNull == null;

Answer 26

Le problème est que vous pourriez facilement avoir des problèmes, car JavaScript comporte de nombreuses conversions implicites, ce qui signifie ...

var x = 0;
var isTrue = x == null;
var isFalse = x === null;

Ce qui devient vite un problème. Le meilleur exemple de la raison pour laquelle la conversion implicite est "diabolique" peut être tiré de ce code dans MFC /C++ qui sera compilé en raison d'une conversion implicite de CString en HANDLE, qui est un type de type pointeur. ..

CString x;
delete x;

Ce qui évidemment pendant l'exécution fait très des choses non définies ...

Google pour les conversions implicites en C++ et STL pour obtenir certains des arguments qui s’y opposent ...

Answer 27

De la référence JavaScript principale

=== Retourne true si les opérandes sont strictement égaux (voir ci-dessus) sans conversion de type.

Answer 28

Comparaison d'égalité:

Opérateur ==

Renvoie true lorsque les deux opérandes sont égaux. Les opérandes sont convertis dans le même type avant d'être comparés.

>>> 1 == 1
true
>>> 1 == 2
false
>>> 1 == '1'
true

Égalité et comparaison de types:

Opérateur ===

Renvoie true si les deux opérandes sont égaux et du même type. C'est généralement mieux et plus sûr si vous comparez de la sorte, car il n'y a pas de conversions en arrière-plan.

>>> 1 === '1'
false
>>> 1 === 1
true

Answer 29

Voici un tableau de comparaison pratique montrant les conversions effectuées et les différences entre == et ===.

Comme le dit la conclusion:

"Utilisez trois égaux à moins de bien comprendre les conversions effectuées pour deux égaux."

http://dorey.github.io/JavaScript-Equality-Table/

Answer 30

* Opérateurs === vs == *

1 == true    =>    true
true == true    =>    true
1 === true    =>    false
true === true    =>    true

Answer 31

null et indéfini sont le néant, c'est-à-dire

var a;
var b = null;

Ici a et b n'ont pas de valeurs. Alors que 0, faux et '' sont tous des valeurs. Une chose commune entre tous ceux-ci est qu'ils sont tous des valeurs fausses, ce qui signifie qu'ils tous satisfaire conditions fausses.

Donc, 0, faux et '' ensemble forment un sous-groupe. Et d'autre part, null & indéfini forment le deuxième sous-groupe. Vérifiez les comparaisons dans l'image ci-dessous. null et undefined seraient égaux. Les trois autres seraient égaux les uns aux autres. Mais, ils sont tous traités comme des conditions de fausseté en JavaScript.

Ceci est identique à tout objet (comme {}, tableaux, etc.), une chaîne non vide et Boolean true sont toutes des conditions de vérité. Mais ils ne sont pas tous égaux.

Answer 32

JavaScript comporte des comparaisons strictes et des conversions de types. Une comparaison stricte (par exemple, ===) n'est vraie que si les opérandes sont du même type. La comparaison abstraite la plus couramment utilisée (par exemple, ==) convertit les opérandes dans le même type avant de procéder à la comparaison.

• L'opérateur d'égalité (==) convertit les opérandes s'ils ne sont pas du même type, puis applique une comparaison stricte. Si l'un des opérandes est un nombre ou un booléen, les opérandes sont convertis en nombres si possible; sinon, si l'un des opérandes est une chaîne, l'opérande est converti en nombre si possible. Si les deux opérandes sont des objets, JavaScript compare les références internes qui sont égales lorsque les opérandes font référence au même objet en mémoire.

  Syntaxe:

  x == y

  Exemples:

  3 == 3     // true
  "3" == 3   // true
  3 == '3'   // true
  

• L'opérateur identité/égalité stricte (===) renvoie true si les opérandes sont strictement égaux (voir ci-dessus) sans conversion de type.

  Syntaxe:

  x === y

  Exemples:

  3 === 3 // true

Pour référence: opérateurs de comparaison (réseau de développeurs Mozilla)

Answer 33

Si vous créez une application Web ou une page sécurisée, vous devez toujours utiliser (uniquement lorsque cela est possible)

===

car il va vérifier si c'est le même contenu et si c'est du même type!

alors quand quelqu'un entre:

var check = 1;
if(check == '1') {
    //someone continued with a string instead of number, most of the time useless for your webapp, most of the time entered by a user who does not now what he is doing (this will sometimes let your app crash), or even worse it is a hacker searching for weaknesses in your webapp!
}

mais avec

var check = 1;
if(check === 1) {
    //some continued with a number (no string) for your script
} else {
    alert('please enter a real number');
}

un pirate informatique n'ira jamais plus loin dans le système pour trouver des bugs et pirater votre application ou vos utilisateurs

mon point est que le

===

ajoutera plus de sécurité à vos scripts

bien sûr, vous pouvez également vérifier si le nombre entré est valide, est une chaîne, etc. avec d'autres instructions if dans le premier exemple, mais c'est pour le moins plus facile à comprendre et à utiliser

La raison pour laquelle j'ai posté ceci est que le mot "plus sécurisé" ou "sécurité" n'a jamais été dit dans cette conversation (si vous regardez sur iCloud.com, il utilise 2019 fois === et 1308 fois ==, cela signifie également que vous utilisez parfois == au lieu de === car sinon, votre fonction sera bloquée, mais comme indiqué au début, vous devez utiliser === autant que possible)

Answer 34

=== se soucie de savoir si les objets sont les mêmes. Par conséquent, new String("Hello world") === "Hello world" renvoie false. Cependant, == ne se soucie pas de savoir si les objets sont les mêmes; il convertit simplement un argument dans le type de l'autre: si la conversion n'est pas possible, retourne false. Ensuite, new String("Hello world") == "Hello world" renvoie true au lieu de false.

Answer 35

Mon processus de raisonnement utilisant emacs org-mode et node.js pour exécuter un test.

| use =      | '' | '0' | false | 'false' | undefined | null | ' \t\r\n ' |
| ''         | x  | f   | t     | f       | f         | f    | f          |
| '0'        |    | x   | t     | f       | f         | f    | f          |
| false      |    |     | x     | f       | f         | f    | t          |
| 'false'    |    |     |       | x       | f         | f    | f          |
| undefined  |    |     |       |         | x         | t    | f          |
| null       |    |     |       |         |           | x    | f          |
| ' \t\r\n ' |    |     |       |         |           |      | x          | 



| use ===    | '' | '0' | false | 'false' | undefined | null | ' \t\r\n ' |
| ''         | x  | f   | f     | f       | f         | f    | f          |
| '0'        |    | x   | f     | f       | f         | f    | f          |
| false      |    |     | x     | f       | f         | f    | f          |
| 'false'    |    |     |       | x       | f         | f    | f          |
| undefined  |    |     |       |         | x         | f    | f          |
| null       |    |     |       |         |           | x    | f          |
| ' \t\r\n ' |    |     |       |         |           |      | x          |

Mon script de test ci-dessous: exécuter> noeud xxx.js

var rowItems = ['', '0', false, 'false', undefined, null, ' \t\r\n ']
var colItems = rowItems

for(var i = 0; i < rowItems.length; i++) {
    for (var j = 0; j < colItems.length; j++) {
        var r = (rowItems[i] === colItems[j]) ? true : false;
        console.log(rowItems[i] + " = " + colItems[j] + " " + r + " [" + i + "] ==> [" + j + "]")
    };
}

Answer 36

Le javascript est un langage faiblement typé c'est-à-dire sans aucun type de données comme en C, c ++, par exemple. int, boolean, float, etc. ainsi une variable peut contenir n'importe quel type de valeur, c'est pourquoi ces opérateurs de comparaison spéciaux sont là

Par exemple

var i = 20;var j = "20";

si nous appliquons des opérateurs de comparaison ces résultats de variables seront

i==j //result is true

ou

j != i//result is false

pour cela, nous avons besoin d’un opérateur de comparaison spécial qui vérifie le valeur ainsi que le type de données de la variable

si nous faisons

i===j //result is false

Answer 37

Différent entre =, = =, = = =

• Opérateur = Utilisé pour attribuer simplement la variable value.
• Opérateur = = Utilisé uniquement pour comparer le values pas datatype
• Opérateur = = = Utilisé pour comparer la values ainsi que datatype.

Answer 38

== l'opérateur compare simplement les valeurs et non le type de données

=== l'opérateur compare les valeurs avec la comparaison de son type de données

par exemple.

1 == "1" //true

1 === "1" //false

Opérateur "===" utilisé dans les langues effectuant la conversion automatique, par exemple. PHP, Javascript. L'opérateur "===" permet d'éviter les comparaisons inattendues causées par la conversion automatique.

Answer 39

toujours utilisez '===' et vous éviterez des milliers d'erreurs. De nos jours, l’égalité triple est préférable entre différents guides de style, car elle permet de prendre en compte le type d’opérandes.

Answer 40

Une raison non mentionnée d'utiliser === - est dans le cas où vous coexistez avec/une compilation croisée vers/à partir de coffee-script. De la petit livre sur CoffeeScript ...

La comparaison d'égalité faible en JavaScript a un comportement déroutant et est souvent à l'origine de bogues déroutants.

La solution consiste plutôt à utiliser l'opérateur d'égalité stricte, composé de trois signes égaux: ===. Cela fonctionne exactement comme l'opérateur d'égalité normal, mais sans aucune contrainte de type. Il est recommandé de toujours utiliser l'opérateur d'égalité stricte et de convertir explicitement les types si nécessaire.

Si vous convertissez régulièrement vers et à partir de coffee-script, vous devez simplement utiliser ===. En fait, le compilateur coffee-script vous forcera à ...

CoffeeScript résout ce problème en remplaçant simplement toutes les comparaisons faibles par des comparaisons strictes, autrement dit en convertissant tous les comparateurs == en ===. Vous ne pouvez pas faire une comparaison d’égalité faible dans CoffeeScript et vous devez convertir explicitement les types avant de les comparer si nécessaire.

Answer 41

Oui, il y a une grande différence entre les opérateurs d'égalité == et d'identité ===.
Généralement, l’opérateur d’identité fonctionne plus rapidement, car aucun type de conversion n’est effectué. Mais si les valeurs sont du même type, vous ne verrez aucune différence.
Check my post La légende de l'opérateur d'égalité JavaScript , qui explique les détails, y compris les types d'algorithmes de conversion et de comparaison, avec de nombreux exemples.

Answer 42

L'égalité stricte est pour la plupart meilleure

Le fait que Javascript soit une langue assez typée doit rester constamment à l’esprit pendant que vous travaillez avec. Tant que la structure de données est la même, il n'y a aucune raison de ne pas utiliser une égalité stricte; avec une égalité régulière, vous obtenez souvent une conversion implicite des valeurs qui se produit automatiquement, cela peut avoir des effets considérables sur votre code. Il est très facile d’avoir des problèmes avec cette conversion car ils se produisent automatiquement.

Avec une égalité stricte, il n’ya pas de conversion implicite automatique car les valeurs doivent déjà avoir la structure de données correcte.

Answer 43

Utilisez === si vous voulez comparer deux choses en JavaScript, cela s'appelle égalité stricte, cela signifie que cela retournera true si seuls le type et la valeur sont identiques =, donc il n’y aurait pas de correction de type non désirée pour vous, si vous utilisiez ==, vous vous en ficheiez, et dans de nombreux cas, vous pourriez faire face à des problèmes de comparaison d’égalité lâche.

égalité stricte avec ===

Une égalité stricte compare deux valeurs pour l'égalité. Aucune de ces valeurs n'est implicitement convertie en une autre valeur avant d'être comparée. Si les valeurs ont des types différents, les valeurs sont considérées comme étant inégales. Sinon, si les valeurs ont le même type et ne sont pas des nombres, elles sont considérées comme égales si elles ont la même valeur. Enfin, si les deux valeurs sont des nombres, elles sont considérées comme égales si elles ne sont pas toutes les deux NaN et qu'elles ont la même valeur, ou si l'une est +0 et l'autre -0.

var num = 0;
var obj = new String('0');
var str = '0';

console.log(num === num); // true
console.log(obj === obj); // true
console.log(str === str); // true

console.log(num === obj); // false
console.log(num === str); // false
console.log(obj === str); // false
console.log(null === undefined); // false
console.log(obj === null); // false
console.log(obj === undefined); // false

égalité lâche utilisant ==

L'égalité lâche compare deux valeurs pour l'égalité après avoir converti les deux valeurs en un type commun. Après les conversions (une ou les deux parties peuvent subir des conversions), la comparaison d’égalité finale est effectuée exactement de la même manière que ===. L'égalité en vrac est symétrique: A == B a toujours une sémantique identique à B == A pour toutes les valeurs de A et B (à l'exception de l'ordre des conversions appliquées).

var num = 0;
var obj = new String('0');
var str = '0';

console.log(num == num); // true
console.log(obj == obj); // true
console.log(str == str); // true

console.log(num == obj); // true
console.log(num == str); // true
console.log(obj == str); // true
console.log(null == undefined); // true

// both false, except in rare cases
console.log(obj == null);
console.log(obj == undefined);

Answer 44

Il est suggéré de remplacer == par === parce que l'opérateur === est plus fiable que ==. Dans notre contexte, les moyens fiables === s'appliquent également à la vérification de type. Considérant les meilleures pratiques de programmation, nous devrions toujours choisir une fonctionnalité plus fiable que moins fiable. De nouveau, chaque fois que nous pensons que la plupart du temps, nous sommes exactement égaux à l'opérateur, nous considérons par défaut que le type doit être identique. Comme === fournit la même chose, nous devrions y aller.

Answer 45

Javascript est typé comme php,

var x = "20";
var y =20;

if (x===y) // false

Cela vous donnera toujours un faux parce que même si les valeurs des variables sont les mêmes, les types de données ne sont pas

L'un est une chaîne l'autre est un entier

If(x==y)//true

Cependant, cela vérifie simplement si le contenu est le même, quel que soit le type de données ...

Je ne veux pas dire que les valeurs sont égales, car une valeur de chaîne ne peut pas être égale à une valeur int logiquement

Answer 46

Premièrement, une terminologie concernant la chaîne Javascript est égale à: Double égal est officiellement appelé opérateur de comparaison d'égalité abstraite, tandis que triple égal est appelé opérateur de comparaison d'égalité stricte. La différence entre eux peut être résumée comme suit: L’égalité abstraite tente de résoudre les types de données par coercition de type avant la comparaison. Une égalité stricte renverra false si les types sont différents. Prenons l'exemple suivant:

console.log(3 == "3"); // true
console.log(3 === "3"); // false.
console.log(3 == "3"); // true
console.log(3 === "3"); // false.

L'utilisation de deux signes égaux renvoie true car la chaîne "3" est convertie en nombre 3 avant la comparaison. Trois signes égaux voient que les types sont différents et retournent faux. En voici un autre:

console.log(true == '1'); // true
console.log(true === '1'); // false
console.log(true == '1'); // true
console.log(true === '1'); // false

De nouveau, la comparaison d'égalité abstraite effectue une conversion de type. Dans ce cas, le booléen true et la chaîne "1" sont convertis en nombre 1 et le résultat est true. Une égalité stricte renvoie faux.

Si vous comprenez que vous êtes sur la bonne voie pour faire la distinction entre == et ===. Cependant, il existe certains scénarios dans lesquels le comportement de ces opérateurs n’est pas intuitif. Voyons quelques exemples supplémentaires:

console.log(undefined == null); // true
console.log(undefined === null); // false. Undefined and null are distinct types and are not interchangeable.
console.log(undefined == null); // true     
console.log(undefined === null); // false. Undefined and null are distinct types and are not interchangeable.

console.log(true == 'true'); // false. A string will not be converted to a boolean and vice versa.
console.log(true === 'true'); // false
console.log(true == 'true'); // false. A string will not be converted to a boolean and vice versa.
console.log(true === 'true'); // false

L'exemple ci-dessous est intéressant car il montre que les littéraux de chaîne sont différents des objets de chaîne.

console.log("This is a string." == new String("This is a string.")); // true
console.log("This is a string." === new String("This is a string.")); // false
console.log("This is a string." == new String("This is a string.")); // true
console.log("This is a string." === new String("This is a string.")); // false

Answer 47

Le dilemme de "Devrais-je utiliser _==_ ou _===_ en comparaison JavaScript" est équivalent ou analogue à une question de: "Devrais-je utiliser une" cuillère "ou une" fourchette "pour manger.

La seule réponse raisonnable à cette question est que

1. Vous devez utiliser Type dynamique comparaison, par exemple: ___==_ pour Type lâche comparaisons.
2. Vous devez utiliser Type statique comparaison, par exemple: ___===_ pour forte Type comparaisons.

C'est parce qu'ils ne sont pas les mêmes. Ils n'ont pas le même but et ne sont pas destinés à être utilisés dans le même but.

Bien sûr, les "fourchettes" et les "cuillères" sont destinées à "manger", mais vous choisirez de les utiliser en fonction de ce que vous avez été servi à manger.

Signification: vous allez utiliser une "cuillère" i.e .: _==_ pour avoir une "soupe" et/ou la "fourchette" i.e .: _===_ pour la cueillette.

Demander s'il est préférable d'utiliser une "fourchette" ou une "cuillère" pour "manger" - équivaut à demander s'il est préférable d'utiliser une méthode statique [===] ou dynamique [==], op. dans JS. Les deux questions sont également erronées et reflètent une compréhension très étroite ou superficielle du sujet en question.

Answer 48

var a = new String("123");
var b = "123";

alert(a === b); // returns false !! (but they are equal and of the same type)

Vu cela dans l'une des réponses. a et b ne sont pas vraiment du même type dans ce cas, si vous vérifiez typeof(a) vous obtiendrez 'objet' et typeof(b) est 'chaîne'.