Dotaz: BUG v PHP array_search a in_array ?

[Sparrow]

Zdravím,

teď jsem narazil na asi docela velký problém.
Při hledání v poli mi to tam najde hodnotu která tam není :)

Konkrétně jde o kontrolu voucherů ze Slevomatu, zda zákazník nezadá jeden voucher 2x.
Bohužel si z nějakého důvodu PHP myslí že 6089139600E-908 = 3767958990E-624.

Zkoušel jsem to php sanboxu a zjistil, že to blbne až od PHP v 5.2 :) V nižších verzích to funguje správně.

Výsledek následujího kódu je FIND IN 2

viz http://sandbox.onlinephpfunctions.com/code/df586ba56c8547a21853cade3dd5659195de4852

To samé dělá i in_array, vrací TRUE.

Vyřešil jsem to tím, že pole převedu na řetězec oddělený | a potom to hledám pomocí STRPOS, ale docela mne to rozhodilo.

Co vy na to?

Dan

 
$allCode=array(
    0 => "4911843820E-152",
    1 => "9189208690C-823",
    2 => "6089139600E-908",
    3 => "1847645250C-229",
);

$findCode="3767958990E-624";

$search = array_search($findCode,$allCode);

if($search !== false){
    echo "FIND IN ".$search;
}else{
    echo "NO FIND";
}

---

---

Odpovědi

[Sparrow]

Pardon, ten link se mi nepovedl

http://sandbox.onlinephpfunctions.com/code/df586ba56c8547a21853cade3dd5659195de4852

[Sparrow]

Kratkodobe riesenie: Staci do search_array pridat posledny parameter (strict) true. Potom to bude fungovat.

Dlhodobe riesenie: Prestat pouzivat PHP, uz asi milion krat som zastal na podobnych koninach. Dalsi podobny bonus - retazec "0" je vyhodnoteny ako false a podobne. Proste ked jazyk vznikol bol dobry, ale dnes uz patri na zasluzeny odpocinok.

[Sparrow]

Přidání parametru strict je dlouhodobým řešením.

Dalším (a podle mne mnohem vhodnějším) dlouhodobým řešením je použití databáze, která ve většině případů umí hledat mnohem lépe než PHP.

"0" přece je false. Nechápu, čemu se divíš. Pokud ti to nevyhovuje, použij jiný predikát.

[Jendа]

"0" přece je false.

Ale tazatel nemá "0", ale string s nějakým bordelem. Jenom PHP se snaží být strašně chytré a vyrábí ze stringů floaty a další věci podle potřeby.

[chrono]

Keď poviem Php, aby sa pokúsilo porovnať podobné objekty (napr. pomocou ==, array_search bez strict, ...) zmenou typu, tak nemôžem byť prekvapený, že to naozaj urobí.

[Jendа]

Samozřejmě, a to je deceptive default.

[Kit]

Obvykle je nejlepší takové konstrukce v PHP nepoužívat.

[Sparrow]

Díky za nakopnutí, toho parametru jsem si vůbec nevšiml (nebo zapomněl) nebyl do teď potřeba.

Jinak DB není potřeba jde o eShop a kontrolu pár kódů, než klient dokončí objednávku, o zbytek se pak už stará API Slevomatu.

[Kit]

Ty kódy přece nemáš v aplikaci, ale v databázi, takže uživatelem zadaný string můžeš porovnávat přímo v té databázi.

[Sparrow]

Vím jak to myslíš, ale kupóny se do DB ukládají až po dokončení objednávky. Jako "zboží" s minusovou hodnotou.

Během objednávky se slevové kupóny ukládají pouze do SESSION v DB je pouze zboží.

Je to kvůli tomu, že kupóny můžou mít časové omezení, tak když si vložím nějaké věci do košíku (ID košíku je v COOKIE) a vrátím se za třeba 3 dny tak kupón už může být neplatný.

Díky všem za radu

[Kit]

A jak poznáš pravost kupónu od zákazníka jinak než jeho porovnáním se seznamem platných kupónů?

[Sparrow]

Přes API Slevomatu (tam zkontroji platnost a zboží ke kterému se vztahuje), po dokončení objednávky je přes něj "uplatním" takže už nejde znovu použít.

Kódy si Slevomat generuje sám.

V postatě jeho kód ani nemusím ukládat, stačí mi výrobek a jeho cena co mám odečíst z objednávky, ale ukládám je kvůli pozdější kontrole.

[Jan Vostrý]

Bohužel to není bug ale feature. Pokud PHP porovnává dva stringy (operátor ==), které vypadají jako číslo, tak je oba převede na číslo a potom je porovnává. Tedy PHP pro "10" == "1e1" vrací true. viz. https://php.net/manual/en/language.operators.comparison.php

[Sparrow]

Díky moc, to mne vůbec nenapadlo. Zadávám STRING myslím STRING, ach jo, taky mne mohlo trknout to E :(

[lertimir]

No když jsem si otázku četl, ani mě nenapadlo, že to čísla nejsou a spíše jsem přemýšlel, proč číslo v řádu 10^-908 se rovná číslu v řádu 10^-624 a myslím si, že jsou mimo přesnost a jsou oba float 0. Ale považuji za hloupost generovat stringy, které jsou čísla. Použitím i pismen je situace jednoznačná a stringy jsou navíc kratší se stejnou kolizní bezpečností.

[Jendа]

Ale považuji za hloupost generovat stringy, které jsou čísla.

Jenže to je API slevomatu mimo jeho kontrolu. (a nejsou to čísla, podívej se na ty ostatní - 9189208690C-823)

[Sparrow]

Přesně tak, já vůbec do poslední chvíle netušil jak budou kódy vypadat.

Dostal jsem akorát seznam ID (6 čísel) k propojení s výrobky.

Až dnes jsem dostal po 3 dnech odpověď (od někoho, kdo zná někoho, který má email na IT ze Slevomatu :D ) Jak se vlastně generuje kód kupónu.

xxxxxxxFF-xxx

X - náhodné číslo

FF - 256 kombinací pro produkt v HEX

Popis API ani nechtějte vědět a testací prostředí se skládá ze 3 kódů formát 1234567-111 až 333 (existují, neexistující, a již využitý)

Prostě radost něco napsat. :(

A jak jsem psal výše komunikace s IT probíhá přes obchoďáka a někoho kdo mám kontakt na někoho kdo něco ví.

[lertimir]

No a co kód v úplně prvním kroku concatenate s pevným stringem třeba "AA-".$SlevomatID, a pak v celém mém programu to bude vždy a pořád string, a až kód budu posílat Slevomatu tak prefix zase utrhnu.

[Jendа]

Geniální řešení.

(jak je řešena stabilita té umělé inteligence napříč architekturami a verzemi? třeba až implementují komplexní čísla a začnou převádět všechny stringy kde je číslo a "i" :)

[logik]

Je řešena? V PHP? ....

[Kit]

Však vidíš, že ta dvě čísla jsou stejná:

<?php
$a = "3767958990E-624";
$b = "6089139600E-908";
echo ($a == $b) ? "rovno" : "nerovno";