blocks|key|611345|text|==运算符将尝试匹配值，即使它们属于不同的类型。例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|611346|'0'+==+0+will+be+true|code-block|syntax|javascript|611347|如果您还需要类型比较，请使用===运算符：|611348|'0'+===+0+will+be+false|611349|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

The == operator will try to match values even if they are of different types. For instance:

<pre><code>'0' == 0 will be true
</code></pre>

If you need type comparison as well, use the === operator: 

<pre><code>'0' === 0 will be false
</code></pre>

blocks|key|611423|text|在PHP中有一个相当方便的方法来验证"0"，"+false+"，"off“作为==+false和"1"，"on"，"+true”的组合作为==+true，这是经常被忽视的。它对于解析GET/POST参数特别有用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|611424|filter_var(+$item['price'],+FILTER_VALIDATE_BOOLEAN+);|code-block|syntax|javascript|611425|它与这个用例并不完全相关，但考虑到相似性和事实，这是搜索在询问验证(字符串)“0”是否为false的问题时倾向于发现的结果，我认为这会对其他人有所帮助。|611426|http://www.php.net/manual/en/filter.filters.validate.php|offset|length|611427|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|1K|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|U|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|V|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|W|8|@]|9|@$K|X|L|Y|1|Z]]|A|$]]|$1|M|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|J]]]]

There's a rather handy method in PHP for validating a mix of "0", "false", "off" as == false and "1", "on", "true" as == true which is often overlooked. It's particularly useful for parsing GET/POST arguments:

<pre><code>filter_var( $item['price'], FILTER_VALIDATE_BOOLEAN );
</code></pre>

It's not wholy relevant to this use-case but given the similarity and fact this is the result search tends to find when asking the question of validating (string)"0" as false I thought it would help others.

<a href="http://www.php.net/manual/en/filter.filters.validate.php" rel="noreferrer">http://www.php.net/manual/en/filter.filters.validate.php</a>

blocks|key|611516|text|你的问题是双等运算符，它会将右成员类型转换为左类型。如果您愿意，可以使用strict。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|611517|if($item['price']+==+'e')+{
++++$item['price']+=+-1;
}|code-block|syntax|javascript|611518|让我们回到你的代码(上面复制的)。在这种情况下，在大多数情况下，$item‘’price‘是一个整数(显然，当它等于e时除外)。因此，根据PHP的规则，PHP会将"e"类型转换为整数，从而产生int(0)。(不相信我？<?php+$i="e";+echo+(int)$i;+?>)。|offset|length|style|CODE|611519|要轻松摆脱这一点，可以使用三重相等(精确比较)运算符，它将检查类型，而不会隐式进行类型转换。|611520|附言:一个有趣的事实：a+==+b并不意味着b+==+a。拿你的例子来反其道而行之:如果$item‘if+("e"+==+$item['price'])’始终是一个整数，那么价格将永远不会真正实现。|611521|entityMap^0|0|0|29|3|2O|6|31|U|0|0|B|6|M|6|1E|Q|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@$I|V|J|W|K|L]|$I|X|J|Y|K|L]|$I|Z|J|10|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|12|8|@$I|13|J|14|K|L]|$I|15|J|16|K|L]|$I|17|J|18|K|L]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|R|$]]

Your problem is the double equal operator, which will typecast the right member to the type of the left. Use strict if you prefer.

<pre><code>if($item['price'] == 'e') {
 $item['price'] = -1;
}
</code></pre>

Let's go back to your code (copied above). In this case, in most cases, $item['price'] is an integer (except when it is equal to e, obviously). As such, by laws of PHP, PHP will typecast <code>"e"</code> to integer, which yields <code>int(0)</code>. (Don't believe me? <code>&lt;?php $i="e"; echo (int)$i; ?&gt;</code>).

To easily get away from this, use the triple equal (exact comparison) operator, which will check the type and will not implicitly typecast.

P.S: a PHP fun fact: <code>a == b</code> does not imply that <code>b == a</code>. Take your example and reverse it: <code>if ("e" == $item['price'])</code> will never actually be fulfilled provided that $item['price'] is always an integer.

blocks|key|826505|text|我认为最好是通过我做过的例子来说明，同时遇到同样奇怪的行为。请看我的测试用例，希望它能帮助您更好地理解行为：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|826506|//+Normal+comparison+using+the+==+Operator
echo+(0+==+"0");+//+true
echo+(0+==+"a");+//+true
echo+(0+==+"safta!");+//+true
echo+(1000+==+"bla");+//+false.+It+appears+that+PHP+has+a+weird+behavior+only+with+the+number+/+string+0+/+"0"+according+to+the+past+3+examples.
echo+(23+==+"23");+//+true.+So+as+we+said,+PHP+has+a+problem+(not+a+problem+but+weird+behavior)+only+when+the+number+/+string+0+(or+"0")+is+present
echo+(23+==+"24");+//+false.+values+aren't+equal+(unlike+last+example).+The+type+is+less+relevant+with+the+==+operator+as+we+can+see.

//+Now+using+the+===+and+!==+Operators
echo+("0"+===+0);+//+false,+since+===+requires+both+value+and+type+to+be+the+same.+Here,+type+is+different+(int+vs+string)
echo+("0"+!==+0);+//+true+because+they+aren't+the+same+in+terms+of+===+comparison+(type+is+different+and+that's+why+it's+true)
echo+("bla"+===+"blaa");+//+false+because+the+values+are+not+the+same.+The+type+is+the+same,+but+===+checks+for+both+equal+type+and+equal+value.

//Now+using+casting+and+===+Operator:
echo+((string)123+===+"123");+//+true.+The+casting+of+the+int+123+to+string+changed+it+to+"123"+and+now+both+variables+have+same+value+and+are+of+same+type
echo+((int)"123"+===+123);+//+true.+The+casting+of+the+string+123+to+int,+changed+it+to+int,+and+now+both+variables+are+of+same+value+and+type+(which+is+exactly+what+the+===+operator+is+looking+for)

//+Now+using+casting+and+==+Operator.+Basically,+as+we've+seen+above,+the+==+care+less+for+the
//+type+of+var,+but+more+to+the+value.+So+the+casting+is+less+relevant+here,+because+even
//+without+casting,+like+we+saw+earlier,+we+can+still+compare+string+to+int+with+the+==+operator
//+and+if+their+value+is+same,+we'll+get+true.+Either+way,+we+will+show+that:
echo+((string)123+==+"123");+//+true.+The+casting+of+the+int+123+to+string+changed+it+to+"123"+and+now+both+vars+have+same+value+and+are+of+same+type
echo+((int)"123"+==+123);+//+true.+The+casting+of+the+string+123+to+int,+changed+it+to+int,+and+now+both+vars+are+of+same+value+and+type+(which+is+exactly+what+the+===+operator+is+looking+for)|code-block|syntax|javascript|826507|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I think it is best to show by examples I did, while running into the same weird behavior. See my test case and hopefully it will help you understand the behavior better:

<pre><code>// Normal comparison using the == Operator
echo (0 == "0"); // true
echo (0 == "a"); // true
echo (0 == "safta!"); // true
echo (1000 == "bla"); // false. It appears that PHP has a weird behavior only with the number / string 0 / "0" according to the past 3 examples.
echo (23 == "23"); // true. So as we said, PHP has a problem (not a problem but weird behavior) only when the number / string 0 (or "0") is present
echo (23 == "24"); // false. values aren't equal (unlike last example). The type is less relevant with the == operator as we can see.

// Now using the === and !== Operators
echo ("0" === 0); // false, since === requires both value and type to be the same. Here, type is different (int vs string)
echo ("0" !== 0); // true because they aren't the same in terms of === comparison (type is different and that's why it's true)
echo ("bla" === "blaa"); // false because the values are not the same. The type is the same, but === checks for both equal type and equal value.

//Now using casting and === Operator:
echo ((string)123 === "123"); // true. The casting of the int 123 to string changed it to "123" and now both variables have same value and are of same type
echo ((int)"123" === 123); // true. The casting of the string 123 to int, changed it to int, and now both variables are of same value and type (which is exactly what the === operator is looking for)

// Now using casting and == Operator. Basically, as we've seen above, the == care less for the
// type of var, but more to the value. So the casting is less relevant here, because even
// without casting, like we saw earlier, we can still compare string to int with the == operator
// and if their value is same, we'll get true. Either way, we will show that:
echo ((string)123 == "123"); // true. The casting of the int 123 to string changed it to "123" and now both vars have same value and are of same type
echo ((int)"123" == 123); // true. The casting of the string 123 to int, changed it to int, and now both vars are of same value and type (which is exactly what the === operator is looking for)
</code></pre>

blocks|key|826643|text|基本上，总是使用===运算符，以保证类型安全。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|826644|​|826645|📷|atomic|826646|826647|826648|826649|826650|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/0d20ae3eb9d26d576e4ed18413ac1589.png|imageAlt|1|https://ask.qcloudimg.com/http-save/yehe-900000/a122ce5750006f7ffedad7f2548e2179.png^0|8|3|0|0|0|1|0|0|0|0|0|1|1|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|12|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|13|8|@]|D|@$9|14|A|15|1|16]]|E|$]]|$1|K|3|G|5|6|7|17|8|@]|D|@]|E|$]]|$1|L|3|G|5|6|7|18|8|@]|D|@]|E|$]]|$1|M|3|I|5|J|7|19|8|@]|D|@$9|1A|A|1B|1|1C]]|E|$]]|$1|N|3|G|5|6|7|1D|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|P|$Q|$5|R|S|T|E|$U|V|W|-4]]|X|$5|R|S|T|E|$U|Y|W|-4]]]]

Basically, always use the <code>===</code> operator, to guarantee type safety.

<a href="https://i.stack.imgur.com/eelli.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/eelli.png" alt="Enter image description here"></a>

<a href="https://i.stack.imgur.com/UZTNZ.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/UZTNZ.png" alt="Enter image description here"></a>

I have the following piece of code:

<pre><code>$item['price'] = 0;
/* Code to get item information goes in here */
if($item['price'] == 'e') {
 $item['price'] = -1;
}
</code></pre>

It is intended to initialize the item price to 0 and then get information about it. If the price is informed as 'e' it means an exchange instead of a sell, which is stored in a database as a negative number.

There is also the possibility to leave the price as 0, either because the item is a bonus or because the price will be set in a later moment.

But, whenever the price is not set, which leaves it with the initial value of 0, the <code>if</code> loop indicated above evaluates as true and the price is set to -1. That is, it considers 0 as equal to 'e'.

How can this be explained?

When the price is provided as 0 (after initialization), the behavior is erratic: sometimes the if evaluates as true, sometimes it evaluates as false.*

Why does PHP consider 0 to be equal to a string?

数据库

我有下面这段代码：$item['price'] = 0;/* Code to get item information goes in here */if($item['price'] == 'e') {    $item['price'] = -1;}它的目的是将商品价格初始化为0，然后获取有关它的信息。如果价格被告...

问为什么PHP认为0等于一个字符串？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么PHP认为0等于一个字符串？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么PHP认为0等于一个字符串？
EN