nicht angemeldet
str_replace "vergisst" Ersetzungen
Der MartinHallo,
ich habe folgende Funktion:
public function checkStrichcode($strichcode) {
$strichcode = trim($strichcode);
$strichcode = str_replace(' ', '', $strichcode);
if (is_numeric($strichcode) && (strlen($strichcode) <= 20) )
return $strichcode;
return false;
}
Übergebe ich dieser Funktion so etwas...
900570 030 1432
kommt dabei nicht dieses Ergebnis heraus...
9005700301432
sondern das hier:
900570 030 1432
Kann sich das jemand erklären? Übrigens funktioniert es mit preg_replace ebensowenig.
Danke im Voraus für eure Antworten,
Markus
-
Hallo,
vielleicht sinds keine blanks dazwischen?
denn:
<?php $testString = "900570 030 1432"; $result = str_replace(' ', '', $testString); echo $result;bringt:
9005700301432
Gruß
jobo
-
Hallo,
<?php
$testString = "900570 030 1432";
$result = str_replace(' ', '', $testString);
echo $result;> > bringt: > > 9005700301432 Ok, das funktioniert so bei mir auch. Markus-
Hallo,
Ok, das funktioniert so bei mir auch.
Du musst verifizieren, dass das wirklich Leerzeichen sind. Mit deiner Regex wäre ich mir da nicht so sicher. Es gibt ja auch von dedlfix einen Vorschlag.
Gruß
jobo
-
Hallo,
es sind offensichtlich Leerzeichen und keine Tabulatoren, wenn man den Hex-Werten Glauben schenken darf. Darüberhinaus finde ich auch folgendes erstaunlich:
Wenn ich danach nochmals ein str_replace drüberlaufen lasse, passiert ebenso nichts. Es bleibt immer ein Leerzeichen vorhanden:
$strichcode = preg_replace('/[\s\t]/', '', $strichcode); $strichcode = str_replace(' ', '', $strichcode);Das muss eventuell irgendwie mit der ersten HTTP-Übertragung zusammenhängen, denn in die Datenbank wird letztendlich fälschlicherweise auch ein Leerzeichen gespeichert (eigentlich wird die Zahl abgeschnitten, was ja dabei das problematische ist, da dann nur der erste Teil vor dme Leerzeichen gespeichert wird).
Markus
-
Hallo,
es sind offensichtlich Leerzeichen und keine Tabulatoren, wenn man den Hex-Werten Glauben schenken darf.
Naja, du musst isolieren, jedes Teil der Ablaufskette.
Gruß
jobo
-
Hi,
interessant ist auch, dass es bei einem Testscript funktioniert, wie es soll. Bin mal gespannt, woran das wirklich liegt.
So funktioniert es auch:
<?php if (isset($_REQUEST['save'])) { $text = $_REQUEST['testtext']; $text = trim($text); $text = preg_replace('/[\s\t]/', '', $text); $text = str_replace(' ', '', $text); if (is_numeric($text) && (strlen($text) <= 20) ) echo $text . "\n"; else echo "Fehler\n"; } else { echo <<<EOT <html> <head><title>test</title></head> <body> <form method="post" action=""> <input type="text" name="testtext" value=""> <input type="submit" name="save" value="submit"> </form> </body> </html> EOT; } ?>
-
-
-
-
-
-
Grüße,
angenommen das sind keine spaces -
dann könntest du vllt mal durchloopen und jedes zeichen einzeln überprüfen - zahlen ausgeben, sonstiges ignorieren (nicht performant)? kannst nebenbei auch sehen ob alle zeichen zahl oder space sind.
MFG
bleicher -
Hi,
900570 030 1432
kommt dabei nicht dieses Ergebnis heraus...
9005700301432
sondern das hier:
900570 030 1432wie verifizierst du das? Anhand der HTML-Ausgabe?
Dann hau ich mal in dieselbe Kerbe wie die beiden Kollegen vor mir und sage: Tabulatorzeichen!Ciao,
Martin--
Zwei Kumpels sitzen vor dem Computer. "Welche Suchmaschine beutzt du eigentlich meistens?" - "Prima Vera." - "Hmm, kenn' ich gar nicht." Dann geht die Tür auf: "Schatz ich habe deine Sonnenbrille wiedergefunden!" - "Prima, Vera!"
-
Hi!
wie verifizierst du das? Anhand der HTML-Ausgabe?
Dann hau ich mal in dieselbe Kerbe wie die beiden Kollegen vor mir und sage: Tabulatorzeichen!Nicht raten, prüfen!
echo bin2hex($text);
Oder hübscher formatiert:
echo chunk_split(bin2hex($text), 2, ' ');
echo '<br>';
echo chunk_split($text, 1, ' ');Lo!
-
Hallo,
hierbei bekomme ich folgende Ausgabe mit dieser Eingabe:
9009700 301432 434Ausgabe:
9009700 301432 434
39 30 30 39 37 30 30 20 20 20 20 33 30 31 34 33 32 20 20 20 20 20 20 20 20 20 20 20 20 34 33 34 20
9 0 0 9 7 0 0 3 0 1 4 3 2 4 3 4Es scheint sich also um Leerzeichen zu handeln, was auch dadurch bestätigt wird, da der geänderte Ausdruck:
$strichcode = preg_replace('/[\s\t]/', '', $strichcode);ebensowenig zu dem gewünschten Ergebnis führt.
Markus.
-
Hi!
Es scheint sich also um Leerzeichen zu handeln, [...]
Diesmal scheint es nicht nur so, es ist damit bestätigt.
Allerdings kann ich das Problem mit PHP 5.2.8 nicht nachvollziehen. Sowohl str_replace() als auch preg_replace() liefern keine Leerzeichen mehr zurück. Als dritten Kandidaten kannst du ja mal strtr() probieren. Das am besten in der zweiten Varianten mit dem Array.
Lo!
-
Hallo,
mittlerweile kann ich schon mal behaupten, dass es sich nicht um fehlerhafte PHP-Funktionen handelt, denn wenn ich die selbe Überprüfungsklasse in einer anderen Datei einbinde, funktioniert es komischerweise wie es soll:
<?php include_once("CheckArtikel.php"); if (isset($_REQUEST['save'])) { $text = $_REQUEST['testtext']; $warengruppe = 8; $checker = new CheckArtikel(); $text = $checker->checkStrichcode($text,$warengruppe); echo $text; } else { echo <<<EOT <html> <head><title>test</title></head> <body> <form method="post" action=""> <input type="text" name="testtext" value=""> <input type="submit" name="save" value="submit"> </form> </body> </html> EOT; } ?> {/code] So sieht die Orginalmethode aus: [code lang=php] public function checkStrichcode($strichcode, $warengruppe) { if ($warengruppe == 9) return true; $strichcode = trim($strichcode); $strichcode = preg_replace('/[\s\t]/', '', $strichcode); $strichcode = str_replace(' ', '', $strichcode); if (is_numeric($strichcode) && (strlen($strichcode) <= 20) ) return $strichcode; return false; }Es ist mir noch immer absolut schleierhaft, wie es zu diesem Verhalten kommt.
Markus
-
-
-
-
-
Hello,
ich habe folgende Funktion:
public function checkStrichcode($strichcode) {
$strichcode = trim($strichcode);
$strichcode = str_replace(' ', '', $strichcode);
if (is_numeric($strichcode) && (strlen($strichcode) <= 20) )
return $strichcode;return false;
}> > Übergebe ich dieser Funktion so etwas... > 900570 030 1432 > kommt dabei nicht dieses Ergebnis heraus... > 9005700301432 > > sondern das hier: > 900570 030 1432 > > Kann sich das jemand erklären? Übrigens funktioniert es mit preg\_replace ebensowenig. Ich komme da mal von einer anderen Seite, als meine Kollegen: Welche PHP-Version aus welcher Distribution auf welchem OS? Ich erinnere mich nämlich daran, dass ich dasselbe Phänomen mit einer frühen Fünfer-Version auf einem Debian-3.5 auch schon mal hatte. Liebe Grüße aus dem schönen Oberharz Tom vom Berg  -- Nur selber lernen macht schlau <http://bergpost.annerschbarrich.de>-
Hallo,
folgende Versionen benutze ich:
php 5.3.0-5 [installed]
php-apache 5.3.0-5 [installed]
php-cgi 5.3.0-5 [installed]
php-gd 5.3.0-5 [installed]
php-mcrypt 5.3.0-5 [installed]auf Arch Linux.
Markus.
-
-
Hallo,
tja, die eigene Schlampigkeit war der Fehler.
Ich verwende ja eigentlich eine andere Variable für den Ergebnisstring:$returnStrichcode = $checker->checkStrichcode($strichcode, $warengruppe)Durche meine Schlampigkeit habe ich aber stets mit dem ursprünglichen String hantiert. ($strichcode = $_REQUEST['strichcode'];)
Den Fehler habe ich dann gleich doppelt gemacht, da ich erstens $strichcode anstatt $returnStrichcode an die DB übergab und zweitens dem Fehler ebenso mit $strichcode versucht habe auf den Grund zu gehen.Markus
-
Durche meine Schlampigkeit habe ich aber stets mit dem ursprünglichen String hantiert. ($strichcode = $_REQUEST['strichcode'];)
Sowas passiert nicht, wenn man direkt mit den superglobalen Arrays arbeitet und nicht (meistens) unsinnigerweise Variablen herumkopiert.
-
Sowas passiert nicht, wenn man direkt mit den superglobalen Arrays arbeitet und nicht (meistens) unsinnigerweise Variablen herumkopiert.
..wodurch man sich aber wieder andere für globale Variablen typische Probleme aufhalsen kann.
Objektorientiertes Design hat schon seinen Sinn und ich versuche mich stets daran zu halten.Markus.
-
..wodurch man sich aber wieder andere für globale Variablen typische Probleme aufhalsen kann.
Objektorientiertes Design hat schon seinen Sinn und ich versuche mich stets daran zu halten.Dann mach es vernünftig und erstelle ein Duplikat eines entsprechenden superglobalen Arrays und arbeite damit in der Instanz deiner Klasse. Aber einzelne Werte aus dem superglobalen Array rauszufischen und in eigene Variablen zu packen ist etwas uncool - da verliert man schnell den Überblick.
var $request_vars = $_REQUEST; $this->foo($this->request_vars['bar']); function foo($param) { // do something return $param; }
-
-
-
Hallo,
tja, die eigene Schlampigkeit war der Fehler.
Ich verwende ja eigentlich eine andere Variable für den Ergebnisstring:$returnStrichcode = $checker->checkStrichcode($strichcode, $warengruppe)Durche meine Schlampigkeit habe ich aber stets mit dem ursprünglichen String hantiert. ($strichcode = $_REQUEST['strichcode'];)
Den Fehler habe ich dann gleich doppelt gemacht, da ich erstens $strichcode anstatt $returnStrichcode an die DB übergab und zweitens dem Fehler ebenso mit $strichcode versucht habe auf den Grund zu gehen.Mich würde jetzt noch interessieren, was denn an der ursprünglichen Variable "falsch" war. Tabs?
Markus
Gruß
jobo
-
Hallo,
Mich würde jetzt noch interessieren, was denn an der ursprünglichen Variable "falsch" war. Tabs?
Im Prinzip ja gar nichts. Ich denke durch die HTTP-Übertragung werden einfach nicht alle außer ein Leerzeichen übernommen (warum ist das eigentlich so?). Den Sachverhalt kennt man ja auch aus schlampigen Foren oder Gästebüchern, wo dann die schöne Formatierung vernichtet wird.
Um es zu verdeutlichen. Ich hantierte die ganze Zeit mit der Variable, die die Daten über HTTP bekam. So gesehen hatte die Variable auch den richtigen Inhalt.Markus
-
Hallo,
Im Prinzip ja gar nichts. Ich denke durch die HTTP-Übertragung werden einfach nicht alle außer ein Leerzeichen übernommen (warum ist das eigentlich so?). Den Sachverhalt kennt man ja auch aus schlampigen Foren oder Gästebüchern, wo dann die schöne Formatierung vernichtet wird.
Um es zu verdeutlichen. Ich hantierte die ganze Zeit mit der Variable, die die Daten über HTTP bekam. So gesehen hatte die Variable auch den richtigen Inhalt.Aber der str_replace-Funktion ist es doch egal, aus welcher Quelle der String stammt oder mit welchem Protokoll er transportiert wurde. Entscheidend ist doch nur, ob ASCII 32 da ist, oder nicht, und ersetzt es dann, oder nicht. Das heißt doch zwangsläufig, dass die Whitespaces aus Nicht-Ascii-32-Zeichen bestanden haben müssen. Sonst wären sie ja ersetzt worden.
Gruß
jobo
-
Hallo,
Aber der str_replace-Funktion ist es doch egal, aus welcher Quelle der String stammt oder mit welchem Protokoll er transportiert wurde. Entscheidend ist doch nur, ob ASCII 32 da ist, oder nicht, und ersetzt es dann, oder nicht. Das heißt doch zwangsläufig, dass die Whitespaces aus Nicht-Ascii-32-Zeichen bestanden haben müssen. Sonst wären sie ja ersetzt worden.
Ich weiß nicht, ob wir da jetzt aneinander vorbeireden. Wenn ich einen Text mit POST übertrage, kommt der Text auch genauso an, d.h. mit zumindest einem Leerzeichen (befinden sich mehrere Leerzeichen hintereinander, gehen diese verloren). Diesen Text habe ich in einer Variable gespeichert und diese Variable die ganze Zeit verwendet, anstatt die Rückgabevariable zu verwenden. Da ich das nicht bemerkte, dachte ich, dass die Funktion damit nichts tut, obwohl sie richtig funktionierte. Nur habe ich den korrekten Rückgabewert nie verwendet.
Markus
-
Hallo,
verstehe, du dachtest, du testest die funktion, hast sie aber garnicht benutzt...;
echo deineFunktion();
wäre wohl sinnvoll gewesen zum testen.
Gruß
jobo
-
-
-
-
-
