Umlaute, die mit GET hereinkommen

[Gast]

Hallo,

komme im Moment nicht weiter, wahrscheinlich eine einfache Sache. Per Get übergebe ich den String "Urlaub an der Küste".

Bei der Umwandlung mit htmlentities geht der ganze String verloren:

$arr_in['titel'] = $_GET['titel'];  
echo "[".$arr_in['titel']."]<br>\n";  
$arr_in['titel'] = htmlentities($arr_in['titel'], ENT_QUOTES, 'UTF-8');  
echo "[".$arr_in['titel']."]<br>\n";  

Anzeige:

[Urlaub an der K�ste]
[]

Woran liegt das?

Gruß, Gast

[Gunnar Bittersmann]

@@Gast:

nuqneH

Bei der Umwandlung mit htmlentities geht der ganze String verloren:

Vergiss am besten, dass es solch eine Funktion in PHP gibt, sie ist reichlich sinnfrei.

Verwende [link:http://de3.php.net/manual/de/function.htmlspecialchars.php@title=htmlspecialchars()] und lass die Umlaute u.a. Zeichen so wie sie sind!

$arr_in['titel'] = $_GET['titel'];

Wozu die Umkopiererei?

Qapla'

[Gast]

$arr_in['titel'] = $_GET['titel'];

Wozu die Umkopiererei?

Mache ich grundsätzlich am Anfang des Programms, um die Eingangswerte zusammenzufassen, zu prüfen und ggf. zu ergänzen.

Ist sozusagen der "Briefkasten" am Eingang, anstatt die Post über den Gartenzaun zu schmeissen und dann im Laufe des Programms einzusammeln.

Gast

[suit]

Ist sozusagen der "Briefkasten" am Eingang, anstatt die Post über den Gartenzaun zu schmeissen und dann im Laufe des Programms einzusammeln.

Wieso? Der Briefträger hat die Sache doch bereits sauber bei der Poststelle (PHP-Interpreter) abgeliefert und diese hat sie für dich vorsortiert auf deinen Schreibtisch ($_GET) gelegt. Wo siehst du da bitte einen Briefkasten?

[Gast]

Hallo, suit,

Ist sozusagen der "Briefkasten" am Eingang, anstatt die Post über den Gartenzaun zu schmeissen und dann im Laufe des Programms einzusammeln.

Wieso? Der Briefträger hat die Sache doch bereits sauber bei der Poststelle (PHP-Interpreter) abgeliefert und diese hat sie für dich vorsortiert auf deinen Schreibtisch ($_GET) gelegt. Wo siehst du da bitte einen Briefkasten?

Sehen wir es mal andersrum: Wenn ich wissen will, welche GET- oder POST- Parameter das Programm erwartet, schaue ich vorne nach. Da werden sie aufgeführt.

$arr_in = array (  
 'titel'                =>( $_POST['titel'] ) ? $_POST['titel'] : $_GET['titel']  
,'nachricht'            =>  trim( $_POST['nachricht'] ).''  
);

Und es wird dort entschieden, ob sie per GET, POST oder wahlweise reinkommen dürfen.

Vergiss am besten, dass es solch eine Funktion (htmlentities) in PHP gibt, sie ist reichlich sinnfrei.

Verwende [link:http://de3.php.net/manual/de/function.htmlspecialchars.php@title=htmlspecialchars()] und lass die Umlaute u.a. Zeichen so wie sie sind!

Naja, das wird an zentraler Stelle in einer Funktion gemacht. Habe da mal htmlspecialchars statt htmlentities eingesetzt. Mal sehen, in welchem Programm es rummst ...

LG Gast

[suit]

Und es wird dort entschieden, ob sie per GET, POST oder wahlweise reinkommen dürfen.

Dafür gibts $_REQUEST :)

Naja, das wird an zentraler Stelle in einer Funktion gemacht. Habe da mal htmlspecialchars statt htmlentities eingesetzt. Mal sehen, in welchem Programm es rummst ...

Ja schon gut - solange du auch die Daten nicht einfach nur "umkopierst" sondern eben auch zusammenführst, auf Sinnhaftigkeit prüfst usw. ist das durchaus sinnvoll - sowas kann man im Konstruktur einer Klasse machen und alles für den Rest vorbereiten und dann weiterverwenden .

[dedlfix]

Hi!

Verwende [link:http://de3.php.net/manual/de/function.htmlspecialchars.php@title=htmlspecialchars()] und lass die Umlaute u.a. Zeichen so wie sie sind!

Naja, das wird an zentraler Stelle in einer Funktion gemacht. Habe da mal htmlspecialchars statt htmlentities eingesetzt. Mal sehen, in welchem Programm es rummst ...

An zentraler Stelle behandelst du irgendwelche Zeichenketten? Und dann fragst du dich, wo dir das schaden kann? Warum machst du es nicht so, wie es sinnvoll ist? Während der Verarbeitung sind die Daten immer im Rohformat, also ohne irgendwelche ausgabespezifischen "Entstellungen". Nur so kann man sie sinnvoll verarbeiten (z.B: Zeichen zählen und andere Stringverarbeitung). Erst wenn die Ausgabe erstellt wird, werden die dafür notwendigen Behandlungen vorgenommen. Dann musst du auch nicht mehr nachforschen, ob die Daten schon behandelt sind oder nicht. Wenn sie im Rohformat sind, müsen sie ausnahmslos alle behandelt werden. Und dann sollte es auch auffallen, wenn mal eine Behandlung fehlt.

Lo!

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunnar Bittersmann!

Vergiss am besten, dass es solch eine Funktion in PHP gibt, sie ist reichlich sinnfrei.

Es sei denn, man muss mit einem sqlite arbeiten, das kein utf-8 kann.

Matthias

[dedlfix]

Hi!

Vergiss am besten, dass es solch eine Funktion in PHP gibt, sie ist reichlich sinnfrei.
Es sei denn, man muss mit einem sqlite arbeiten, das kein utf-8 kann.

Mag sein, dass SQLite so einfach ist, dass ihm keine Funktionalität spendiert wurde, mit Zeichenkodierungen und Kollationen umzugehen, aber das heißt nur, dass man keine Stringfunktionen (nebst Sortierung) darauf loslassen kann. Es wird auch nicht besser, wenn man statt Nicht-ASCII-Zeichen eine Ersatzschreibweise verwendet. Die nicht mögliche Stringverarbeitung bleibt nicht nur bestehen, durch die Verunstaltung kann man den String auch dann nur schwer verarbeiten, wenn er wieder aus dem DBMS rauskommt. Es ist ja nicht so, dass SQLite nur ASCII oder Bytes von 0..7F verarbeiten könnte, also kann man ruhig UTF-8-kodierten Text genauso wie ISO-8859-1-kodierten übergeben und auch wieder so empfangen.

Lo!

[Matthias Apsel]

Om nah hoo pez nyeetz, dedlfix!

Es sei denn, man muss mit einem sqlite arbeiten, das kein utf-8 kann.

Es ist ja nicht so, dass SQLite nur ASCII oder Bytes von 0..7F verarbeiten könnte, also kann man ruhig UTF-8-kodierten Text genauso wie ISO-8859-1-kodierten übergeben und auch wieder so empfangen.

Mir wollte es allerdings nicht gelingen, ein in einer SQLite-DB gespeichertes "Straße" als "Straße" in einer utf-8-kodierten Datei auf den Bildschirm zu bringen. Es endete in "Stra�e". Und aufgrund dieses Zeichens verweigerte auch der Validator die Überprüfung des Dokumentes.

Aber vielleicht gibt es ja auch andere Möglichkeiten (mit SQLite !important)?

siehe auch sqlite-libencoding.php

Matthias

[dedlfix]

Hi!

Mir wollte es allerdings nicht gelingen, ein in einer SQLite-DB gespeichertes "Straße" als "Straße" in einer utf-8-kodierten Datei auf den Bildschirm zu bringen. Es endete in "Stra�e".

Das sieht so aus, als ob die Straße in ISO-8859-1-Kodierung in der DB liegt, du das da rausliest und versuchst, es so in einen UTF-8-Kontext zu bringen. Da fehlt noch ein Umkodieren nach UTF-8. Selbst wenn die Straße UTF-8-kodiert ist und SQLite mit ISO-8859-1-Kompatibilität kompiliert wurde, darf das ß nicht verlustig gehen. Denn wenn du ein UTF-8-ß hingibst und SQLite es als ß liest, sollte es wieder ein UTF-8-ß werden, wenn SQLite sein ß liefert und du es als UTF-8 interpretierst. Umkodieren darf SQLite nicht, denn ß ist ja aus seiner Sicht perfektes ISO-8859-1. Dass diese Zeichenfolge für Menschen wenig Sinn ergibt, merkt SQLite ja nicht.

Lo!

[Matthias Apsel]

Om nah hoo pez nyeetz, dedlfix!

Das sieht so aus, als ob die Straße in ISO-8859-1-Kodierung in der DB liegt, du das da rausliest und versuchst, es so in einen UTF-8-Kontext zu bringen. Da fehlt noch ein Umkodieren nach UTF-8.

Das gibt ja mal ein dickes "fachlich hilfreich" !!einselfhundertelf

Matthias

[Gast]

ich weiss zwar nicht, warum der String verlorengegangen ist, aber mit

$arr_in['titel'] = htmlentities(utf8_encode($arr_in['titel']), ENT_QUOTES, 'UTF-8');

ist das Problem (scheinbar?) gelöst.

Gast

[dedlfix]

Hi!

ich weiss zwar nicht, warum der String verlorengegangen ist, aber mit
$arr_in['titel'] = htmlentities(utf8_encode($arr_in['titel']), ENT_QUOTES, 'UTF-8');
ist das Problem (scheinbar?) gelöst.

Nein. Zum einen ist es wenig sinnvoll, andere als die HTML-eigenen Zeichen als Entity/NCR zu schreiben. Ausnahmen sind zum Beispiel Whitespace-Zeichen, denen man nicht ansieht, dass sie eben kein einfaches Leerzeichen sind. Aber das braucht man eigentlich nur, wenn man die Zeichen zu Fuß notiert. In einer automatischen Verarbeitung bringen die Entitys/NCRs keine Vorteile gegenüber der Verwendung der eigentlichen Zeichen.

Aber schauen wir uns mal das Konstrukt an. Du sagst htmlentities(), dass es den übergebenen String als UTF-8-kodiert ansehen soll. Die Funktion kann aber nur dann ein richtiges Ergebnis bringen, wenn du den übergebenen String erst noch in UTF-8 umkodierst. Warum nimmst du dann nicht gleich ISO-8859-1/Latin1 - sprich, htmlentities() ohne charset-Parameter (falls du dich doch nicht entschließen kannst, auf htmlspecialchars() umzusteigen)? Oder anders gefragt, warum nahmst du an, UTF-8 zu verarbeiten, wenn dem ja gar nicht so ist?

Jedenfalls bekommst du einen Leerstring geliefert, wenn die Kodierung offensichtlich nicht zum angegebenen Wert passt, also hier kein gültiges UTF-8 ist. Das PHP-Handbuch schweigt sich allerdings aus, wie die Funktion im Fehlerfall reagiert.

Lo!

[suit]

Nein. Zum einen ist es wenig sinnvoll, andere als die HTML-eigenen Zeichen als Entity/NCR zu schreiben. Ausnahmen sind zum Beispiel Whitespace-Zeichen, denen man nicht ansieht, dass sie eben kein einfaches Leerzeichen sind.

Oder andere schwer unterscheidbare Zeichen - Bindestriche, Gedankenstriche, Minus-Zeichen oder das Multiplikationszeichen und das keine X sind in manchen Schriftarten kaum (oder nicht) unterscheidbar.

[Gunnar Bittersmann]

@@suit:

nuqneH

Oder andere schwer unterscheidbare Zeichen - Bindestriche, Gedankenstriche, […]

Ich sehe deutlich, dass du hier keinen Gedankenstrich gesetzt hast. ;-b

Qapla'

[suit]

Oder andere schwer unterscheidbare Zeichen - Bindestriche, Gedankenstriche, […]

Ich sehe deutlich, dass du hier keinen Gedankenstrich gesetzt hast. ;-b

Das nennt man Monospace-Krankheit - "da gibt es nicht so viele Zeichen" und muss auf Ersatzzeichen zurückreifen.

Hast du's gemerkt? Ich hab' statt den toolen Anführungszeichen einfach das "gewöhnliche" genommen? Oh, schon wieder: ich hab' statt dem Apostroph einfach das "gewöhnliche" Apostroph verwandt.

Ich bin ein Schelm, der gerne Ersatzzeichen verwendet :)

[Kai345]

[latex]Mae  govannen![/latex]

und muss auf Ersatzzeichen zurückreifen.

Und ich dachte immer, man reift im Laufe der Zeit (also "vorwärts").

Stur lächeln und winken, Männer!
Kai

[suit]

und muss auf Ersatzzeichen zurückreifen.

Und ich dachte immer, man reift im Laufe der Zeit (also "vorwärts").

Nein, ich schoss über das Ziel hinaus - jetzt muss ich erst wieder zurückreifen, damit das Kind im Manne besser rauskommt :p

[Gunnar Bittersmann]

@@suit:

nuqneH

Ich bin ein Schelm, der gerne Ersatzzeichen verwendet :)

Du solltest dich Der suit nennen. ;-)

Qapla'

[Felix Riesterer]

Lieber Gunnar Bittersmann,

Ich bin ein Schelm, der gerne Ersatzzeichen verwendet :)

Du solltest dich Der suit nennen. ;-)

LOL!!!!

Liebe Grüße,

Felix Riesterer.