PHP Problem mit Umlauten aus GET-Parameter

öhm, weil du zb bei mitglieder nach mitglieder suchst oO
und bei termine nach termine, und nicht nach dem kino programm, die kinoprogramm suche muss ich erst machen, das is aber net so einfach weil das kinoprogramm automatisch von der kino seite übertragen wird und so =)


wer nimmt schon IE :D


ok, korrektur hab ich keine, wäre aber eine gute idee xD

jop... so wie bing vs google rofl ^^



aber wegn deinem umlautproblem oO
mach dir mal ein script, das die umlaute ausbessert,
zb sowas in der art:

function korrUmlaute($text) {
$umlaute = array(
'ä' => 'ä',
'Ä' => 'Ä',
'ö' => 'ö',
'Ö' => 'Ö',
'ü' => 'ü',
'Ü' => 'Ü',
'ß' => 'ß'
);

foreach($umlaute as $key => $repl) {
$text = str_replace($key,$repl,$text);
}

return $text;

}


also damit mal die umlaute in der DB ersetzt sind .. musst halt anpassen ^^
das problem hatte ich nämlich bei meiner seite auch, wie ich aufeinmal alles auf UTF-8 stellte... ^^

oder durchsuchst du gar keine db? (könnt ja sein ^^)
 
D.h. ich kann - wenn ich mich auf der Member-Seite befinde, wo die Mitgleider aufgelistet sind - nach den Mitgliedern suchen? Kurz gesagt: ich suche mir die Seite mit den Infos die ich suchen möchte selbst, und durchsuche sie dann? Ich dachte eine Suchfunktion ist dazu da um Infos zu finden, die man nicht finden kann. Jetzt weiß ich, warum dein Script so kurz, und meins so lang ist :D


Zum Problem: die Umwandlung hab ich ja schon. Aber das Problem tritt anscheinend während der Ausgabe auf - also nachdem die Umlaute umgewandelt wurden:
PHP:
164    $tmpl = join('', file('./tmpl/search_result.php')); 
... 

285    $file = fopen ("tmpl.php", "w+"); 
286    fwrite ($file, $tmpl); 
287    fclose($file); 
288    include("tmpl.php"); 
289    unlink("tmpl.php");
Die Frage ist eben, ob hierbei was mit der Kodierung falsch läuft. Alle Scripte sind als UTF-8 gespeichert, und nur bei der ausgabe sind die Umlaute plötzlich falsch dargestellt. Auch solche, die nicht in den Suchergebnissen stehen, sondern alle auf der Seite.


P.S.: nein, ich suche nicht in einer DB, sondern in einer Datei.
 
Zuletzt bearbeitet:
Ist das Zeug in der Datei dann auch in UTF8?
Wirf mal ein paar utf8_encode/decode in den Raum, ob du es damit irgendwie in den Griff bekommst.
 
Jo, alle Dateien sind UTF-8.

Ich habe die letzten 2 Stunden auch damit verbracht im Script alles mit utf8_decode etc. blabla zu bearbeiten, es klappt nicht.


Mittlerweile hab ich's auch irgendwie geschafft, dass die Lösung des eigentlichen Problems:
Mr. Snoot schrieb:
edit: mit header ("Content-Type: text/html;charset=utf-8"); zu Beginn scheint es zu klappen
nicht mehr nötig ist. Das klappt jetzt auch so :freak:

Aber diese Umlautprobleme am Anfang und am Ende der Suchausgabe


bekomme ich nicht in den Griff.
 
Mit dem 'reinwerfen' von utf8_encode und decode Funktionen wirst du sicher nicht weiterkommen.


Ich habe schon in Post #7 geschrieben, dass du das Problem isolieren musst, ansonsten wirst du niemals die Ursache finden.
 
Ich habe ja versucht im Code die Stelle zu finden, wo das Problem auftritt.

Aktuell ist es ja so, dass die Umlaute im Quellcode "falsch" dargestellt werden (ä = ä etc.), im Browser aber korrekt.

Die Funktion im Script, die die Suchausgabe erzeugt und am Anfang und am Ende '...' setzt hat mit den "falschen" Umlauten ein Problem und erkennt hier Wortanfang/-ende nicht richtig, so dass eben nicht das ganze Wort angezeigt wird, sondern mitten im Umlaut gretrennt wird. D.h. Waferoberfläche wird zu WaferoberflÃ. Daher wird der Umlaut auch im Browser nicht mehr als ä sondern nur noch als angeeigt - weil ja die Hälfte fehlt.


Also habe ich versucht, dem zuvorzukommen und die Umlaute mit bspw. utf8_decode() zu ändern (das ist die Variable $a ab Zeile 367). Das hat dann die Folge, dass die Umlaute im Quellcode korrekt sind, dafür aber jetzt im Browser anstelle dessen generell nur noch als angezeigt werden.


Wie bekomme ich das jetzt unter einen Hut, so dass die Umlaute im Quellcode und im Browser korrekt angezeigt werden?
 
Was meinst du mit Quelltext?

Die Quelltextansicht im Browser? Da liegst du falsch, diese Ansicht unterscheidet sich nicht von der normalen Ansicht.


Ich habe ja versucht im Code die Stelle zu finden, wo das Problem auftritt.

Mit isolieren habe ich gemeint, dass du den Code soweit zusammenfassen und kürzen sollst, dass er portabel wird, und wir lokal deinen Code testen können, ohne auf deine ganzen includes und Datenfiles angewiesen zu sein.

Außerdem wird dadurch das Problem eingegrenzt.
 
Zuletzt bearbeitet:
Das meine ich:

quellcode.jpg

Werd mal sehen, was ich machen kann.
 
Vergiss Notepad. Und wenn du schon den IE benutzen musst, dann mache wenigstens das Upgrade auf Version 8.


Notepad zeigt die Umlaute falsch an, weil es den meta-header nicht berücksichtigt (warum denn auch - es ist ein TXT Editor).
 
erklär das nochmal mit dem Wort splitten....
also den teil:
D.h. Waferoberfläche wird zu WaferoberflÃ. Daher wird der Umlaut auch im Browser nicht mehr als ä sondern nur noch als � angeeigt - weil ja die Hälfte fehlt.
 
Hat er es nach deinem utf8_decode im Quelltext die Umlaute wenigstens richtig getrennt?
Dein Suchscript arbeitet offensichtlich auf winansi (das ist wohl auch der Grund, warum es im Editor "richtig" angezeigt wird). SIcher, dass das File als UTF8 gespeichert ist?

Wenn es mit den utf8_decode richtig getrennt hat, könntest du die Variablen am Ende einfach wieder mit utf8_encode in UTF8 umwandeln, dann sollte die Ausgabe im Browser richtig rauskommen.

Alllerdings ist das alles nicht wirklich schön...
 
luky37 schrieb:
Vergiss Notepad. Und wenn du schon den IE benutzen musst, dann mache wenigstens das Upgrade auf Version 8.
Das ist der 8er ;)
Notepad zeigt die Umlaute falsch an, weil es den meta-header nicht berücksichtigt (warum denn auch - es ist ein TXT Editor).
Wenn ich aber im Script utf8_decode anwende, zeigt Notepad sie korrekt an - und Textpad übrigens auch, welches unterschiedliche Kodierungen beherrscht.

Womit soll ich den Code denn am besten anschauen?
+ BELA B. + schrieb:
erklär das nochmal mit dem Wort splitten....
Das Suchscript gibt maximal 500 Zeichen Text pro gefundener Seite aus (250 Zeichen vor und 250 Zeichen nach dem gesuchten Wort). In jedem Fall aber ganze Wörter. Ist der Text nach dem Suchbegriff also bspw. 251 Zeichen lang, wird halt ein Wort weggelassen und nicht nur ein Buchstabe. Anscheinend erkennt das Script wegen der kodierten Sonderzeichen aber Wortanfang/-ende falsch und denkt daher, dass Waferoberfläche zwei Wörter sind: Waferoberflà und ¤che. Ist jetzt der ausgegebene Text mit dem Wort Waferoberfläche am Ende gerade knapp über 250 Zeichen, wird eben das letzte Wort - in dem Fall also das ¤che - abgeschnitten. Also bleibt Waferoberflà stehen. Zum einen ist jetzt natürlich nur das halbe Wort zu sehen, zum anderen ist à kein Umlaut mehr und wird als Kästchen angezeigt (¤ fehlt ja).
darkservant2 schrieb:
Hat er es nach deinem utf8_decode im Quelltext die Umlaute wenigstens richtig getrennt?
Wie meinst du das? Die Umlaute, die im Quelltext zu sehen sind, stehen da halt als ä o.ä. Getrennt werden soll eigentlich nichts bei der Ausgabe. Das ist ja anscheinend gerade der Fehler an der Sache (s. Zitat vorher).
SIcher, dass das File als UTF8 gespeichert ist?
Jap, 100 % - hab alles 500 mal kontrolliert und auch nochmal neu abgespeichert und hochgeladen.
Wenn es mit den utf8_decode richtig getrennt hat, könntest du die Variablen am Ende einfach wieder mit utf8_encode in UTF8 umwandeln, dann sollte die Ausgabe im Browser richtig rauskommen.
Ja - das schon. Dummerweise funktioniert dann die Markierung der Suchbegriffe nicht mehr - weil das preg_match den Suchbegriff im zu durchsuchenden, jetzt aber mit utf8-kodierten Text nicht mehr findet. Dann müsste ich da also auch wieder was ändern.
Alllerdings ist das alles nicht wirklich schön...
Nein, ehrlich gesagt ist das alles ziemlich kacke :p

Davor - als ich noch nicht auf die Kodierung beim Abspeichern der Scripte geachtet habe -, hat die Suchausgabe auch noch funktioniert (teilweise war da was mit ANSI kodiert, teilweise mit UTF-8). Aber das gab Probleme an anderer Stelle, weswegen ich alles einheitlich auf UTF-8 umgestellt habe.



Aber es kommt ja noch was dazu: die Startseite der Suchfunktion zeigt mir Umlaute im Quelltext richtig an (Ä, Ö, Ü, ä, ö, ü). Also z.B. Text, der da steht wie Groß-/Kleinschreibung beachten usw. Die Suchergebnisseite ist im Grunde wie die Startseite aufgebaut - enthält also auch diesen Text Groß-/Kleinschreibung beachten - aber es werden dann halt noch die Suchergebnisse in die Seite eingebaut.

Die Suchergebnisseite wird über das o.g. Suchscript aufgerufen:
PHP:
164    $tmpl = join('', file('./tmpl/search_result.php'));  
...  

285    $file = fopen ("tmpl.php", "w+");  
286    fwrite ($file, $tmpl);  
287    fclose($file);  
288    include("tmpl.php");  
289    unlink("tmpl.php");
Und wenn ich mir die Umlaute der Suchergebnisseite im Quellcode anschaue, dann sind diese nicht mehr korrekt - also ä statt ä usw. Und zwar nicht nur die Umlaute der Suchergebnisse, sondern eben auch das GroÃ₫-/Kleinschreibung beachten. Also muss bei diesem Include was geschehen, was die Kodierung zerbröselt.
 
Zurück
Oben