PHP - Zufälliges rundes Verhalten Problem

Question

Ich habe tatsächlich ein großes Problem mit mehreren Websites (eigentlich 3) auf Prestashop. Das Problem ist, dass PHP oder Prestashop die Preise zufällig auf die nächste ganze Zahl runden und es ist nicht systematisch.

Die meiste Zeit, es funktioniert perfekt, wie es sollte, aber manchmal (es kann Wochen oder Monate zwischen zwei Problemen dauern), wird ein Preis gerundet. Meine Option für den runden Modus ist korrekt eingestellt, um zwei Dezimalstellen anzuzeigen.

Das Problem kann auftreten, wenn ein Produktpreis im Back-Office bearbeitet wird oder wenn sich der Kunde im Checkout-Schritt befindet.

Ich habe versucht, das Problem zu reproduzieren, also habe ich einen grundlegenden Test erstellt: Ich erhalte eine Warenkorbinformation und ich zeige seinen Preis an. Ich habe die Seite mehrmals aktualisiert und sah den Preis nur ein paar Mal gerundet. Das Interessanteste ist, dass sich weder der Kontext noch der Code zwischen dem Beginn und dem Ende des Tests geändert haben.

ich Hilfe bei Google gesucht und niemand schien dieses Problem zu haben ...

Hat jemand dieses Problem begegnen? Glaubst du, dass es sich um ein PHP-Problem oder ein Prestashop-Problem handelt? Vielen Dank im Voraus für Ihre Hilfe. Hier

ist der Code, der Rundenfunktion Prestashop verwendet:

round($value, 2, PHP_ROUND_HALF_UP); 

Informationen, die PHP-Version 5.4.39.

Answer 1

Mehr als 2 Jahre später haben wir das Problem herausgefunden. Es lag an php5-fpm, die nicht mit Locales pro Thread, sondern pro Prozess umgehen. Es ist wirklich klar in PHP documentation:

Warnung Die locale Informationen werden pro Prozess behandelt, nicht pro Thread. Wenn Sie PHP auf einer Multithread-Server-API wie IIS, HHVM oder Apache unter Windows ausführen, können plötzliche Änderungen der Gebietsschemaeinstellungen während der Ausführung eines Skripts auftreten, obwohl das Skript selbst nie setlocale() aufgerufen hat. Dies geschieht aufgrund anderer Skripts, die gleichzeitig in verschiedenen Threads des gleichen Prozesses ausgeführt werden, wobei das prozessweite Gebietsschema mithilfe von setlocale() geändert wird.

Da das Dezimaltrennzeichen geändert wurde, erkannte PHP keine Dezimalzahlen und trunkierte meine Zahlen.

Answer 2

Vielleicht gibt es ein Problem, wenn der Preis ein Tausend-Trennzeichen wie 12,300.20 hat?

Bitte haben Sie folgendes beachten:

Hinweis: PHP nicht behandelt Zeichenfolgen wie „12,300.2“ standardmäßig korrekt. Siehe Konvertieren von Strings.

See: http://php.net/round

Answer 3

Ich bin fast sicher, seine, wie die Gleitkommazahlen in Ihrem Computer oder etwas in diese Richtung gespeichert sind, das könnte man in die richtige Richtung weisen.

http://php.net/manual/en/language.types.float.php

prüfen dies auch aus und erklärt, warum Gleitkommazahlen nicht immer gleich, wenn Sie denken, sie sollten. http://docstore.mik.ua/orelly/webprog/pcook/ch02_03.htm#phpckbk-CHP-2-SECT-3

Answer 4

Möglicherweise gibt es Probleme mit Gebietsschemas. Im Deutschen sind zum Beispiel Tausendertrennzeichen und Dezimalstellen genau umgekehrt. Wenn Sie nicht sehr vorsichtig damit umgehen, können Sie falsche Werte in einer Persistenz speichern oder einen Wert brechen, wenn Sie sie in Float umwandeln. Denken Sie daran - wenn die Berechnung mit Strings (zB: "2.55") php in float umwandelt, führt die Behandlung von deutschen Zahlen ("2,55") zu einer falschen Gleitkommazahl.

(float) "2.55" = 2.55 
(float) "2,55" = 2 

Das Problem kann behoben werden, indem die Ländereinstellungen korrekt konfiguriert werden.

Wenn Sie in der Lage sind, automatisch ein falsches Ergebnis von einem gültigen zu unterscheiden, sollten Sie das debug_backtrace an diesem Punkt protokollieren, um den Programmablauf in diesem Fall zu bewerten.