[ PHP ] Code richtig in MYSQL Übergeben/finden
#1
geschrieben 16. Oktober 2013 - 18:35
Ich möchte per PHP eine Übersicht erstellen, bei welcher verschiedenen Objekten jeweils ein Barcode gegeben wurde und man die Ojkete per Barcode Scanner so wieder mit den jeweiligen Eingenschaften aufrufen kann.
Sprich z.B.
Objekt -- Barcode -- Eigenschaft
Apfel -- ö12334_ -- rot
Wenn ich also nun das Objekt per Barcode Scanner einlese soll es in der Übersicht erscheinen.
Das erstellen klappt wunderbar und der Barcode wird auch korrekt eingelesen und in der MYSQL Datenbank richtig übergeben ( dabei ist dieser leider immer mit "ö" am Anfang und einem "_" am Ende ).
Nun klappt aber leider das Abrufen in der Übersicht nicht wirklich.
Wenn ich in das Barcode Feld nun den Code einlese bzw. diesen per Hand eingebe wird er allerdings nicht in der Übersicht anzeigen. Falls ich aber händisch den Barcode per phpmyadmin abändere und diesen neuen Code ohne "ö" und "_" eingebe, kann ich diesen händisch finden. Aber natürlich nicht per Barcode Scanner, da der Code ja leider das ö und den _ enthält.
Was könnte ich nun machen, dass entweder die ö`s und _`s jedes Mal herausgefiltert werden oder dass trotz der ö`s und Unterstrichen die Objekte in der Datenbank richtig gefunden werden?
Wäre schön, wenn jemand ne Idee hätte
Danke schon mal.
Anzeige
#2
geschrieben 16. Oktober 2013 - 19:25
$wort = substr(utf8_decode($wort),1,count($wort)-2);
kannst du das erste und das letzte Zeichen abschneiden.
Das utf8_decode hab ich nur gemacht, weil es wegen des "ö" sonst Probleme geben könnte und wenn die Codes immer gleich lang sind, kannst du "count($wort)-2" auch durch die entsprechende Zahl ersetzen.
Dieser Beitrag wurde von Holger_N bearbeitet: 16. Oktober 2013 - 19:27
#3
geschrieben 16. Oktober 2013 - 19:30
Zitat (Balder: 16. Oktober 2013 - 18:35)
Wäre schön, wenn jemand ne Idee hätte
Danke schon mal.
bin zwar etwas eingerostet was das angeht... aber:
Problematisch ist eben hier (meiner Auffassung nach), dass diese benannten Sonderzeichen schon in der Datenbank stehen.
Optimum ist meiner Ansicht nach folgendes:
Diese Sonderzeichen aus der Datenbank entfernen
Die Sonderzeichen lediglich (wenn überhaupt erforderlich ) in der Anzeiche durch PHP-Verkettungsoperatoren einfach kosmetisch vor und hinter den Datenbank-Werten zu schreiben.
Wieso werden denn diese Sonderzeichen überhaupt benötigt?
#4
geschrieben 16. Oktober 2013 - 19:38
#5
geschrieben 16. Oktober 2013 - 19:49
Zitat (Holger_N: 16. Oktober 2013 - 19:38)
"abschneiden" brauchst du doch nix. Diese Zeichentypen werden nicht eingescannt/ignoriert - kann im Fehlerfall sogar den Barcode unlesbar machen.
Würde das ehr so machen - kein Anrecht auf Syntaxkorrektheit und Funktion
echo "ö".$BARCODE_AUS_DATENBANK."_";
und den Barcode - wie er zu sein hat - in der Datenbank nur als Ziffernfolge speichern.
Im übrigen: Es macht Sinn, für den Barcode in der Datenbank einen CHAR-Datentyp zu wählen da bspw. EAN mit Nullen aufgefüllt werden muss um korrekt zu funktionieren (bspw. bei zu kurzen Werten die weder EAN7 noch EAN13 entsprechen. Bei numerischen Datentypen werden ja bspw. vorangestellte Nullen ignoriert.
PS:
Wenn der Barcode bereits unsauber in der Datenbank steht, so kann man auch eine zusammengesetzte Variabel an die Datenbank geben. Dies funktioniert bspw. so:
$BARCODE_FUER_DATENBANK = "ö_".$BARCODE_EINGESCANNT."_";
Auszulesen bspw dann mit
$BARCODE_AUSGABE= "ö_".$BARCODE_EINGESCANNT."_"; echo $BARCODE_AUSGABE;
Dieser Beitrag wurde von Stefan_der_held bearbeitet: 16. Oktober 2013 - 19:56
#6
geschrieben 16. Oktober 2013 - 19:56
#7
geschrieben 16. Oktober 2013 - 20:16
Nun habe ich vollkommen die Übersicht verloren die ich erst gedacht hatte gefunden zu haben
#8
geschrieben 16. Oktober 2013 - 20:32
Ich brauche "ö" und "_" nicht, allerdings scheinen diese irgendwie bei dem Barcode schon dabei zu sein.
Die Datenbank kann man notfalls nochmal "cleanen" da ich z.Z. eh nur einige Testvariablen drin habe, daher ist es nicht zu schlimm wenn ich diese nochmal löschen müsste.
Falls noch wer ne Idee hat , könnt ihr diese gerne nochmal schreiben, ich versuche es so lange erst einmal mit dem kürzen des Barcodes
#9
geschrieben 16. Oktober 2013 - 20:39
Zitat (Balder: 16. Oktober 2013 - 20:32)
Die Datenbank kann man notfalls nochmal "cleanen" da ich z.Z. eh nur einige Testvariablen drin habe, daher ist es nicht zu schlimm wenn ich diese nochmal löschen müsste.
Ja Moment mal....
Werden diese denn auch mit-eingescant? oder stehen die nur davor und dahinter? Haben diese denn irgendeinen zuweisenden Zweck?
Nach welchem Standard ist denn der Barcode überhaupt?
Wenn ich bspw. bei Lenovo_Notebooks den Barcode einscanne wird quasi aus
PN1234-CTO SN L3-1234567
beim Scan ein
1234CTOL31234567
sprich entweder muss da eine Maskierung vor dem Speichern erfolgen oder eben beim Auslesen damit das ein "Normalsterblicher" noch lesen kann.
#10
geschrieben 16. Oktober 2013 - 21:44
Wenn die von externer Stelle reingeschrieben werden, würd ich da auch nix ändern. Ist zwar komisch, so mit Sonderzeichen... aber diese dienen augenscheinlich als Start-und Endzeichen, also müssen sie halt auch sichtbar bleiben (für die Abfrage).
Also
a) - wie Stefan meint - die Einfüge-Operation so anpassen, daß die Daten ohne irgendwelche Verzierungen in der Datenbank landen. Das Beste wäre hier, wenn man selbe Daten so klar wie möglich da reinschreibt - nun kenn ich mich mit Barcodes nicht so aus, aber zumindest vom Ansatz her würd ich da zumindest drei Spalten in die Datenbank tun, nämlich einmal den Barcode-Typen, einmal den Wert selber, und einmal das Prüfbit, welches im Barcode enthalten ist. Dann kann man das nämlich noch verifizieren, ob der Barcode hinhaut oder nicht. Dann, wenn der Code selber gebraucht wird, das ö und den Unterstrich vorne und hinten anhängen, damit diejenigen Anwendungen, die drauf zugreifen sollen und das ö vorne und den Unterstrich hinten halt erwarten, diese auch so zu Gesicht kriegen.
Für eigene Abfragen braucht man das ja dann nicht und kann es entsprechend weglassen.
Wenn aber natürlich die Daten extern eingefügt werden, hieße das Option
b) die Daten in der Datenbank so lassen und dann, wenn Du selber eine Abfrage startest, den Wert aus dem $_REQUEST[] nehmen, vorne und hinten ö und _ dranbammeln und damit suchen gehen.
NB: Indices auf der Datenbank nicht vergessen. Sonst dauert die Suche irgendwann ewig, wenn mehr als nur ein paar Tausend Einträge in der DB stehen.
NB2: Weiß ja nicht, wie nah Du an der Datenbank arbeitest und/oder wie gut Du Dich damit auskennst, daher: Unterstriche haben in SQL eine besondere Bewandtnis, daher LIKEs entweder vermeiden oder die Unterstriche ESCAPE()n. Sonst fällt Dir das irgendwann irgendwo auf die Füße, weil alles nicht so funktioniert, wie man's erwarten sollte.
Dieser Beitrag wurde von RalphS bearbeitet: 16. Oktober 2013 - 21:50
#11
geschrieben 16. Oktober 2013 - 22:04
#12
geschrieben 22. Oktober 2013 - 09:33
Davon ausgehend, dass in der Regel EAN8/EAN13 und UPC-A / UPC-E Barcodes vorkommen, sollte alles zwischen ö und _ ja eineindeutig sein.
Eine "Enthält-Suche" kann zum Beispiel so aussehen:
$queryText="SELECT * FROM `tabellenname` WHERE `Barcode` LIKE '%".$_GET[Sucheingabe]."%';";
Dann sollte man schaun, wie die Barcodes per Definition beschaffen sein dürfen.
Alles was da per Definition nicht hingehört, kann unter Umständen rausgefiltert werden. Jenachdem, warum das angehängt und in die Datenbank einfefügt wird, also ob es beispielsweise andere Module gibt, die diese Notation verlangen, kann das im Negativfall vielleicht mit nem Script komplett aus der Datenbank genommen werden.
Was den Grund für das Anhängen jener Zeichen betrifft:
Einige Scanner haben zum Beispiel die Möglichkeit, vor und/oder nach jedem Scan bestimmte Zeichen anzuhängen, die man je nach Gerät selbst festlegen kann. Dies können einfache Zeichen oder auch Tab, Enter, sonstwas sein.
Ich selbst benutze beispielsweise diese Funktion, um nach einem Scan den Tab zu veranlassen, um ins nächste Eingabefeld zu springen. Gibt es diese Funktionen vielleicht vom "Vorbenutzer" noch? Dann könnte man das mit einem Factory-Reset rausnehmen.
Wie gesagt, das Wichtigste ist immer, dass man vorher sicher ist, nicht an anderer Stelle Probleme zu verursachen...
Dieser Beitrag wurde von Mondragor bearbeitet: 22. Oktober 2013 - 09:38
#13
geschrieben 22. Oktober 2013 - 14:55
Besser, einfach die SQL-Abfrage seitens PHP anpassen. Also sowas wie
$query = printf( "SELECT * FROM barcodes WHERE barcode = 'ö%s_';", $barcode);
oder welche *printf bei PHP die Zeichenfolge selber zurückgibt. Ansonsten halt mit normaler Verkettung, also
$query = "SELECT * FROM barcodes WHERE barcode = 'ö" . $barcode . "_';";
NB: Immer so wenig Streß wie möglich auf die Datenbank abwälzen, und mit Indices unterstützen, wenn nötig (EXPLAIN anstrengen).
Übrigens, weil man sich nie sicher sein kann, wo die Daten für die Suchabfrage selber herkommt und man sich auch sonst an kritische Vorgehensweisen einfach gewöhnt:
Immer, wirklich IMMER, die Eingaben vor der Verwendung prüfen. Einzelne Apostrophe dürfen in $barcode nicht enthalten sein - das muß man sicherstellen. Wenn man LIKEs verwendet, werden % und _ erst richtig problematisch, wenn man das nicht abfängt. Und wenn $barcode ein SQL-Codebruckstück enthält, sodaß die gesamte Abfrage wieder gültiges SQL ist, aber mit der Originalabfrage nix zu tun hat, kann das auch gefährlich werden (hier ist man mit dem fest codierten '=ö' im Quellcode schon mal etwas sicherer, aber nicht viel). Was zum Beispiel, wenn $barcode den Wert
%'; DELETE *; SELECT 'enthält?
Schritt 1: Parameter aus $_REQUEST durch nen cast schieben - egal wie - sodaß am Ende kein Objekt sonstwelcher Art, sondern zumindest eine Zeichenfolge rauskommt (und das garantiert).
Schritt 2: Regex über den Input, der möglichst nur gültige Eingaben akzeptiert. Also wirklich nur Barcodes und keine Mailadressen oder Codefragmente wie im Beispiel.
Schritt 3: Falls es nicht in (2) schon rausgeflogen ist, SQL-Symbole wie ', %, _ rausESCAPE()n.
Schritt 4: Ergebnis in die Abfrage stecken.
Dieser Beitrag wurde von RalphS bearbeitet: 22. Oktober 2013 - 15:07
#14
geschrieben 22. Oktober 2013 - 15:17
Ich war aber nicht davon ausgegangen, dass dieser Zustand ein Dauerzustand ist, insofern maximal als Übergangslösung.
Natürlich sollten auch die Daten geprüft werden, bevor man sie auf die Datenbank loslässt.
Dieser Beitrag wurde von Mondragor bearbeitet: 22. Oktober 2013 - 15:21