Zum Inhalt springen

Empfohlene Beiträge

Geschrieben

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?

Geschrieben

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.

Geschrieben
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

Geschrieben
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

(B) an den entsprechenden Stellen konvertieren

Geschrieben

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?

Geschrieben

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

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

Geschrieben

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

Geschrieben

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?

Geschrieben

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.

Geschrieben

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.

Geschrieben

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

  • 2 Wochen später...
Geschrieben

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]

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.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...