[PHP] Asterisk teken letterlijk gebruiken

[Verwijderd]

Het zit namelijk zo dat ik een variabele heb met een kwaliteitsaanduiding die er uit ziet als een aantal sterretjes (asterisktekens), bijvoorbeeld: **.

Nu wil ik deze met de volgende (sterk vereenvoudigde) code letterlijk uitlezen:

PHP:

$quality = '***';
echo $quality . '<br/>';
if ($quality== '\*\*\*')
    {
    echo '3 sterren kwaliteit is gekozen!';
    }
echo 'rest van code..';

De output is als volgt:

code:

***
rest van code..

Wat heb ik geprobeerd?
* if ($quality== '\*\*\*')
* if ($quality== '\***')
* if ($quality== '***')
* if ($quality== "\*\*\*")
* if ($quality== "\***")
* if ($quality== "***")
* $quality1 = '***'; if ($quality == $quality1)

Alles geeft het zelfde resultaat. Ik ben ten einde hoop. Wie kan mij helpen?

[Janoz]

De * is geen speciaal teken dus escapen is helemaal niet nodig. Je probleem zit dus ergens anders. Heb je die vereenvoudigde code zelf ook al eens gedraaid? (en dan bedoel ik de versie waarbij je het gewoon vergelijkt met '***').

[ Voor 18% gewijzigd door Janoz op 21-11-2007 10:42 ]

[BassieBulk]

PHP:

<?php 
$quality = '***'; 
echo $quality . '<br/>'; 
if (eregi("\*\*\*", $quality))
    { 
    echo '3 sterren kwaliteit is gekozen!'; 
    } 
echo 'rest van code..'; 
?>

[RobIII]

Een asterisk moet je alleen escapen als je met databases werkt, en dan nog lang niet altijd (in het geval van een LIKE bijvoorbeeld). Dus ik zie niet waarom je zou escapen?

[Gune]

Als je $quality wilt vergelijken, dan werkt onderstaande methode toch gewoon? Bij mij geeft het in ieder geval de volgende output:

code:

***
3 sterren kwaliteit is gekozen!rest van code..

PHP:

<?php
$quality = '***';
echo $quality . '<br/>';
if ($quality== '***')
    {
    echo '3 sterren kwaliteit is gekozen!';
    }
echo 'rest van code..';
?>

[Verwijderd]

In een reguliere expressie natuurlijk wel, maar ik zie niet echt in waarom je voor zoiets simpels een reguliere expressie gaat gebruiken. (of je voorbeeld code is te simpel waardoor we het echte probleem niet zien)

[Swaptor]

In BassieBulk's voorbeeld moet de astreisk wel ge-escaped worden in verband met de eregi.
Verder heeft RobIII natuurlijk gelijk

[Janoz]

Hiervoor een reguliere expressie gebruiken is oneindige onzin. Daarnaast klopt het ook voor geen meter om daar backslashes voor de * voor te zetten. Ik heb de code even lokaal gedraait, precies zoals de TS heeft (maar dan met het vergelijken tegen '***') en het werkt gewoon. Je fout zit dus duidelijk ergens anders (zitten er misschien spaties omheen?)

@Swaptor: Als je het geescaped naar de regexp engine wilt sturen zul je twee keer een backslash moeten gebruiken.

[ Voor 14% gewijzigd door Janoz op 21-11-2007 10:48 ]

[.oisyn]

Waarom gebruik je eigenlijk niet gewoon strlen()? Als je toch weet dat er altijd sterretjes in staan is het natuurlijk ook een beetje onzin om erop te gaan controleren

Naast onhandig is BassieBulk's code overigens ook gewoon onjuist. Hij matcht namelijk op alles waar *** in voorkomt. Dus ook "aap***noot***mies" of "*****".

[ Voor 31% gewijzigd door .oisyn op 21-11-2007 10:49 ]

[Verwijderd]

.oisyn schreef op woensdag 21 november 2007 @ 10:47:
Waarom gebruik je eigenlijk niet gewoon strlen()? Als je toch weet dat er altijd sterretjes in staan is het natuurlijk ook een beetje onzin om erop te gaan controleren

Anders eerst ff met een regex checken of er inderdaad alleen sterretjes in zitten

[.oisyn]

Verwijderd schreef op woensdag 21 november 2007 @ 10:48:
[...]

Anders eerst ff met een regex checken of er inderdaad alleen sterretjes in zitten

assert(strlen($str) == strspn($str, "*"));

[Verwijderd]

Ik snap ook niet waarom het niet werkt, maar ik had inderdaad ook al een oplossing gevonden met strlen($quality) en substr_count($quality, '*'), maar eigenlijk vind ik dat het gewoon direct moet werken. Ik ga nog even proberen...

EDIT:

Er zit inderdaad een (leeg) teken achter het laatste sterretje. Het is echter geen spatie, daarom had ik het niet eerder gezien. Eerst maar eens kijken waar die vandaan komt en wat het is.

Ik vond het ook al zo raar, ik heb hier nooit eerder problemen mee gehad.

[ Voor 37% gewijzigd door Verwijderd op 21-11-2007 11:01 ]

[flashin]

http://nl3.php.net/trim

[hamsteg]

waarom gebruik je geen strcmp()? Ik weet dat dit zou moeten werken maar het zou wel zuiverder zijn. Daarnaast met mid() en/of trim() even de juiste substring pakken en alles even schoonpoetsen.

[.oisyn]

hamsteg schreef op woensdag 21 november 2007 @ 11:47:
waarom gebruik je geen strcmp()? Ik weet dat dit zou moeten werken maar het zou wel zuiverder zijn.

Waarom? Wat denk je dat == intern doet dan?

[hamsteg]

.oisyn schreef op woensdag 21 november 2007 @ 11:50:
[...]
Waarom? Wat denk je dat == intern doet dan?

Zoals ik al zei: ik weet dat dit moet werken maar ... het werkt voor niet gevorderde programmeurs fouten in de hand als je er van uit gaat dat het intern wel wordt opgelost. Werk eens met pointers en dan weet jij niet meer wat die intern doet (aangezien het een vereenvoudigde post was kan dit dus wel degelijk van belang zijn).

[ Voor 9% gewijzigd door hamsteg op 21-11-2007 12:07 ]

[.oisyn]

Kom op zeg, dit is een PHP topic. In PHP kun je strings vergelijken met een ==, net zoals je dat in heel veel andere talen ook kan. De enige uitzonderingen die ik ken zijn Java, C, en C++ als je niet met std::strings werkt.

[hamsteg]

Jij hebt gelijk ... not.

De str... libraries zijn er niet voor niets en geven een gedefinieerd gedrag.

Wil je duidelijke en gedefinieerd programmeren maar dan gebruik van uitgebreid geteste libraries in plaats van mogelijkheden waarvan het gedrag niet gedefinieerd uitlegbaar is. De == operator kent zoveel mogelijkheden daar wil je je niet aan branden ... mag wel. Het volgende voorbeeld is goed:

PHP:

$sText = "hoi"
$iGetal = 0

if( $iGetal > $sText) ....

Ik weet het deze vier regels zien we allemaal meteen dat dit nooit kan en schreeuwen we natuurlijk moord en brand ... echter in scripts/functies waar de variabelen lekker door elkaar lopen wordt het al een heel ander verhaal.

Zie ook PHP.net in de forums of zelfs bij de commentaren van de strcmp() en andere functies hoe vaak programmeurs hierop nat zijn gegaan.

[ Voor 98% gewijzigd door hamsteg op 21-11-2007 12:24 ]

[flashin]

ik hou van korte antwoorden:
=== en !==

[ Voor 49% gewijzigd door flashin op 21-11-2007 12:25 ]

[.oisyn]

hamsteg schreef op woensdag 21 november 2007 @ 12:10:
Jij hebt gelijk ... not.

Goed lezen. Ik zei dat je strings kunt vergelijken. Jij vergelijkt geen strings, en dan heb je idd een punt.

Grappig trouwens dat je het hele "not" verhaal er later bijeditte

[ Voor 18% gewijzigd door .oisyn op 21-11-2007 12:54 ]

[hamsteg]

.oisyn schreef op woensdag 21 november 2007 @ 12:48:
Grappig trouwens dat je het hele "not" verhaal er later bijeditte

Moest even iets anders doen en heb blijkbaar op verzenden gedrukt ... foutjes zijn altijd snel gemaakt.

[Woy]

flashin schreef op woensdag 21 november 2007 @ 12:24:
ik hou van korte antwoorden:
=== en !==

Je houd van kort en foute antwoorden? Of reageer je niet op de TS. Het enige wat === volgens mij toevoegt is de controle op type.

[flashin]

Fout antwoord..

Ik reageerde niet op de TS nee, maar op de subdiscussie over het vergelijken van strings in php. Simpelste oplossing hierbij is de operator ===. Ik zou niet weten in wat voor voorbeeld strcmp meer voordelen heeft.

De vraag van de TS was verder m.i. al volledig beantwoord.


edit: op deze pagina nog duidelijker de verschillen tussen het gebruik van == en ===. Tabel R.3 laat dus zien dat ik === "een" (ik vind "de") juiste manier is.
http://nl2.php.net/manual/nl/types.comparisons.php

[ Voor 26% gewijzigd door flashin op 21-11-2007 14:33 ]

[hamsteg]

flashin schreef op woensdag 21 november 2007 @ 14:28:
Ik zou niet weten in wat voor voorbeeld strcmp meer voordelen heeft.

edit: op deze pagina nog duidelijker de verschillen tussen het gebruik van == en ===. Tabel R.3 laat dus zien dat ik === "een" (ik vind "de") juiste manier is.
http://nl2.php.net/manual/nl/types.comparisons.php

In feite geef je je eigen antwoord ... kijk eens naar de string nummers (colommen 6, 7 en 8 in vergelijking met string teksten (regels 11 en 12)... De strict type checks betekenen dat je wel heel zeker moet weten wat er in de string staat (schrijf jij daar controle functie omheen?), staat er een getal in dat wordt dit anders geïnterpreteerd. ik vind het wel heel eng worden als je aannames gaat doen voor een string zeker als dit "custom" input is. Geef mij de str... libraries dan maar.

Het mag allemaal, is niet fout maar verhoogt de kans op problemen en problemen kosten vaak enorm veel tijd (en geld) om uit te zoeken, helemaal als een ander de fouten er uit mag zoeken die jouw gedachten niet kent.

Omgekeerd, wat is er op tegen om strcmp() te gebruiken?

[ValHallASW]

hamsteg schreef op woensdag 21 november 2007 @ 16:32:De strict type checks betekenen dat je wel heel zeker moet weten wat er in de string staat (schrijf jij daar controle functie omheen?), staat er een getal in dat wordt dit anders geïnterpreteerd.

Hoezo? "0" wordt als string geinterpreteerd, niet als getal... en dat is wat je wilt hebben.

Het mag allemaal, is niet fout maar verhoogt de kans op problemen en problemen kosten vaak enorm veel tijd (en geld) om uit te zoeken, helemaal als een ander de fouten er uit mag zoeken die jouw gedachten niet kent.

Tsja, drop dan php in z'n geheel even . Het probleem is dat PHP dit soort implicit casts heeft waar ik op z'n zachtst gezegd... niet echt blij van word.

Omgekeerd, wat is er op tegen om strcmp() te gebruiken?

global functions zijn bah. Bovendien is

code:

 if (strcmp(a,b) === 0) {doe iets;}

toch een stuk minder leesbaar dan

code:

 if (a === b) {doe iets;}

...wat mij betreft.

Of ik mis je hele punt, maar dan mag je het wat duidelijker uitleggen

[ Voor 5% gewijzigd door ValHallASW op 21-11-2007 17:09 ]

[Voutloos]

Als je user input controleert en gewoon weet wat je wil testen, is deze hele PHP weak-typing discussie zwaar onnodig en offtopic...

[hamsteg]

ValHallASW schreef op woensdag 21 november 2007 @ 17:09:Hoezo? "0" wordt als string geinterpreteerd, niet als getal... en dat is wat je wilt hebben.

Neem even de moeite om naar de tabel te kijken ... er staat zelfs een expliciet commentaar onder voor "0'
Tabel R.3. Strict comparisons with ===

	TRUE	FALSE	1	0	-1	"1"	"0"	"-1"	NULL	array()	"php"	""
TRUE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE
FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE
1	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE
0	FALSE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE
-1	FALSE	FALSE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE
"1"	FALSE	FALSE	FALSE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE
"0"	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE
"-1"	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE
NULL	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE
array()	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	TRUE	FALSE	FALSE
"php"	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	TRUE	FALSE
""	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	TRUE

PHP 3.0 note: The string value "0" was considered non-empty in PHP 3, this behavior changed in PHP 4 where it's now seen as empty.

[.oisyn]

Dat commentaar slaat op empty(), niet op ===. Voor PHP4: empty("0") -> false.
Vanaf PHP4: empty("0") -> true. Als je "" === "0" oid doet zul je gewoon false krijgen.

[ Voor 25% gewijzigd door .oisyn op 21-11-2007 21:21 ]

[_js_]

BassieBulk schreef op woensdag 21 november 2007 @ 10:42:

PHP:

<?php 
$quality = '***'; 
echo $quality . '<br/>'; 
if (eregi("\*\*\*", $quality))
    { 
    echo '3 sterren kwaliteit is gekozen!'; 
    } 
echo 'rest van code..'; 
?>

Bij een reguliere expressie (RE) moet je dubbel escapen. Eerst voor PHP, en dan nog eens voor het onderdeel van PHP dat de RE behandelt.
\\*\\*\\*
wordt nadat PHP het ingelezen heeft
\*\*\*
en dat wordt door de RE-engine gezien als drie asterisken die letterlijk moeten worden gebruikt.

offtopic:
Wat een hoop gezeur, verkeerde antwoorden en onzin in dit topic zeg.

[.oisyn]

Het is idd wel zo netjes ja, maar in het geval van de asterisk hoeft dat dus niet, omdat een \* door PHP ook als zodanig wordt geinterpreteerd, aangezien \* geen geldig escape sequence is.