[PHP] Header mit charset erzeugt komische Zeichen am Seitenanfang

[mr. mo (Gast)]

Hey Leute,
damit alles mit den Sonderzeichen zwischen Seite und Datenbank klappt, 
habe ich am Anfang der Seite ein:

header('Content-type: text/html; charset=ISO-8859-1');

eingefügt.

Jedoch gibt dieser Abschnitt am Anfang der Seite ein  aus. Es steht 
also noch über der [html] Answeisung.

Woher kommt das? In den Meta-Tags ist noch ein

<meta charset="utf-8">

verbaut. Dies zu löschen oder zu ändern bringt aber keine Änderung.

Wenn ich den PHP-Code Abschnitt raus nehme werden aber die Sonderzeichen 
nicht richtig dargestellt (also üäö usw.).

[Stryker (Gast)]

Versuch einmal die Datei als UTF8 ohne BOM zu speichern (Notepad++ kann 
dies z.B.).

[Stryker again (Gast)]

> header('Content-type: text/html; charset=ISO-8859-1');

möchtest du das nicht vielleicht auch zu UTF-8 ändern?

[mr. mo (Gast)]

Stryker again schrieb:
>> header('Content-type: text/html; charset=ISO-8859-1');
>
> möchtest du das nicht vielleicht auch zu UTF-8 ändern?

omg. hätte ich auch selber drauf kommen können :D

[mr. mo (Gast)]

Ich nehms zurück. Die Zeichen am Anfang sind weg, aber meine 
Sonderzeichen auf der Seite sind wieder Fragezeichen im Kasten....

[Stryker again (Gast)]

Alle Dateien sind UTF8 ohne BOM?
Die Zeichen in der DB sind in der utf8_general_ci oder äquivalenten 
Kollation? Zur not zwinge die DB explizit dir es als UTF8 weiterzugeben.

[Martin M. (kaktus621)]

Die Zeichen am Anfang entstehen, wie bereits von Stryker erwähnt, durch 
die Byte Order Mark. Wenn du später mit PHP sessions arbeiten möchtest, 
würde ich die Zeichen entfernen (auch wenn unsichtbar). Dies kann man 
(wie ebenfalls von Stryker erwähnt) z.B. mittels Notepad++ erledigen.

Ansonsten wirst du später keine neue Session starten können, da dies 
geschehen muss, bevor jeglicher Content ausgegeben wird (und die BOM 
zählt als Content).


Was die Sonderzeichen angeht: geschieht auch die Kommunikation zur 
Datenbank in UTF-8? Probier mal, den Kommunikationszeichensatz mit Hilfe 
von

http://php.net/manual/en/mysqli.set-charset.php

einzustellen. Sobald sowohl Kommunikation als auch Seite in UTF-8 sind, 
sollten Sonderzeichenprobleme eigentlich der Vergangenheit angehören.

[Läubi .. (laeubi)]

Stryker again schrieb:
> Alle Dateien sind UTF8 ohne BOM?
> Die Zeichen in der DB sind in der utf8_general_ci oder äquivalenten
> Kollation? Zur not zwinge die DB explizit dir es als UTF8 weiterzugeben.

Alle Optionen haben überhauptnix mit der DB zu tun, der ist das völlig 
wurscht. Auch der Zeichensatz der DB interessiert (erstmal) nicht 
solange dieser alle Sonderzeichen abdecken kann, viel wichtiger ist:

Martin Matysiak schrieb:
> Sobald sowohl Kommunikation als auch Seite in UTF-8 sind,
> sollten Sonderzeichenprobleme eigentlich der Vergangenheit angehören

Dann sollte man sich aber einig sein ob man UTF-8 oder ISO/Latin/... 
haben will und bedenken das ggf. schon falsche Zeichen in der DB stehen 
als ggf. einmal mit einem leeren Schema neu beginnen.

[D. I. (Gast)]

Man sollte einfach direkt am Anfang gleich alles in UTF-8 machen.

Das heißt:

- .php Dateien in UTF-8 ohne BOM speichern
- Datenbank Kollation auf ut8_general_ci oder ähnliches stellen
- charset in der html datei auf utf-8 stellen
- nach verbindung zur datenbank die sql anweisung "SET NAMES UTF-8" oder 
so ähnlich ausführen (google)

erst nachdem ich das alles gemacht hatte war alles wirklich utf-8.

Seit ich auf rails umgestiegen bin war nur noch punkt 1 wichtig, alles 
andere war default ;)

[mr. mo (Gast)]

hab das projekt ja aufm usb stick mit xampp portable usw. und ich 
vermute ja, dass der der editor scriptly da irgendwas an den dateien 
gemacht hat. schon alleine das es mich gefragt hat wie die datei 
geöffnet werden soll.

mache gerade mal notepad++ drauf und werde den tipps mal nachgehen. an 
der datenbank liegt es nicht mit den sonderzeichen. wenn man nachschaut 
sind alle sonderzeichen richtig abgespeichert.

[D. I. (Gast)]

aja wenn du mit utf-8 zeug in php hantierst, solltest du bei stirng 
funktionen auch darauf achten die multi-byte versionen zu verwenden.

Also mb_strlen statt strlen und ähnliches

[mr. mo (Gast)]

D. I. schrieb:
> aja wenn du mit utf-8 zeug in php hantierst, solltest du bei stirng
> funktionen auch darauf achten die multi-byte versionen zu verwenden.
>
> Also mb_strlen statt strlen und ähnliches

ja ich merke schon das mit utf-8 alles ein wenig anders ist. spontan 
hätte ich dort auch die grundvarianten benutzt.


habe jetzt mal alles ohne BOM abgespeichert. es ist nur eins von den 
zeichen verschwunden.
als ich nach dem SET NAME gegoogelt hab, habe ich einen gefunden der 
genau das problem hat wie ich. die gleichen mysql einstellungen. dort 
wurde ihm aber geholfen in dem er mysql auf utf-8 gestellt hat. werde 
den schritten mal nachgehen und wieder berichten.

hier ist nochmal der link:
http://www.php.de/datenbanken/45586-utf-8-nur-mit-set-names.html

[D. I. (Gast)]

richtig diesen befehl musst du immer als erstes ausführen nachdem eine 
verbindung hergestellt wurde.

Vielleicht möchtest du auch einen Blick auf Ruby on Rails werfen, da hat 
man dieses gschieß nicht ;)

[mr. mo (Gast)]

hab jetzt vor jedem datenbank auslesen das

mysql_query("SET NAMES 'utf8'");

eingefügt. löst auf jeden fall das problem, aber ist das echt die 
methode um mit utf8 zu arbeiten?

gibt es da nicht noch eine alternative die man kurz nach dem verbinden 
zur datenbank einfügen kann? also nur einmal und nicht mehr mals?

[Peter II (Gast)]

mr. mo schrieb:
> SET NAMES

seit ihr euch sicher was ihr macht? Ich lese die doku so das man damit 
umstellt in welchen Format man die SQL-anweisungen schreibt. Du kannst 
also damit Tabellen und Spalten namen mit UTF8 verwenden - will man das 
überhaupt? Es sollte aber keine Einfluss auf die Daten selber haben.

Ich halte von UTF8 eh wenig, die datenbanken werden dadurch langsamer 
weil die index zugriffe nicht mehr so effizent sind. Dann hat man das 
Problem das umlaute anders condiert sein können. ein ö gibt es mehrfach 
in UTF8 - wie soll man es dann wieder finden?

Das der Browser UTF8 bekommt ist ja ok, aber in der Datenbank konnte ich 
es bis jetzt immer vermeiden und hatte noch die Probleme mit umlauten.

[Läubi .. (laeubi)]

Wenn du mysqli verwendest kannst du einfach:
$db->set_charset("uft-8")
schreiben ($db = deine mysqlidb Verbindung)

Peter II schrieb:
> Das der Browser UTF8 bekommt ist ja ok, aber in der Datenbank konnte ich
> es bis jetzt immer vermeiden und hatte noch die Probleme mit umlauten.

Wie gesagt geht es hier darum wie es am "anderem Ende" rauskommt in der 
DB ist nochmal eine andere Baustelle...

[mr. mo (Gast)]

Peter II schrieb:
> Ich halte von UTF8 eh wenig, die datenbanken werden dadurch langsamer
> weil die index zugriffe nicht mehr so effizent sind.

ich will ja kein forum oder ähnlich großes projekt bauen, daher ist mir 
das nicht ganz so wichtig.
gehst du dabei von der einstellung der tabellen in der mysql datenbank 
aus?
die stehen derzeit auf utf8-general-ci vorher war das die latin 
irgendwas.

ich bin mir eh nicht so sicher warum ich überhaupt UTF8 benutze, anlass 
war nur das ich auf HTML5 umgestiegen bin und dies als meta im head 
verbaut ist und ich wohl dadurch darstellungsprobleme bekommen habe.

aber scheint nicht UTF8 irgendwie standart zu werden? sorry für die 
doofen fragen, arbeite mich gerade erst wieder in die materie ein. habe 
vor langer zeit mit php4 gearbeitet und muss mich an paar neuerungen 
erstmal gewöhnen.

[Läubi .. (laeubi)]

mr. mo schrieb:
> und dies als meta im head
> verbaut ist

Im Header darf auch ein anderes Charset stehen es sollten nur die 
Charsets übereinstimmen.

[D. I. (Gast)]

Ja in der heutigen Zeit baut man webzeug mit utf-8, dann kann auf dieses 
ganze ä Gerümpel im html code verzichten.

[mr. mo (Gast)]

D. I. schrieb:
> Ja in der heutigen Zeit baut man webzeug mit utf-8, dann kann auf dieses
> ganze ä Gerümpel im html code verzichten.

das ist mir sogar positiv aufgefallen ^^

[Peter II (Gast)]

D. I. schrieb:
> Ja in der heutigen Zeit baut man webzeug mit utf-8, dann kann auf dieses
> ganze ä Gerümpel im html code verzichten.

das ist auch auch gut so, aber das hat wenig mit der Datenbank zu tun. 
Die Datenbank kann immer noch anders sein.

[D. I. (Gast)]

das kann sie aber warum sollte man das wollen? das bisschen 
mikrosekunden sparen bei einem indizierten string zugriff?

[Peter II (Gast)]

D. I. schrieb:
> das bisschen mikrosekunden sparen bei einem indizierten string zugriff?
naja bei 10Gb datenbanken geht es leider nicht nur um ein paar 
mikrosekunden.

[D. I. (Gast)]

Da stellt sich erstens die Frage, welcher Privatnutzer auf solche 
Datenmengen kommt. Zweitens ist indizierte Zugriff auf String immer 
erstmal zu hinterfragen ob mans nicht doch mit Integern hinbekommt und 
dann erst irgendwann würde ich mir um dieses Problem Gedanken machen.

Im vorliegenden und vielen anderen Fällen tut es der wartbarkeit des 
Programms und der entwicklungsgeschwindigkeit erstmal keinen Abbruch 
komplett auf UTF-8 zu setzen...

[Andy (Gast)]

Hi an alle,

hatte genau das gleiche Problem das Fragezeichen mit Kasten angezeigt 
wurden. Es lag am Dreamviwer und an CuteFTP Editor.

Vielen dank an "Stryker" ganz oben im Beitrag. Hat mir sehr geholfen und 
ich konnte mein Problem lösen.

Notepad++ installieren
Notepad++ öffnen
Datei die Probleme macht öffnen (bei mir was es eine lang Datei)
Kodierung >>> UTF-8 ohne BOM wählen
Datei speichern
hochladen

Und siehe da alles funktioniert wieder, ausser Ihr habt an der Datei 
schon mehrfach etwas geändert mit einem Editor der falsch codiert hat. 
Dies müsst ihr dann einfach mit suchen und ersetzten im Notepadd++ 
abändern. Dann speichern und hochladen.

Also nochmal vielen Dank an alle!