philipp-schoene Geschrieben 24. Februar 2009 Geschrieben 24. Februar 2009 Hallo, Ich möchte mein PHP Script nach einen String, der Umlaute enthält suchen lassen. Es werden keine Datensätze gefunden. Die MySQL-Abfrage, die dafür generiert wird lasse ich mir auch im Browser ausgeben. Wenn ich diese nun mit Copy und Paste in PHPMyAdmin kopiere, findet er 23 Datensätze. Ich vermute, dass es an den Umlauten liegt, denn die anderen Filterkriterien ohne Umlaute funktionieren. Muss ich bei Umlauten etwas bestimmtes beachten? Zitieren
flashpixx Geschrieben 24. Februar 2009 Geschrieben 24. Februar 2009 Welches Encoding verwendest Du im HTML Format, welches in PHP und welches in der Datenbank? Phil Zitieren
philipp-schoene Geschrieben 26. Februar 2009 Autor Geschrieben 26. Februar 2009 ich setze in HTML den Metatag mit iso-8859-1, und MySQL ist der uft8-unicode-ci. Wie ließt man in PHP den Zeichensatz aus? Zitieren
flashpixx Geschrieben 26. Februar 2009 Geschrieben 26. Februar 2009 Es kommt in PHP meines Wissens darauf an, in welchem Encoding die PHP Dateien vorliegen. Phil Zitieren
Aiun Geschrieben 26. Februar 2009 Geschrieben 26. Februar 2009 nein. in PHP ist nur relevant, falls strings direkt im Quellcode vorhanden sind. soweit beschrieben sendet der browser ISO 8859-1, der Mysql-Server sucht dann in utf8. Dann sollte klar sein wo das Problem liegt alles was vom browser an den Server geht muss in utf8 konvertiert werden. Wundert mich dann nur das es keine Fehler in der Ausgabe gibt, da der Mysql-Server ja auch utf8 liefert. Zitieren
flashpixx Geschrieben 26. Februar 2009 Geschrieben 26. Februar 2009 nein. in PHP ist nur relevant, falls strings direkt im Quellcode vorhanden sind. genau darauf habe ich mich bezogen. Wundert mich dann nur das es keine Fehler in der Ausgabe gibt, da der Mysql-Server ja auch utf8 liefert. ein PHP String der von außen per ISO gesetzt wurde wird so an die mySQL Datenbank gereicht, sprich, der Server interpretiert die Zeichen als UTF8. Beim ISO Latin sind die Zeichen an der gleichen Position wie beim UTF8, darum funktionieren auch die Abfragen (siehe Kodierung UTF-8 ? Wikipedia). Umlaute liefern dann etwas anderes. Phil Zitieren
philipp-schoene Geschrieben 26. Februar 2009 Autor Geschrieben 26. Februar 2009 wie kann ich denn das Problem mit den verschiedenen Zeichensätzen lösen? also das ich die Umlaute beim Abfragen nutzen kann? Zitieren
perdian Geschrieben 26. Februar 2009 Geschrieben 26. Februar 2009 wie kann ich denn das Problem mit den verschiedenen Zeichensätzen lösen? also das ich die Umlaute beim Abfragen nutzen kann? (a) Zeichensatz über alle verwendeten Systeme konsistent halten oder ( an den entsprechenden Stellen konvertieren Zitieren
philipp-schoene Geschrieben 2. März 2009 Autor Geschrieben 2. März 2009 Ist es überhaupt sinnvoll mit Worten abzufragen? Ich beschreibe mal kurz die Situation: Ich habe eine todo-Liste als MySQL-Tabelle vorliegen. Eine andere Tabelle enthält Talsperren, an denen arbeiten anfallen mit IDs. Bisher habe ich nach dem Talsperrennamen gefiltert. Wäre es besser nach der Talsperren ID zu filtern und dann den Namen nur bei der Ausgabe an den User anzuzeigen? Zitieren
flashpixx Geschrieben 2. März 2009 Geschrieben 2. März 2009 Ohne Dein Datenbankdesign zu kennen ist eine sinnvolle Bewertung kaum möglich. Phil Zitieren
philipp-schoene Geschrieben 2. März 2009 Autor Geschrieben 2. März 2009 So sieht das Datenbankdesign aus: Tabelle arbeiten id int(11) Nein auto_increment eingangsdatum date Nein talsperren_id int(2) Nein ort varchar(200) utf8_unicode_ci Nein kunde varchar(40) utf8_unicode_ci Nein aufgabenbeschreibung text utf8_unicode_ci Nein bearbeiter_id int(2) Nein abschlussdatum date Nein status_id int(2) Nein Tabelle bearbeiter bearbeiter_id int(2) Nein bearbeiter_name varchar(30) latin1_swedish_ci Nein Tabelle talsperren talsperren_id int(2) Nein talsperren_name varchar(40) utf8_unicode_ci Nein Tabelle tblstatus status_id int(2) Nein status_name varchar(30) utf8_unicode_ci Nein Zitieren
flashpixx Geschrieben 2. März 2009 Geschrieben 2. März 2009 Warum hast Du innerhal Deiner Tabellen unterschiedliches Encoding? Außerdem nützt das recht wenig die Ausgabe von phpMyAdmin zu posten, poste bitte ein ERM, in dem man die Beziehungen sehen kann (Entity-Relationship-Modell ? Wikipedia) Phil Zitieren
philipp-schoene Geschrieben 2. März 2009 Autor Geschrieben 2. März 2009 Warum hast Du innerhal Deiner Tabellen unterschiedliches Encoding? Phil Weil ich die nachträglich umgestellt habe. Habe die eine Tabelle wohl vergessen. Mir ist nur aufgefallen, dass nach Umstellung nur noch 54 der 110 Einträge angezeigt werden. Außerdem nützt das recht wenig die Ausgabe von phpMyAdmin zu posten, poste bitte ein ERM, in dem man die Beziehungen sehen kann (Entity-Relationship-Modell ? Wikipedia) Kann isch das ERM irgendwo rausziehen oder wie soll ich das hier posten? Ich kann sagen, dass die Tabellen tblstatus, bearbeiter und talsperren jeweils in 1:n -Beziehung zu tabelle arbeiten stehen. Zitieren
flashpixx Geschrieben 3. März 2009 Geschrieben 3. März 2009 Kann isch das ERM irgendwo rausziehen oder wie soll ich das hier posten? Ich kann sagen, dass die Tabellen tblstatus, bearbeiter und talsperren jeweils in 1:n -Beziehung zu tabelle arbeiten stehen. Ich verweise Dich auf Deinen eigenen Thread, da ich Dir damals zum allg. DB Design schon umfangreiche Informationen gegeben habe und mich ungern wiederhole: Forum Fachinformatiker.de - Einzelnen Beitrag anzeigen - Daten in Access von anderer DB importieren Phil Zitieren
philipp-schoene Geschrieben 3. März 2009 Autor Geschrieben 3. März 2009 Wozu willst du da groß ein Design machen? Schreibst du für 1 + 1 = 2 auch eine 10 DIN A 4 Seiten lange Rechnung????? Also lass und mal nicht übertreiben! Es handelt sich um ganz einfache Beziehungen. Ich habe im vorherigen Beitrag schon geschrieben, wie ich das mir vorgestellt habe. Abgesehen kann man unabhängig davon auch mal die Feldnamen ansehen. Wie wäre es mal mit konstruktiven Lösungen als auf ollen Kamellen herumzureiten? Zitieren
T3D Geschrieben 5. März 2009 Geschrieben 5. März 2009 jag die daten im php script vorher durch PHP: utf8_encode - Manual dann sollte er die codierten daten inna DB auch finden Zitieren
philipp-schoene Geschrieben 6. März 2009 Autor Geschrieben 6. März 2009 Vielen Dank für deine Antwort T3D. Ich überlege, ob es nicht generell besser ist, nach der ID anstatt nach dem Namen zu suchen. Ich habe das schon bei vielen anderen Systemen gesehen. Aber selbst habe ich damit noch nicht Erfahrungen gemacht. Deswegen würde ich euch gern Frage, was ihr davon haltet. Zitieren
Aiun Geschrieben 6. März 2009 Geschrieben 6. März 2009 ich verallgemeiner mal, da ich deine DB nicht kenne. "normalerweise" sucht man immer nur nach IDs, "nie" nach Namen. (es sei denn natürlich, die Funktion soll explizit alle mit Namen XY finden ^^) Ein Name kann mehrfach vorkommen, eine ID (Primärschlüssel) nicht. Somit sind nur Funktionen mit IDs zuverlässig. Zitieren
T3D Geschrieben 6. März 2009 Geschrieben 6. März 2009 generell solltest du immer den PK als suchindex nehmen... allerdings kann es ja auch vorkommen das du indiviuelle suchen haben moechtest.. wie zbsp mit einer eingabe des nutzers.. also ganz drumherum kommen nach name / orten / strassen was auch immer wirst du nicht. noch als tipp... wenn du die daten wieder ausliest und zbsp in ein input feld oder eine textarea schreibst... bedenke das du die daten wieder decodieren musst... in normaler textausgabe musst du es nicht .. da der browser?, bin mir da unsicher, dies von allein erledigt. Ted Zitieren
philipp-schoene Geschrieben 15. März 2009 Autor Geschrieben 15. März 2009 vielen Dank, ich habe die Suche jeweils auf die ID umgestellt. Ich habe nur den Suchbegriff nochmal dem User dargestellt. Nun ergibt sich ein Problem. Ich habe ja auch IDs umgestellt und so klappte das nicht mehr. Ich frage nun ein Array ab und übergebe diesen Wert an das Template. Es kommt aber nicht an. Wenn ich aber die Daten mit print ausgebe klappt das. Code mit Smarty-Templatesystem home.php: $filter_bearbeiter_wert = $bearbeiter_auswahlliste_liste[$_POST['auswahl_bearbeiter']-1][0]['bearbeiter_name']; $filter_bearbeiter = true; [...] $smarty->assign('filter_bearbeiter',$filter_bearbeiter); $smarty->assign('filter_bearbeiter_wert',$filter_bearbeiter_wert); [/PHP] home.tpl [code]{if $filter_bearbeiter} <li>Filter Bearbeiter: {$filter_bearbeiter_wert}</li> {/if}[/code] Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.