長い数値文字列の比較問題

この投稿は、anyilaoliu によって最終編集されました: 2013-12-13 15:04:43

タイトルの通り
このような問題に遭遇しました

$a = "222111565652521142";		$b = "222111565652521139";		$c = 222111565652521142;		$d = 222111565652521139;		var_dump($a);		echo "<br/>";		var_dump($b);		echo "<br/>";		var_dump($c);		echo "<br/>";		var_dump($d);		echo "<br/>";		if ($a == $b) {			echo 3;		}else{			echo 31;		}		echo "<br/>";		if ($c == $d) {			echo 4;		}else{			echo 41;		}		echo "<br/>";

結果は

string '222111565652521142' (length=18)string '222111565652521139' (length=18)float 2.2211156565252E+17float 2.2211156565252E+17314

ここで質問が来ます、に2 番目のケースに進みます。 2 つの比較

質問 2: データベースから読み取られた 2 つの数値セットは、var_dump の後に string(18) として表示されます。ただし、比較結果は上記の比較とまったく逆になります。等価性を表す 2 つの文字列も合格しました

解く

ディスカッションへの返信 (解決策)

11 桁を超える整数は文字列として扱ってください
浮動小数点数の特性により、精度の高い場合には使用できません。要件

11 桁を超える整数を扱ってください 文字列として処理します
浮動小数点数の特性により、高精度が要求される状況では使用できません

これを学びました

また、今日もう一度試してみたところ、私の環境では、18 の 2 つの文字列形式です。長さが 10 桁のアラビア数字の場合、== 演算子は比較するときに最後の 2 桁を無視します。別の環境では、数値が内部で変換されるはずです。この問題は発生しません。2 つの文字列は、== 演算子を使用してください。

この現象が発生する原因となる設定や拡張機能を教えてください。 32 ビット環境では、long 整数は 4 バイトを使用します 表現される
は、-pow(2,31) と pow(2,31) の間にあります
pow(2,31) = 2147483648

pow(2,32) = 4294967296

これでは明らかに一般的なニーズを満たすことができないため、php には logn タイプに基づいていくつかの拡張機能が作成されています。整数
を格納するために 6 バイトが使用されます。これは、-99999999999999 か​​ら 99999999999999 までの正の数、つまり 14 ビット整数
を表すことができることを意味します。64 ビット PHP では、この制限を簡単に超えることができます。 -bit 環境では、logn 型自体は 8 バイトです




=== を使用しても変換されません

私たちが使用する PHP 環境のほとんどは 32 ビットであり、32 ビット環境では長整数型数値は 4 バイトで表されます
つまり、-pow(2,31) と pow(2,31) の間

pow(2,31) = 2147483648

pow(2,32) = 4294967296

これは明らかに一般を満たすことができません必要に応じて、php は logn タイプに基づいていくつかの拡張機能を作成しました。 6 バイトは、-99999999999999 か​​ら 99999999999999 までの正の数を表す整数

を格納するために使用されます。つまり、14 ビット整数

64 ビットの PHP では、この制限を簡単に超えることができます。環境では、logn タイプ自体は 8 バイトです
混乱を解消してくれてありがとう、xu さん、なぜ 64 ビットと 32 ビットの問題について以前に考えなかったのでしょう... もちろん、説明しませんでした。これは、PHP 自体のコードとドキュメントの間に関係があることを詳しく見てきました