[Balder]

Hallo.
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.

[Holger_N]

Geht bestimmt auch eleganter aber damit

$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

[Stefan_der_held]

Zitat (Balder: 16. Oktober 2013 - 18:35)

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.

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?

[Holger_N]

Also so wie er das beschreibt sollte man die Zeichen vorne und hinten gleich nach dem Scannen abschneiden und dann erst in die Datenbank schreiben. Ergänzend zu meiner zu meinem Vorschlag da oben könnte man das auch als Funktion schreiben.

[Stefan_der_held]

Zitat (Holger_N: 16. Oktober 2013 - 19:38)

Also so wie er das beschreibt sollte man die Zeichen vorne und hinten gleich nach dem Scannen abschneiden und dann erst in die Datenbank schreiben. Ergänzend zu meiner zu meinem Vorschlag da oben könnte man das auch als Funktion schreiben.

"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

[Holger_N]

Aber er schreibt doch (Mal angenommen der Barcode entspräche 12345) dass es funktioniert, wenn er 12345 per Hand eingibt aber wenn er den 12345 entsprechenden Barcode einscannt, hängt der Scanner ö und _ dran und dann funktioniert es nicht. Also würde ich ö und _ abschneiden, 12345 in die Datenbank schreiben, dort wird dann auch alles gefunden, wenn alles so gespeichert wird und wenn ein Wert irgendwo ausgegeben wird und man das ö und _ für eine Weiterverarbeitung braucht, dann kann man das ja wieder dranschreiben. Das sind doch sicherlich nur die Anfangs und Endzeichen damit der Scanner weiß, wie rum der Code gerade ist. Die braucht man ja nicht, wenn der Code numerisch in der Datenbank gespeichert wird.

[Stefan_der_held]

ernsthaft Holger?

Nun habe ich vollkommen die Übersicht verloren die ich erst gedacht hatte gefunden zu haben

[Balder]

Huhu danke für die Hilfe, ich werde es nun erst einmal mit der Ignorierung der einzelnen Buchstaben versuchen ( sprich ö und _ ) und dann auch die Auslesung hoffentlich so hinbekommen.

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

[Stefan_der_held]

Zitat (Balder: 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.

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.

[RalphS]

Die Frage muß doch lauten: WIE kommen denn die Codes IN die Datenbank? Macht das ein (externes) Programm, oder werden die letztlich per selbstgebautem Interface da reingeschoben?

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

[Holger_N]

Son Barcode hat doch ein Startzeichen und ein Endzeichen. Das ist nur dafür da, wie rum der Code gelesen wird. Wenn zum Beispiel die Kassiererin eine Ware über ihren Pieptisch zieht, dann achtet die ja nicht darauf, ob der Code nun richtig oder Kopfrum ist. Kopfrum wäre das ja ein ganz anderer Code. Anhand der Start- und Endzeichen weiß der Scanner aber nun, wie rum das sein muß. Dass der Scanner nun diese Zeichen als ö und _ mitschreibt liegt aber mit Sicherheit nur an dem Treiber bzw. dem Tool zum Scanner. Nötig ist das nicht, denn die Scanner die ich kenne, schreiben die nicht mit und schreiben nur die reinen Daten in die Datenbank. Wenn man nun aus den Daten mittels entsprechenden Konverter einen Barcode erzeugen würde, dann würde der ja seinerseits wieder ein Start und ein Endzeichen generieren und wenn der dann die Daten aus der Datenbank 1:1 übernimmt, dann schreibt der doch "sein Starzeichen"ö12345_"Sein Endzeichen" und wenn man den Code dann einscannt, hätte man öö12345__.

[Mondragor]

also in dem Fall, wo ö und _ in der Datenbank stehen, und du danach suchen willst, aber ohne diese Anhänge vorn und hinten, würde ich einfach eine "enthält"-Suche machen.
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

[RalphS]

Kann man machen... aber warum sollte man? Indices mögen LIKEs nicht so wirklich. Klar kann man das auch so konfigurieren, aber... ist halt aufwendiger, und bringt nicht viel.

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

[Mondragor]

Mein Beitrag ging ja davon aus, es erstmal zu finden, klar, einfach so "ö".$x."_" zusammenzusetzen ist für MySQL besser, hast Recht.
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