001 = 1 und password_hash

[PHP Lulu]

Hallo beisammen,

ich habe heute die Entdeckung gemacht, dass 01 das gleiche ist wie 1. Nicht lachen, es geht ja noch weiter ;)

01 = 1
001 = 1
0002 = 1

Prinzipiell stimmt das. Allerdings dachte ich nicht, dass die Nullen ignoriert werden. Ich beschreibe es mal kurz:

• Ich habe eine Nutzer ID die ich einfach der Schönheit halber 5 Stellig haben möchte. Also fülle ich mit str_pad von links mit Nullen auf.
• Ich erstelle einen Link darauß z.B.: /userprofil/00004 und fange die ID aus dem Link via mod_rewrite ^[1]{5}$ ab.
• $_GET['ID'] enthält jetzt die Userid. Ich gebe mit echo aus und tatsächlich gibt er 00004 aus.
• Ich zähle die länge mit count($_GET['ID']) und erhalte den wert 1. strlen ergibt das richtige Ergebnis von 5.

Bis hierhin ist es nicht schlimm. In der normalen Mathematik ist das ja richtig. Jetzt gehe ich aber dazu über, daten aus einer Datenbank zu holen und schreibe im sql query "ID = '. $_GET['ID'] .'". Da die ID in der Datenbank mit Auto Increment erstellt wird, gibt es keine vorhergehenden Nullen.

Jetzt ist meine Frage: Warum ist das so? Es ist in "Wirklichkeit" ja nicht exakt das gleiche - es sind ja zwei verschiedene zeichenkettenlängen von außen betrachtet. Ich hätte eher dem Operator LIKE zugetraut, dass er das so interpretieren würde, aber einer genauen gegenüberstellung mit = nicht. (MariaDB)

Für mich ist es für das Skript natürlich "unwichtig". Ich muss dann nicht die Nullen vorne weg streichen um wieder die richtige ID zu haben. Die weitergehende Frage wäre für mich aber, in wie fern etwas manipuliert werden könnte? z.Z. kann ich mir nichts vorstellen, aber eventuell kommt es an irgendeiner stelle zu fehlern im skript. Ich weiß nicht wie ich das einschätzen soll, zu wenig erfahrung.

Und eine weitere frage wäre, ob jemand ein deutsches tutorial für die funktion password_hash hat, da man das md5 und sha1 vorziehen soll. Ich verstehe die Parameter da nicht so ganz und was man alles für Optionen angeben kann.

mfg
Bernd

---

1. \d ↩︎

[Der Martin]

Hi,

01 = 1
001 = 1
0002 = 1

mit welcher Testmethode und in welchem Zusammenhang stellst du das fest? Ich kann das nämlich nicht nachvollziehen.

Prinzipiell stimmt das.

Nö. Es gilt immer noch 0002 == 2.

Allerdings dachte ich nicht, dass die Nullen ignoriert werden.

Warum nicht? Führende Nullen sind mathematisch-numerisch ohne Bedeutung. Sie haben allerdings in vielen Programmiersprachen eine besondere Bedeutung - nämlich die Aussage, dass es sich um eine im Oktalsystem notierte Zahl handelt. Unter der Prämisse gilt also: 006==6, 007=7, 010==8, 0100==64.

Und genau da liegt vermutlich dein Verständnisproblem.

Ciao,
 Martin

[Rouven]

Hello,

Und genau da liegt vermutlich dein Verständnisproblem.

da oder in der Nähe davon. Von deinem (zurecht gegebenen) Hinweis auf Oktal mal abgesehen, wäre in einheitlich numerischen Vergleichen schonmal 1, 01, 001 identisch. Was mir darüber hinaus aber auch als Anmerkung auf der Zunge liegt ist automatische Typumwandlung: diverse Operanden und Funktionen im SQL Umfeld führen automatische Typkonvertierungen durch. Würde ich einen Primary Key als CHAR oder VARCHAR definieren, dann wäre zwischen '1' und '01' in der Tat ein Unterschied. Wenn die ID-Spalte als Auto-Increment definiert ist, dann handelt es sich vmtl. um eine INTEGER Spalte oder etwas verwandtes. Damit wäre die Konsequenz, dass selbst ein Vergleich mit einem String intern in einen numerischen Vergleich münden:
WHERE numeric_column = '01'
ist äquivalent zu
WHERE numeric_column = 01
ist äquivalent zu
WHERE numeric_column = 1

MfG
Rouven

[Bernd]

Hi

Nö. Es gilt immer noch 0002 == 2.

Verschrieben :)

Warum nicht? Führende Nullen sind mathematisch-numerisch ohne Bedeutung.

Also bei PHP werden Sie nicht in Oktalzahlen umgewandelt?

Sie haben allerdings in vielen Programmiersprachen eine besondere Bedeutung - nämlich die Aussage, dass es sich um eine im Oktalsystem notierte Zahl handelt. Unter der Prämisse gilt also: 006==6, 007=7, 010==8, 0100==64.

Wenn PHP also doch das als Oktalzahl erkennt, kann ich nicht in der SQL Abfrage ein 'SELECT blub FROM woauchimmer WHERE ID = '. intval($_GET['ID']) .'' schreiben, da es einfach die Oktalzahl in ein Integer umwandelt.

015 = 13

Bernd

[Tom]

Hello,

Wenn PHP also doch das als Oktalzahl erkennt, kann ich nicht in der SQL Abfrage ein 'SELECT blub FROM woauchimmer WHERE ID = '. intval($_GET['ID']) .'' schreiben, da es einfach die Oktalzahl in ein Integer umwandelt.

Hier wir keine Oktalzahl aus $_GET['ID'] gemacht, da der Pre-Parser die Zahl im Parameter gar nicht mehr in die Finger bekommt. Sie ist nämlich schon in einem String verpackt.

Als Zahl wird sie erst wieder durch den Vergeleichsoperator behandelt, der aber in diesem Falle zur SQL-Textschnittstelle gehört, also die Regeln für die SQL-Textschnittstelle einhält.

Intval() wird allerdings in PHP ausgeführt. Dort wird der in $_GET['ID'] enthaltene ParemterSTRING typgewandelt, aber nicht mehr der Interpretation Literal->Oktalzahl unterworfen.

Die Benutzung von intval() beseitigt im Übrigen hier auch die SQL-Injection-Lücke. Man muss sich eben nur darüber im Klaren sein, ob die Spalte ID in der Datenbank wirklich vom Typ Integer ist.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

[...] siehe Martins Antwort.

[...] ich aber dazu über, daten aus einer Datenbank zu holen und schreibe im sql query "ID = '. $_GET['ID'] .'".

Da lies Dir bitte mal ganz schnell den Artikel im Wiki

http://wiki.selfhtml.org/wiki/Artikel:Kontextwechsel

durch. Du bereitest hier nämlich eine lupenreine MySQL-Injection vor.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Whouzuo]

Hallo beisammen,

ich habe heute die Entdeckung gemacht, dass 01 das gleiche ist wie 1. Nicht lachen, es geht ja noch weiter ;)

01 = 1
001 = 1
0002 = 1

Prinzipiell stimmt das. Allerdings dachte ich nicht, dass die Nullen ignoriert werden. Ich beschreibe es mal kurz:

• Ich habe eine Nutzer ID die ich einfach der Schönheit halber 5 Stellig haben möchte. Also fülle ich mit str_pad von links mit Nullen auf.
• Ich erstelle einen Link darauß z.B.: /userprofil/00004 und fange die ID aus dem Link via mod_rewrite ^[1]{5}$ ab.
• $_GET['ID'] enthält jetzt die Userid. Ich gebe mit echo aus und tatsächlich gibt er 00004 aus.
• Ich zähle die länge mit count($_GET['ID']) und erhalte den wert 1. strlen ergibt das richtige Ergebnis von 5.

Bis hierhin ist es nicht schlimm. In der normalen Mathematik ist das ja richtig. Jetzt gehe ich aber dazu über, daten aus einer Datenbank zu holen und schreibe im sql query "ID = '. $_GET['ID'] .'". Da die ID in der Datenbank mit Auto Increment erstellt wird, gibt es keine vorhergehenden Nullen.

Jetzt ist meine Frage: Warum ist das so? Es ist in "Wirklichkeit" ja nicht exakt das gleiche - es sind ja zwei verschiedene zeichenkettenlängen von außen betrachtet.

Weil PHP einfach nur... ach lies selbst: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Wenn du die Chance hast, verwende eine vernünftige Sprache, bei der nicht solche komischen Typkonvertierungen durchführt. Bei Zeichenketten würde man erwarten, dass der Ausdruck ("01" == "1") FALSE ergibt und nicht TRUE.

Für mich ist es für das Skript natürlich "unwichtig". Ich muss dann nicht die Nullen vorne weg streichen um wieder die richtige ID zu haben. Die weitergehende Frage wäre für mich aber, in wie fern etwas manipuliert werden könnte? z.Z. kann ich mir nichts vorstellen, aber eventuell kommt es an irgendeiner stelle zu fehlern im skript. Ich weiß nicht wie ich das einschätzen soll, zu wenig erfahrung.

Wie gesagt, lies den Abschnitt "Operators" in meinem Link.

---

1. \d ↩︎

[Der Martin]

Hallo,

Bei Zeichenketten würde man erwarten, dass der Ausdruck ("01" == "1") FALSE ergibt und nicht TRUE.

das ist auch in PHP so, solange beide Operanden Strings sind. Die "magische" und oft lästige oder gar gefährliche automatische Typumwandlung mit all ihren bösen Nebenwirkungen schlägt erst zu, wenn die Operanden verschiedene Typen haben.

Ciao,
 Martin

[mbr]

Hallo Der Martin

Bei Zeichenketten würde man erwarten, dass der Ausdruck ("01" == "1") FALSE ergibt und nicht TRUE.

das ist auch in PHP so, solange beide Operanden Strings sind. Die "magische" und oft lästige oder gar gefährliche automatische Typumwandlung mit all ihren bösen Nebenwirkungen schlägt erst zu, wenn die Operanden verschiedene Typen haben.

ich wollte dir erst zustimmen und mich bedanken, dass du das richtig gestellt hast, aber dann habe ich nochmal folgendes ausgeführt:

  
var_dump("01"=="1"); 	//true  
var_dump("01"==1); 	//true  
var_dump(01=="1");	//true  
var_dump("015"=="13");	//false  
var_dump(015=="13");	//true  
var_dump("015"==13);	//false  

WTF - habe ich etwas übersehen oder hat Whouzo tatsächlich recht? Auch die letzte Ausgabe verstehe ih nicht wirklich. Mir ist noch klar, dass eine führende Null bedeutet, dass es sich um eine Oktalzahl handelt. Außerdem weiss ich, dass 15(Oct) = 13(Dec) ist...

Achso: PHP 5.3.8 auf Win7 (XAMPP)

Viele Grüße

Michael

[Tom]

Hello,

ich wollte dir erst zustimmen und mich bedanken, dass du das richtig gestellt hast, aber dann habe ich nochmal folgendes ausgeführt:

var_dump("01"=="1");   //true
var_dump("01"==1);   //true
var_dump(01=="1");   //true     Hier ersetzt erst der Pre-Parser die 01 gegen die Oktalzahl
var_dump("015"=="13");  //false
var_dump(015=="13");   //true     Hier ersetzt erst der Pre-Parser die 015 durch die Oktalzahl
var_dump("015"==13);   //false

  
Wenn Du die Zahlen aber als Strings notiert, werden sie erst durch den Vergleichsoperator als Zahl interpretiert. Wenn Du den richtigen[tm] Vergleichsoperator '===' benutzt, dann findet keine Interpretation statt und die beiden Operanden werden unter Beibehaltung der notierten Typen verglichen.  
  
Eine Zahl ist beim Typvergleich dann selbstverständlich ungeleich einem String!  
  
Das was PHP hier macht, ist absolut logisch nachvollziehbar. Es richtet sich nach den für die Sprache festgelegten Regeln. Es ist daher nicht falsch, Vergleich im Zweifelsfall immer mit dem Identitätsoperator, also unter Beibehaltung der Typen der Operanden, durchzuführen.  
  
  
  
  
Liebe Grüße aus dem schönen Oberharz  
  
  
Tom vom Berg  
![](http://selfhtml.bitworks.de/Virencheck.gif)  
  

-- 
 ☻\_  
/▌  
/ \ Nur selber lernen macht schlau  
<http://bikers-lodge.com>

[Tom]

Hello,

Wenn du die Chance hast, verwende eine vernünftige Sprache, bei der nicht solche komischen Typkonvertierungen durchführt. Bei Zeichenketten würde man erwarten, dass der Ausdruck ("01" == "1") FALSE ergibt und nicht TRUE.

Wenn Du den typsicheren Vergleich nimmst, der dann hier angemessen wäre, stimmt das auch.

"01" === "1" -> false,

PHP ist als "Spezialsprache" für die Arbeit im Internet (hauptsächlich HTTP/s) entstanden. Da per HTTP alle Parameter als Zeichenketten ("Strings") übertragen werden, muss ständig interpretiert werden. Man muss auf Empfängerseite (Server) _wissen_, was man tut, und nicht einfach Rateprogramme schreiben :-P

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Whouzuo]

Hello,

Wenn du die Chance hast, verwende eine vernünftige Sprache, bei der nicht solche komischen Typkonvertierungen durchführt. Bei Zeichenketten würde man erwarten, dass der Ausdruck ("01" == "1") FALSE ergibt und nicht TRUE.

Wenn Du den typsicheren Vergleich nimmst, der dann hier angemessen wäre, stimmt das auch.

wieso? das sind beides strings, also warum sollte php hier eigentlich konvertieren? gibt es irgendeine andere sprache, die strings bei einem vergleich implizit zu ints konvertiert?

"01" === "1" -> false,

PHP ist als "Spezialsprache" für die Arbeit im Internet (hauptsächlich HTTP/s) entstanden. Da per HTTP alle Parameter als Zeichenketten ("Strings") übertragen werden, muss ständig interpretiert werden.

ja, aber vom Entwickler, nicht von der Sprache. sonst passiert nämlich genau das, was hier passiert ist: die Sprache tut etwas, das für den Entwickler nicht intuitiv ist. nach heutigen Maßstäben ist das nicht mehr akzeptabel, darum sollte man auf andere Sprachen setzen, wenn man kann.

Man muss auf Empfängerseite (Server) _wissen_

[Tom]

Hello,

Wenn Du den typsicheren Vergleich nimmst, der dann hier angemessen wäre, stimmt das auch.

wieso? das sind beides strings, also warum sollte php hier eigentlich konvertieren? gibt es irgendeine andere sprache, die strings bei einem vergleich implizit zu ints konvertiert?

Weil der Operator '==' die automatische Typanpassung anweist
Weil der Operator '===' die automatische Typanpassung unterbindet

"01" === "1" -> false,

Stimmt. "Äpfel" === "Birnen" -> false;

Da findet aufgrund des Operators '===' keinerlei Umwandlung mehr statt, nur noch der Vergleich!

Darum sage ich ja immer: PHP hätte in Turbo-Pascal geschrieben werden sollen. Dann gäbe es diese Besonderheiten nicht!

C ist einfach Sch....e

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Whouzuo]

Hello,

Wenn Du den typsicheren Vergleich nimmst, der dann hier angemessen wäre, stimmt das auch.

wieso? das sind beides strings, also warum sollte php hier eigentlich konvertieren? gibt es irgendeine andere sprache, die strings bei einem vergleich implizit zu ints konvertiert?

Weil der Operator '==' die automatische Typanpassung anweist

bei den in php eingebauten typen ja. aber wer zur Hölle ist auf die idee gekommen, zwei strings jeweils zu floats zu konvertieren, selbst wenn z.b. zeichen darin vorkommen? darum geht es doch.

[Der Martin]

Hallo,

Weil der Operator '==' die automatische Typanpassung anweist

aber wenn beide Operanden den gleichen Typ haben, ist eigentlich gar keine Anpassung nötig. Dass doch eine stattfindet, lässt nur einen Schluss zu: Der Vergleichsoperator == ist für Strings nicht definiert.

Das wiederum würde aber heißen, dass Strings beim typfreien Vergleich immer in Zahlen konvertiert werden müssten, ergo müsste auch "aa"=="bb" sein, weil beide Strings zu 0 konvertieren. Das ist aber auch nicht der Fall! Ich muss ehrlich zugeben, dass ich die Logik dahinter nicht begreife.

Es scheint so, als würde die Konvertierung zu int immer dann durchgeführt, wenn sie fehlerfrei möglich ist. Mit Logik, wie ich sie verstehe, hat das aber nicht mehr viel zu tun.

Als eingefleischter C-Programmierer ist mir diese Problematik (zum Glück) bisher nie aufgefallen, weil ich beim Stringvergleich "instinktiv" strcmp() verwende.

Darum sage ich ja immer: PHP hätte in Turbo-Pascal geschrieben werden sollen. Dann gäbe es diese Besonderheiten nicht!

In welcher Sprache Murks geschrieben wird, ist völlig egal - auch in einer sehr streng reglementierten Sprache wie Pascal kann man Programme schreiben, die Mist machen.

C ist einfach Sch....e

Ich finde C vom Grundsatz her prima - eine sehr flexible Sprache mit wenigen Beschränkungen. Im Gegensatz zu PHP weiß man als Programmierer aber von vornherein, dass man auf jedes Detail selbst achten muss, und in C gibt es keine "Magie" im Hintergrund.

Schönes Wochenende,
 Martin

[Bernd]

Hi,

Wenn du die Chance hast, verwende eine vernünftige Sprache, bei der nicht solche komischen Typkonvertierungen durchführt. Bei Zeichenketten würde man erwarten, dass der Ausdruck ("01" == "1") FALSE ergibt und nicht TRUE.

Meiner Meinung nach gibt es keine vernünftigen Sprachen. Jede Sprache hat seine Tücken und Stärken, Vor- und Nachteile. Am besten ist die Sprache, die man am liebsten spricht. Ich wollte auch keine neue Sprache mehr erlernen und auch wenn ich ab und zu damit Ringe das zu tun - aber das aus anderen Gründen. Nur mir gefällt das sehr gut, was ich derzeit nutze.

Natürlich hast du nicht unrecht. Ich denke die vorangehende 0 ist eine große Tücke bei PHP. Und von Zeichenketten kann man wirklich erwarten, dass "01" etwas anderes ist als "1". Eine Zeichenkette ist ein String und der beste Beweis, dass "01" nicht "1" sein kann ist die Funktion strlen, denn bei ersterm gibt sie 2 aus und nicht 1.
=== war doch eine Typprüfung? Aber wenn wir "01" und "1" manuell übergeben, wissen wir doch, dass es Strings sind. Dennoch:

var_dump("01"=="1");  //true
var_dump("01"==="1"); //false

PHP Doku:
$a == $b Gibt TRUE zurück, wenn $a gleich $b ist.
Trifft oben nicht zu. strlen beweißt es ja.

$a === $b Gibt TRUE zurück wenn $a gleich $b ist und beide vom gleichen Typ sind (eingeführt in PHP 4).
Müsste dann ebenfalls true ergeben.

MEINE VORANGEHENSWEISE:
Ich kann $_GET['ID']+=0; setzen um eine Umwandlung in einen integer zu bewirken. Wenn ich eine 000453 im $_GET['ID'] habe, dann ist es danach eine 453 in der Ausgabe. Die Nullen wurden gestrichen. Theoretisch geht auch intval, nur sehe ich ein problem darin, das es doch die oktalzahl nur in eine hexa umwandelt. Zumindest sehe ich das an den Beispielen in der PHP Doku.

ODER:
Ich benutze ltrim($_GET['ID'],'0') und habe dann 453 als string vorliegen, den ich dann mit intval sicher umwandeln kann. Durch das mod_rewrite sind für $_GET['ID'] nur Zahlen erlaubt. Oder kann das jemand noch von außen manipulieren? Eigentlich nicht oder?

Welche Variante würde man mir zuraten?

mfg,
Bernd

[Tom]

Hello,

$a === $b Gibt TRUE zurück wenn $a gleich $b ist und beide vom gleichen Typ sind (eingeführt in PHP 4).
Müsste dann ebenfalls true ergeben.

Nein, eben nicht, denn die linke Zeichenkette ist ja nicht identisch der rechten!
Und der Pre-Parser fasst die "Zahlen" nicht an, um ggf. eine Oktalzahl daraus dzu machen, da er sie ja bereits als Zeichenketten erkannt hat. Erst durch den Operator '==' wird der Mechanismus der Typumwandlung angestoßen. Die Funktion strlen() enthält aber keinen Operator. Darum führt die auch keine Typumwandlung durch!

Alle Klarheiten beseitigt?

Wenn PHP in (Turbo-)Pascal geschrieben wäre und nicht in C, dann wäre alles anders :-)

Dort gibt es keine Überladung und außerdem ist es ein typenstrenge Sprache. Man darf mit Mühe und Not mal gerade explizites Typecasting betreiben.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Bernd]

Hi,

Nein, eben nicht, denn die linke Zeichenkette ist ja nicht identisch der rechten!

Stimmt, sie ist nicht identisch. Aber laut der Beschreibung aus der PHP Doku die ich ja schrieb:

$a == $b ist gleich. Gilt für $a = '01' und $b = '1'. // true

Der Operator === sagt nach der Beschreibung von php.net:
$a == $b ist gleich // true, siehe oben
... und es muss der gleiche Typ sein:
gettype($a) == gettype($b) // string, true

Das macht sie doch dann "identisch". Ansonsten ist die deutsche Übersetzung schlecht, wenn er auch die Länge betrachten sollte. Denn das steht in der Beschreibung ja nicht drinnen. Und warum sollte er bei === die länge beachten und bei == nicht. Meines erachtens ein Fehler bei PHP.

Und der Pre-Parser fasst die "Zahlen" nicht an, um ggf. eine Oktalzahl daraus zu machen, da er sie ja bereits als Zeichenketten erkannt hat.

Ja.

Erst durch den Operator '==' wird der Mechanismus der Typumwandlung angestoßen. Die Funktion strlen() enthält aber keinen Operator. Darum führt die auch keine Typumwandlung durch!

Typumwandlung:
$z = '01';
$y = '1';
strlen($z) // 2
strlen($y) // 1

if($z == $y) // "Typ umgewandelt"

strlen($z) // 2
strlen($y) // 1

Es geht ja nicht um eine Typumwandlung mit strlen, sondern nachzuweisen, dass der string der schon vor dem == ein string war ($_GET kommt immer als string) ein string ist und nicht gleich dem anderen ist. Das er verschiedene längen hat, also nicht gleich ist. Es geht ja nichtmal um den Typ. Es geht darum, dass sie nicht gleich sind wegen verschiedener längen und deshalb $z nicht $y sein kann, weil sie nicht gleich sind.

Alle Klarheiten beseitigt?

Nein. ^^

Wenn PHP in (Turbo-)Pascal geschrieben wäre und nicht in C, dann wäre alles anders :-)
Dort gibt es keine Überladung und außerdem ist es ein typenstrenge Sprache. Man darf mit Mühe und Not mal gerade explizites Typecasting betreiben.

Deine Aufgabe :)) Ich unterstütze dich auch beim Turbo PHP.

mfg
Bernd

[Whouzuo]

Hi,

Wenn du die Chance hast, verwende eine vernünftige Sprache, bei der nicht solche komischen Typkonvertierungen durchführt. Bei Zeichenketten würde man erwarten, dass der Ausdruck ("01" == "1") FALSE ergibt und nicht TRUE.

Meiner Meinung nach gibt es keine vernünftigen Sprachen.

gut dann eben die sprache mit den kleinsten übeln.

Jede Sprache hat seine Tücken und Stärken, Vor- und Nachteile. Am besten ist die Sprache, die man am liebsten spricht. Ich wollte auch keine neue Sprache mehr erlernen

wenn du das hobbymäßig machst, ok. aber im professionellen Bereich musst du das, sonst kriegst du Probleme.

und auch wenn ich ab und zu damit Ringe das zu tun - aber das aus anderen Gründen. Nur mir gefällt das sehr gut, was ich derzeit nutze.

Natürlich hast du nicht unrecht. Ich denke die vorangehende 0 ist eine große Tücke bei PHP. Und von Zeichenketten kann man wirklich erwarten, dass "01" etwas anderes ist als "1". Eine Zeichenkette ist ein String und der beste Beweis, dass "01" nicht "1" sein kann ist die Funktion strlen, denn bei ersterm gibt sie 2 aus und nicht 1.
=== war doch eine Typprüfung? Aber wenn wir "01" und "1" manuell übergeben, wissen wir doch, dass es Strings sind.

ja, dennoch ist dieser operator bei strings in php zu verwenden.

[MudGuard]

Hi,

Jede Sprache hat seine Tücken

auch die deutsche - und in der ist "Sprache" weiblich, also muß es
"Jede Sprache hat ihre Tücken"
heißen.

SCNR ;-)

cu,
Andreas

[suit]

Weil PHP einfach nur... ach lies selbst: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Wenn du die Chance hast, verwende eine vernünftige Sprache, bei der nicht solche komischen Typkonvertierungen durchführt. Bei Zeichenketten würde man erwarten, dass der Ausdruck ("01" == "1") FALSE ergibt und nicht TRUE.

Ansichtssache - das ist eine der Designeigenheiten die es bei PHP zu beachten gibt - und in anderen Sprachen wieder nicht. Nur weil viele anderen Sprachen eine strengere Typbehandlung haben, ist PHP deshalb nicht schlecht oder macht es falsch.

PHP hat ganz andere Schwächen, die lockere Typbehandlung ist aber sicher keine Schwäche sondern ein Featue, welches man einfach beim Arbeiten beachten muss - wer das nicht tut ist selbst Schuld  ;)

[Whouzuo]

Weil PHP einfach nur... ach lies selbst: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Wenn du die Chance hast, verwende eine vernünftige Sprache, bei der nicht solche komischen Typkonvertierungen durchführt. Bei Zeichenketten würde man erwarten, dass der Ausdruck ("01" == "1") FALSE ergibt und nicht TRUE.

Ansichtssache - das ist eine der Designeigenheiten

Ich würde es Designfehler nennen. Aber das ist natürlich auch Ansichtssache. ;)

die es bei PHP zu beachten gibt - und in anderen Sprachen wieder nicht. Nur weil viele anderen Sprachen eine strengere Typbehandlung haben, ist PHP deshalb nicht schlecht oder macht es falsch.

Das hat nichts mit strengerer Typbehandlung zu tun. Javascript ist in dieser Hinsicht nicht besser und beinhaltet trotzdem nicht solche Designfehler wie PHP (dafür aber genug andere...).

[Tom]

Hello,

ich habe heute die Entdeckung gemacht, dass 01 das gleiche ist wie 1. Nicht lachen, es geht ja noch weiter ;)

01 = 1
001 = 1
0002 = 2

Hättest Du auch vorher nachlesen können:
http://www.php.net/manual/en/language.types.type-juggling.php
Dann wäre dir die "Entdeckung" erspart geblieben :-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg