Mysql trim auf alle Spalten anwenden? und vs. php
Henry
- mysql
- php
Hallo,
gibt es eine Möglichkeit trim() auf alle Spalten gleichzeitig anzuwenden ohne diese einzeln aufzulisten?
Und noch eine Frage, löscht mysql-trim auch, wie bei der PHP-Funktion, Zeilenumbruchzeichen wie zb. "\r\n"?
Gruss
Henry
Lieber Henry,
gibt es eine Möglichkeit trim() auf alle Spalten gleichzeitig anzuwenden ohne diese einzeln aufzulisten?
meines Wissens nicht. Das Handbuch nennt nur SELECT-Beispiele, die diese TRIM-Funktion auf die jeweils explizit genannte Spalte anwenden. Es handelt sich eben um eine String-Funktion für SQL. Aber es gibt da ja auch noch die Möglichkeiten mit SELECT TRIM(*) FROM tbl
...
Liebe Grüße
Felix Riesterer
Hallo Felix,
ich bin verwirrt...
meines Wissens nicht. Das Handbuch nennt nur SELECT-Beispiele, die diese TRIM-Funktion auf die jeweils explizit genannte Spalte anwenden. Es handelt sich eben um eine String-Funktion für SQL.
genau habe auch keinen Hinweis darauf gefunden, dass es gehen könnte.
Aber es gibt da ja auch noch die Möglichkeiten mit
SELECT TRIM(*) FROM tbl
...
Das allerdings, als Abfrage, würde mir durchaus reichen. Bist du sicher, dass das gehen müsste? Weil, ich bekomme da nur eine Fehlermeldung oder verstehe ich dich falsch?
SELECT TRIM(*) FROM trimtest
MySQL meldet: Dokumentation
#1064 - Fehler in der SQL-Syntax. Bitte die korrekte Syntax im Handbuch nachschlagen bei '*) FROM trimtest
Gruss
Henry
Hallo Henry,
ich glaube, dass Felix sich da geirrt hat. Es gibt meines Wissens nur eine Funktion, die den Stern als Parameter verträgt, und das ist COUNT(*).
Wenn Du trimmen musst, wirst Du um spaltenweisen Aufschrieb nicht herum kommen.
TRIM entfernt nur Spaces, kein Whitespace (d.h. Tab und Zeilenende werden nicht bearbeitet). Wenn Du das brauchst, müsstest Du das von Hand machen. Vor MYSQL 8 musst Du dafür TRIM mehrfach geschachtelt aufrufen. Für \r oder \n brauchst Du die Syntax TRIM(BOTH '\n' FROM spalte). Ab MySQL 8 gibt es REGEX_REPLACE.
Um Dir nicht pro Spalte den Wolf zu tippen, könntest Du die Trimmerei in einer Stored Funktion kapseln (siehe CREATE FUNCTION im Handbuch).
Rolf
Hallo Rolf,
Wenn Du trimmen musst, wirst Du um spaltenweisen Aufschrieb nicht herum kommen.
ok. Danke.
Für \r oder \n brauchst Du die Syntax TRIM(BOTH '\n' FROM spalte).
Habe da mal ein paar Versuche angestellt, sowohl mit trim als auch mit replace. Funktioniert mit CHAR(13, 10) wie auch '\r\n'. Aber nicht in Spalten vom typ=text, da tut sich gar nichts. Ist das normal?
Gruss
Henry
Hello,
Wenn Du trimmen musst, wirst Du um spaltenweisen Aufschrieb nicht herum kommen.
ok. Danke.
Für \r oder \n brauchst Du die Syntax TRIM(BOTH '\n' FROM spalte).
Habe da mal ein paar Versuche angestellt, sowohl mit trim als auch mit replace. Funktioniert mit CHAR(13, 10) wie auch '\r\n'. Aber nicht in Spalten vom typ=text, da tut sich gar nichts. Ist das normal?
Dann bau dir doch mal eine HEX-Anzeige für das Textfeld. Was steht denn tatsächlich hinten hinter? Vielleicht hängt ein EOT hinten dran.
Es ist nie gut, im Blindflug irgendwelche Codierungsmanipulationen zu planen.
Woher kommen denn die Daten, und wie sind sie in die Datenbank gelangt?
Glück Auf
Tom vom Berg
Hallo TS,
Dann bau dir doch mal eine HEX-Anzeige für das Textfeld. Was steht denn tatsächlich hinten hinter? Vielleicht hängt ein EOT hinten dran.
Das sagt mir leider nie was:
7a 2e 42 2e 20 48 61 6c 6c 6f 20 54 65 73 74 20 66 c3 bc 72 20 54 65 73 74 65 72 20 20 20 76 6f 6e 20 54 65 73 74 79
Es ist nie gut, im Blindflug irgendwelche Codierungsmanipulationen zu planen.
Darum frage ich ja hier und teste.
Woher kommen denn die Daten, und wie sind sie in die Datenbank gelangt?
Gemischt durch Html Formulare und PHP Scripts, und nein es geht nicht um Prävention, es geht um bereits passierte (was ist wenn) Fehleinträge.
Gruss
Henry
Hello,
Dann bau dir doch mal eine HEX-Anzeige für das Textfeld. Was steht denn tatsächlich hinten hinter? Vielleicht hängt ein EOT hinten dran.
Das sagt mir leider nie was:
7a 2e 42 2e 20 48 61 6c 6c 6f 20 54 65 73 74 20 66 c3 bc 72 20 54 65 73 74 65 72 20 20 20 76 6f 6e 20 54 65 73 74 79
ASCII-Tabelle usw. zur Hand und dann gibts auch Converter im Web
Glück Auf
Tom vom Berg
Hallo TS,
7a 2e 42 2e 20 48 61 6c 6c 6f 20 54 65 73 74 20 66 c3 bc 72 20 54 65 73 74 65 72 20 20 20 76 6f 6e 20 54 65 73 74 79
ASCII-Tabelle usw. zur Hand und dann gibts auch Converter im Web
Klar, nur dann gibt er mir ja nur wieder das aus was ich auch in Klarschrift in der DB sehe, na ja fast der Konverter hier kommt irgendwie nicht mit UTF-8 zurecht. "z.B. Hallo Test für Tester von Testy"
Nur, wie werte ich das jetzt aus, seltsam ist schon dass keine Umbrüche jetzt da sind, welche ich aber bei der Ausgabe und bei Phpmyadmin sehe.
Gruss
Henry
Auch die Zeilenumbrüche sind nur Bytesequenzen:
printf ("%02X %02X", unpack "CC", "\r\n"); # 0D 0A
MFG
Hallo Henry,
eine Ausgabe kann von vielem beeinflusst sein. Die Hex-Sequenz, die du uns zeigst, enthält nur Buchstaben und innere Leerstellen. Umbrüche werden von ihr nicht veranlasst.
Für deine Hex-Sequenz reicht übrigens die Ascii-Tabelle nicht, es ist - wie man an der merkwürdigen Decodierung von "für" sieht, eine UTF-8 Sequenz. D.h. du musst wissen, wie man UTF-8 in Codepoints decodiert, dann noch eine Unicode-Codetabelle haben und die Unicode-Kombinationsregeln kennen. Das ist eeetwas mehr als eine ASCII-Tabelle.
Und eine ASCII-Tabelle ist heutzutage ohnehin wertlos. Das ist ein 7-bit Code, die heutigen Singlebyte-Codes sind 8-bittig, und es gibt eine Menge davon. Guck Dir in der Wikipedia die Ausführungen zu Codepage 1252 und der ISO-8859 Familie an, und wenn Du mit Kotzen fertig bist, kannst Du noch versuchen, Unicode in allen Feinheiten (Astral Planes, Encoding-Regeln, Kombinationen, Normalisierung) zu verstehen. Solltest Du dann wider Erwarten noch leben, lies hier weiter 😉
Die UTF-8 Multibyte-Zeichen in deiner Hex-Sequenz kann übrigens die Tools-Seite von Browserling ganz gut. Ob der mit den Astralplanes klar kommt (wo z.B. die Emojis leben), weiß man natürlich nicht.
Das innere Dreifachspace bekommst Du mit TRIM nicht in den Griff, falls Du das gehofft hast.
Rolf
Liebe Mitdenker, liebe Wissende, liebe Neugierige,
Und eine ASCII-Tabelle ist heutzutage ohnehin wertlos.
Das stimmt so nicht!
Die ASCI-Tabelle (7 Bit) ist seit über 40 Jahren immer noch gültig und sollte immer den Einstieg in die Untersuchungen bei Codierngen darstellen. Alternativ sollte man aber auch EBCID und andere nicht außer Betracht lassen.
Als nächstes kommt dann der Hexadezimalcode (Bytedarstellung) der Nachricht. Wenn dort Werte ab 0x80 enthalten sind, spricht dies für "Codepages" oder z. B. Multibytekodierungen, wie z. B. UTF-8.
Hier waren die Bytecodes
7a 2e 42 2e 20 48 61 6c 6c 6f 20 54 65 73 74 20 66 c3 bc 72 20 54 65 73 74 65 72 20 20 20 76 6f 6e 20 54 65 73 74 79
c3 bc
größer als 7F
. Die gesuchten 0A 0D
Sequenzen waren aber nicht enthalten.
An dieser Stelle kann man dann mit dem Ausprobieren von Codierungen weitermachen.
Hallo Robert,
Und eine ASCII-Tabelle ist heutzutage ohnehin wertlos.
Das stimmt so nicht!
Ich habe die Ironie wohl nicht dick genug aufgetragen, dass Du sie übersehen hast 😉
Und ich habe doch auch begründet, weshalb ich das so gesagt habe. Letztlich meinen wir das gleiche: ASCII reicht nicht, es ist nur der Einstieg ins Codepage-Quiz.
(Die IBM Saurier verwenden übrigens EBCDIC („epssiedick“), nicht EBCID).
Rolf
Liebe Mitdenker, liebe Wissende, liebe Neugierige,
Hallo Robert,
Und eine ASCII-Tabelle ist heutzutage ohnehin wertlos.
Das stimmt so nicht!
Ich habe die Ironie wohl nicht dick genug aufgetragen, dass Du sie übersehen hast 😉
Und ich habe doch auch begründet, weshalb ich das so gesagt habe. Letztlich meinen wir das gleiche: ASCII reicht nicht, es ist nur der Einstieg ins Codepage-Quiz.
(Die IBM Saurier verwenden übrigens EBCDIC („epssiedick“), nicht EBCID).
Danke für die Korrektur. Ich darf hier leider nur kurze Zeit nach Posting nachbessern.
Aber auf die Tabellen des Quiz hat ja Tom schon hingewiesen.
Spirituelle Grüße
Euer Robert
Hallo TS,
Dann bau dir doch mal eine HEX-Anzeige für das Textfeld. Was steht denn tatsächlich hinten hinter? Vielleicht hängt ein EOT hinten dran.
Das sagt mir leider nie was:
7a 2e 42 2e 20 48 61 6c 6c 6f 20 54 65 73 74 20 66 c3 bc 72 20 54 65 73 74 65 72 20 20 20 76 6f 6e 20 54 65 73 74 79
MFG
Hallo,
gibt es eine Möglichkeit trim() auf alle Spalten gleichzeitig anzuwenden ohne diese einzeln aufzulisten?
Vermutlich beim Insert? Tipp: Mache nie ein Insert ohne die Spalten namentlich aufzulisten. Und was das trim() betrifft, kommt ohnehin PHP noch vor dem Insert, wo mittels PHP i.d.R. geprüft wird ob eine Eingabe vorliegt und da muss sowieso ein trim() erfolgen. Zumindest bei den Pflichtfeldern.
MFG
Hello,
gibt es eine Möglichkeit trim() auf alle Spalten gleichzeitig anzuwenden ohne diese einzeln aufzulisten?
Das wäre unsinnig. Trim() hat nur einen Sinn für Textformate. Was soll dabei herauskommen, wenn Du einen Bigint trimmen lässt?
Varchar-Spalten werden u. U. sowieso automatisch getrimmt, da kämd mif eher in den Sinn, diese Eigemschaft mittels binary abzuschalten.
Und noch eine Frage, löscht mysql-trim auch, wie bei der PHP-Funktion, Zeilenumbruchzeichen wie zb. "\r\n"?
Das kannst Du dir im Manual unter Stringfunktionen genauer ansehen. :-)
Glück Auf
Tom vom Berg