Wenn du bei der Eingabe utf8_decode verwenden musst dann stimmt doch irgendwas noch nicht, weil utf8_decode einen utf8 string ja in einen ISO-8859-1 String.
http://de2.php.net/manual/de/function.utf8-decode.php
Sind die PHP Scripte selber auch als UTF8 gespeichert?
http://de2.php.net/manual/de/function.utf8-decode.php
Sind die PHP Scripte selber auch als UTF8 gespeichert?
ind die PHP Scripte selber auch als UTF8 gespeichert?
ähm äh.. nee
btw. die funktion muss ich net erklärt bekommen..
mich wunderts ja selber .. aber ohne diesem decode bekomme ich keine gute ausgabe hin, ohne daran wieder schrauben zu müssen..
und mein programm unterstützt nicht wirklich utf8.. wie zwingend notwendig ist es denn?!
ich meine.. wieso und warum und weshalb muss mein programm dateien als utf8 abspeichern?
ich bin auf der homepage ja nicht mit diesem programm unterwegs
|
Achtung: Dirk Kántor ist unterwegs! Er verteilt gerne Verwarnungen ohne vorher darüber diskutiert zu haben. |
Wie in Beitrag 7, das Funktion leider nur, wenn wirklich Alles auf UTF8 eingestellt ist, was auf den meisten Servern & auch CMS wie PHKIT nicht der Fall ist, sonst wäre uns die Befehle utf8_decode ode utf8_encode sicherlich ein Fremdwort.
Notwendig ist gar Nichts Alles auf den UTF8-Zeichensatz umzuschreiben, Fakt ist aber, das dieser ein internationaler Standard ist (geworden ist) & wenn Dein Script oder was auch immer dies so speichert bist Du immer auf der sicheren Seite im Moment.
Wenn Dein Programm nicht "wirklich" UTF8 unterstützt, dann schau ob Du auch UTF8 in der DB als Zeichensatz eingestellt hast, dazu kommt, was ich oft habe, wenn ich Wörter in der PHP-Datei habe muss ich diese mit utf8_encode in die PHP-Datei "schreiben", aber wenn dies über $_POST kommen, dann wieder ohne utf8_encode.
Notwendig ist gar Nichts Alles auf den UTF8-Zeichensatz umzuschreiben, Fakt ist aber, das dieser ein internationaler Standard ist (geworden ist) & wenn Dein Script oder was auch immer dies so speichert bist Du immer auf der sicheren Seite im Moment.
Wenn Dein Programm nicht "wirklich" UTF8 unterstützt, dann schau ob Du auch UTF8 in der DB als Zeichensatz eingestellt hast, dazu kommt, was ich oft habe, wenn ich Wörter in der PHP-Datei habe muss ich diese mit utf8_encode in die PHP-Datei "schreiben", aber wenn dies über $_POST kommen, dann wieder ohne utf8_encode.
Es geht nicht darum zu haben was man will, sondern zu schätzen was man hat!
Blutrausch HP
Mauern sind auch nur Steine & Wassertropen können auch mal Wassermengen werden!
Blutrausch HP
Mauern sind auch nur Steine & Wassertropen können auch mal Wassermengen werden!
genau das unterstützt mein WS ja nich 
aber das wäre mir auch egal, was ich innerhalb der dateien schreibe, muss ich umwandeln, dass is ja normal..
mir gehts mehr um die eingaben direkt auf der homepage.. genau diese sind es die mir sorgen machen.. und das gewaltig und es nervt..
DB ist wie folgt umgestellt:
MySQL-Zeichensatz: UTF-8 Unicode
Zeichensatz / Kollation der MySQL-Verbindung: utf8_general_ci
Alle Tabellen haben als Kollation: utf8_general_ci
Alle Tabellenfelder haben als Kollation: utf8_general_ci
Quelltextauszug Frontend:
Quelltextauszug Backend:
Nach abspeichern in einer textarea wird das ö dazu: (im firefox son komisches Fragezeichen in einem oval)
Übergeben tu ich es so an die DB:
Er gibt mir das ö im Frontend auch aus:
Im Backend gebe ich die DB Inhalte direkt aus:
Im Frontend ebenfalls:
Im Frontend habe ich (natürlich!) alle Inhalte mit htmlentities() bestückt.. im Backend nicht..
Habe ich das htmlentities() nun entfernt, kommen ebenfalls diese Fragezeichen..
Heisst das nun ich muss htmlentities() ebenfalls im Backend verwenden, damit diese Fragezeichen verschwinden?!

aber das wäre mir auch egal, was ich innerhalb der dateien schreibe, muss ich umwandeln, dass is ja normal..
mir gehts mehr um die eingaben direkt auf der homepage.. genau diese sind es die mir sorgen machen.. und das gewaltig und es nervt..
DB ist wie folgt umgestellt:
MySQL-Zeichensatz: UTF-8 Unicode
Zeichensatz / Kollation der MySQL-Verbindung: utf8_general_ci
Alle Tabellen haben als Kollation: utf8_general_ci
Alle Tabellenfelder haben als Kollation: utf8_general_ci
Quelltextauszug Frontend:
|
|
HTML |
1 2 3 4 |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> |
Quelltextauszug Backend:
|
|
HTML |
1 2 3 4 5 |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Adminbereich</title> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> |
Nach abspeichern in einer textarea wird das ö dazu: (im firefox son komisches Fragezeichen in einem oval)
|
|
Quellcode |
1 |
Hall�chen liebe Besucher |
Übergeben tu ich es so an die DB:
|
|
PHP-Quelltext |
1 |
utf8_decode($_POST['title'])
|
Er gibt mir das ö im Frontend auch aus:
|
|
Quellcode |
1 |
Hallöchen liebe Besucher |
Im Backend gebe ich die DB Inhalte direkt aus:
|
|
PHP-Quelltext |
1 |
$allcontents['content_title']
|
Im Frontend ebenfalls:
|
|
PHP-Quelltext |
1 |
$latestnews['title']
|
Im Frontend habe ich (natürlich!) alle Inhalte mit htmlentities() bestückt.. im Backend nicht..
Habe ich das htmlentities() nun entfernt, kommen ebenfalls diese Fragezeichen..
Heisst das nun ich muss htmlentities() ebenfalls im Backend verwenden, damit diese Fragezeichen verschwinden?!
|
Achtung: Dirk Kántor ist unterwegs! Er verteilt gerne Verwarnungen ohne vorher darüber diskutiert zu haben. |
versuch es mal mit htmlspecialchars das müsste eigentlich gehen weil htmlentites wandelt ja ö in ö und wenn ich mich net irre brauchste das ja bei utf8 gar net.
Edit:
Oder mal bei htmlentities mit dem 3 Parameter utf8 versuchen vlt. bringt dich das ja evtl. weiter
Edit:
Oder mal bei htmlentities mit dem 3 Parameter utf8 versuchen vlt. bringt dich das ja evtl. weiter
Seit 02.07.2010 Papa einer süssen Tocher !!!!
http://www.burnerfm.de
Mit den besten Hits der 80´s, 90´s und von heute. Plus einigen PHPKit Addons... uvm.
Mit den besten Hits der 80´s, 90´s und von heute. Plus einigen PHPKit Addons... uvm.
Das macht meine funktion eigentlich automatisch:
dennoch gehts nicht..
vielleicht ist das für Strings gedacht die nicht UTF8 konform sind?
ich muss schauen, denke ich werde es so machen das ich abfrage ob html drin ist im text oder nicht und wenn ja, soll man es ohne html schreiben
lol
das brauche ich auch nur für öffentliche dinge wie GB..
mal schauen wie ich vorankomme..
erstmal danke alle..
das einzigste problem was war, war das entitie der ausgabe.. das machte bei der speicherung mittels decode natürlich nix aus.. aber bei utf8 konforme strings, wars bockmist
|
|
PHP-Quelltext |
1 |
elseif($type=='html') return htmlentities($str,ENT_QUOTES,'UTF-8',FALSE);
|
dennoch gehts nicht..
vielleicht ist das für Strings gedacht die nicht UTF8 konform sind?
ich muss schauen, denke ich werde es so machen das ich abfrage ob html drin ist im text oder nicht und wenn ja, soll man es ohne html schreiben
loldas brauche ich auch nur für öffentliche dinge wie GB..
mal schauen wie ich vorankomme..

erstmal danke alle..
das einzigste problem was war, war das entitie der ausgabe.. das machte bei der speicherung mittels decode natürlich nix aus.. aber bei utf8 konforme strings, wars bockmist
|
Achtung: Dirk Kántor ist unterwegs! Er verteilt gerne Verwarnungen ohne vorher darüber diskutiert zu haben. |
ja und hast es mal mit htmlspecialchars versucht?
Seit 02.07.2010 Papa einer süssen Tocher !!!!
http://www.burnerfm.de
Mit den besten Hits der 80´s, 90´s und von heute. Plus einigen PHPKit Addons... uvm.
Mit den besten Hits der 80´s, 90´s und von heute. Plus einigen PHPKit Addons... uvm.

- 1
- 2



