zurück zur Startseite
  


Zurück XHTMLforum > Webentwicklung (außer XHTML und CSS) > Serveradministration und serverseitige Scripte
Seite neu laden Nachmal XHTML, PHP, MySQL und UTF-8

Antwort
 
LinkBack Themen-Optionen Ansicht
  #1 (permalink)  
Alt 29.08.2004, 21:37
Benutzer
neuer user
Thread-Ersteller
 
Registriert seit: 29.08.2004
Beiträge: 59
ollo befindet sich auf einem aufstrebenden Ast
Standard Nachmal XHTML, PHP, MySQL und UTF-8

Hallöchen miteinander!

Da hier in dem genannten Bereich ja scheinbar einiges an Erfahrung existiert. kann mir hier vielleicht jemand weiterhlefen...

Ich schreibe momentan ein CMS und dieses soll multilingual sein.

Das klappt durch ausgelagerte Locales auch ganz gut, nur ist mir leider recht spät eingefallen, dass es noch Zeichen außerhalb von Latin1 gibt...

Darum hab ich folgendes gemacht:
-> Alle Tabellen in MySQL umgestellt auch UTF-8 (die alten Einträge sind dadurch zwar fehlerhaft, ist aber vorerst egal
-> mbstring-Extension in PHP aktiviert, mbstring.internal_encoding auf UTF-8 gesetzt und str*-Funktionen überladen
-> Formulare angepasst so dass sie accept-charset="UTF-8" haben.
-> Seiten angepasst, dass als header content="text/html; charset=UTF-8" haben (sowohl im head-bereich als auch von PHP aus)

Dabei ist dann dieses herausgekommen:
- soweit ich das beurteilen kann, landen die Formulardaten korrekt als UTF-8 in der DB (Navicat zeigt für ein ü bspw. A mit Tilde und 1/4 Zeichen, der kann wohl kein UTF-8, schätze ich, jedenfalls werden üs aus alten Einträgen auch als ü gezeigt)
- bei der Augabe (ob über htmlentities() escaped oder nicht ist egal) bleiben allerdings die Zeichen so wie sie in der DB stehen, es wird also auch ein A mit Tilde und 1/4 Zeichen ausgegeben und ist im Browser sichtbar. (mit htmlentities() als $Atilde; ...) :-/

Was mache ich falsch?
Mit Zitat antworten
Sponsored Links
  #2 (permalink)  
Alt 30.08.2004, 00:54
Benutzerbild von toscho
Perplexifikator
XHTMLforum-Kenner
 
Registriert seit: 22.05.2004
Ort: Halle/Saale
Beiträge: 1.565
toscho sorgt für eine eindrucksvolle Atmosphäretoscho sorgt für eine eindrucksvolle Atmosphäre
Standard Re: Nachmal XHTML, PHP, MySQL und UTF-8

Mußte der neue Thread wirklich sein? Hätte so schön in den alten gepaßt!

Zitat:
Zitat von ollo
- bei der Augabe (ob über htmlentities() escaped oder nicht ist egal) bleiben allerdings die Zeichen so wie sie in der DB stehen, es wird also auch ein A mit Tilde und 1/4 Zeichen ausgegeben und ist im Browser sichtbar. (mit htmlentities() als $Atilde; ...) :-/

Was mache ich falsch?
Entweder gibst du die Seite doch nicht mit der Kodierung UTF-8 aus, oder du schreibst sie schon falsch in die DB. Gib mal eine URL.

Gruß
Thomas
Mit Zitat antworten
Sponsored Links
  #3 (permalink)  
Alt 30.08.2004, 03:15
Benutzer
neuer user
Thread-Ersteller
 
Registriert seit: 29.08.2004
Beiträge: 59
ollo befindet sich auf einem aufstrebenden Ast
Standard Re: Nachmal XHTML, PHP, MySQL und UTF-8

Zitat:
Zitat von toscho
Mußte der neue Thread wirklich sein? Hätte so schön in den alten gepaßt!
Jein, da ging es nicht um MySQL bzw. DBMS überhaupt, ist ja ne völlig andere Problematik... Und bevor ich OT poste, dachte ich starte lieber mal nen neuen... :)

Zitat:
Entweder gibst du die Seite doch nicht mit der Kodierung UTF-8 aus, oder du schreibst sie schon falsch in die DB. Gib mal eine URL.
Hab mal den Server mit dem neuesten Stand gefüttert: solidBrickz Demo

Die beiden oberen Einträge... äh, häh???? Leck die Katz!

Auf meinem Popel-Testserver funktionierts!!! Mist. ...äh ich mein super... =)

Fantastisch, also die beiden oberen Einträge zeigen normalerweise die Umlaute richtig an und der dritte den UTF-8 als ASCII. Hier ist's jetzt jedoch wie's sein soll, d.h. die ersten beiden sind unicodemäßig Müll und der Dritte wird vom Browser richtig dekodiert... grml...

Also werd ich nun erst mal checken, was die genauen Unterschiede in der PHP.ini sind (an der liegt's wahrscheinlich, die hab ich grad auf die schnelle für mbstring fertiggemacht), aber das mache ich nicht mehr heut.

Bin vom Museumsuferfest noch zu strulli und platt... 8-]

Ich meld mich wenn ich was genaueres weiß...
Mit Zitat antworten
  #4 (permalink)  
Alt 30.08.2004, 04:21
Benutzerbild von toscho
Perplexifikator
XHTMLforum-Kenner
 
Registriert seit: 22.05.2004
Ort: Halle/Saale
Beiträge: 1.565
toscho sorgt für eine eindrucksvolle Atmosphäretoscho sorgt für eine eindrucksvolle Atmosphäre
Standard Re: Nachmal XHTML, PHP, MySQL und UTF-8

Zitat:
Zitat von ollo
Hab mal den Server mit dem neuesten Stand gefüttert: solidBrickz Demo
Die sind in ISO-8859-1 kodiert. Da geht also beim Abspeichern was schief. Laß dir von deinem Script doch mal vor dem Eintrag in die DB probehalber eine Ausgabe dessen geben, was dann eingetragen wird.

Da ich gerade reingucke: Bitte gib deinen Stylesheets mediale Einschränkungen — media="screen,projection" — ein Handheldbrowser will die sicher nicht laden. ;)
Und »Cache-Control:no-store« ist für Leute mit wenig Arbeitsspeicher eine wahre Pest. Nicht machen.

Den Rest kommentiere ich lieber mal nicht. :)

Gruß
Thomas
Mit Zitat antworten
  #5 (permalink)  
Alt 30.08.2004, 19:01
Benutzer
neuer user
Thread-Ersteller
 
Registriert seit: 29.08.2004
Beiträge: 59
ollo befindet sich auf einem aufstrebenden Ast
Standard Re: Nochmal XHTML, PHP, MySQL und UTF-8

Zitat:
Die sind in ISO-8859-1 kodiert. Da geht also beim Abspeichern was schief. Laß dir von deinem Script doch mal vor dem Eintrag in die DB probehalber eine Ausgabe dessen geben, was dann eingetragen wird.
Na dann ist doch alles in Butter... Denn wie ich oben schrob, ist der dritte Eintrag der, der Unicode sein sollte, die oberen sind, wie du schon sagst, ISO-8859-1.

Prinzipiell funktioniert's also, es gibt aber immer noch ein Problem.
Wenn ich den obersten Abschnitt z.B. von dieser Seite eintrage, wandern 95% der Zeichen korrekt in die DB und wieder heraus, der Rest scheint kein Unicode mehr zu sein und wird durch das altbekannte Fragezeichen ersetzt bei der Ausgabe. Die Engaben werden für das Query mit mysql_real_escape_string() behandelt, das kann aber nicht der Verursacher sein.
Kurz gefasst, übliche (Latin) Unicodes funktionieren, Unicodes exotischer Sprachen funktionieren manchmal nicht.

Kennt jemand dieses Problem? Könnte es vielleicht mit dem Copy-Paste zusammenhängen? (Wobei, eigentlich nicht, der Text wird ja noch in der Textarea richtg angezeigt...)

Zitat:
Da ich gerade reingucke: Bitte gib deinen Stylesheets mediale Einschränkungen — media="screen,projection" — ein Handheldbrowser will die sicher nicht laden. ;)
Gute Idee, wollte ich ohnehin noch machen, hatte aber keine Prio.

Zitat:
Und »Cache-Control:no-store« ist für Leute mit wenig Arbeitsspeicher eine wahre Pest. Nicht machen.
Wohl eher für Leute mit viel Arbeitsspeicher und ner lahmen I-Net-Verbindung...
Wo kommt denn das mit? Als header? Dann muss es noch irgendwo in der Apache-Config drin sein, muss mal bei Gelegenheit schauen.
Wobei dynamische Seiten eigentlich sowieso nicht gecachet werden sollten, oder übersehe ich was?

Zitat:
Den Rest kommentiere ich lieber mal nicht. :)
Hihihihi. Ja mach das mal lieber nicht... :)
Welchen 'Rest' meinst Du?

Gruß, ()((()
Mit Zitat antworten
  #6 (permalink)  
Alt 30.08.2004, 19:51
Benutzerbild von toscho
Perplexifikator
XHTMLforum-Kenner
 
Registriert seit: 22.05.2004
Ort: Halle/Saale
Beiträge: 1.565
toscho sorgt für eine eindrucksvolle Atmosphäretoscho sorgt für eine eindrucksvolle Atmosphäre
Standard Re: Nochmal XHTML, PHP, MySQL und UTF-8

Zitat:
Zitat von ollo
Wenn ich den obersten Abschnitt z.B. von dieser Seite eintrage, wandern 95% der Zeichen korrekt in die DB und wieder heraus, der Rest scheint kein Unicode mehr zu sein und wird durch das altbekannte Fragezeichen ersetzt bei der Ausgabe.
Mit welchem Browser schickst du das ab? Manche Browser scheitern daran einfach, da kannst du serverseitig wenig machen.

Zitat:
Zitat:
Und »Cache-Control:no-store« ist für Leute mit wenig Arbeitsspeicher eine wahre Pest. Nicht machen.
Wohl eher für Leute mit viel Arbeitsspeicher und ner lahmen I-Net-Verbindung...
Nein, »no-store« bedeutet, daß das Dokument auch kurzfristig nicht auf der Patte abgelegt werden darf und somit permanent im RAM bleibt, auch wenn der Leser vielleicht gerade diese Seite gar nicht im Vordergrund hat. Als ich früher noch mit 64MB RAM auskommen mußte, habe ich »no-store« extra mit einem Proxy ausfiltern müssen; anders wäre ein vernünftiges Arbeiten unmöglich gewesen.

Zitat:
Wobei dynamische Seiten eigentlich sowieso nicht gecachet werden sollten, oder übersehe ich was?
Warum nicht? Wenn du »revalidate« verlangst, ist doch alles in Butter: Wenn sich nichts geändert hat, kannst du 304 schicken und der Browser seine Kopie aus dem Cache nehmen.

Zitat:
Welchen 'Rest' meinst Du?
Ahem. Dein angestaubtes Markup. Mensch, 1998 ist schon lange vorbei! ;)

Gruß
Thomas
Mit Zitat antworten
  #7 (permalink)  
Alt 30.08.2004, 22:53
Benutzer
neuer user
Thread-Ersteller
 
Registriert seit: 29.08.2004
Beiträge: 59
ollo befindet sich auf einem aufstrebenden Ast
Standard Re: Nochmal XHTML, PHP, MySQL und UTF-8

Zitat:
Zitat von toscho
Mit welchem Browser schickst du das ab? Manche Browser scheitern daran einfach, da kannst du serverseitig wenig machen.
Mit Firefox... Wenn der das schon nicht packt, was soll dann erst der IE machen? =)

Aber sonst fällt Dir auf Anhieb auch keine andere Fehlerquelle ein?

Ich hab grad mal das Verhalten beim Explorer gecheckt, und das Problem scheint (wenn überhaupt) serverseitig zu sein. 'Wenn überhaupt' deshalb, weil der IE bei der Ausgabe mehr Zeichen richtig darstellt als Firefox. von dem erwähnten 1. Absatz wird nur ein Zeichen als Rechteck angezeigt, bei FF sind's cs. 20 Fragezeichen.

Die Frage ist bloß, was soll ich jetzt daraus schließen?

Zitat:
Nein, »no-store« bedeutet, daß das Dokument auch kurzfristig nicht auf der Patte abgelegt werden darf und somit permanent im RAM bleibt, auch wenn der Leser vielleicht gerade diese Seite gar nicht im Vordergrund hat. Als ich früher noch mit 64MB RAM auskommen mußte, habe ich »no-store« extra mit einem Proxy ausfiltern müssen; anders wäre ein vernünftiges Arbeiten unmöglich gewesen.
Ups. Ich dachte eigentlich das läge im Bereich des OS.

Zitat:
Zitat:
Wobei dynamische Seiten eigentlich sowieso nicht gecachet werden sollten, oder übersehe ich was?
Warum nicht? Wenn du »revalidate« verlangst, ist doch alles in Butter: Wenn sich nichts geändert hat, kannst du 304 schicken und der Browser seine Kopie aus dem Cache nehmen.
So, hab mich mal ein bischen kundig gemacht und werde folgende Direktiven senden:

header('Cache-control: private');
header('Cache-control: must-revalidate');
header('Cache-control: max-age=0');
header('Pragma: no-cache');

Hab's aber nur kurz überflogen, ist das so sinnvoll?

Zitat:
Ahem. Dein angestaubtes Markup. Mensch, 1998 ist schon lange vorbei! ;)
Hehe, hast ja Recht. Ich nehme an Du meinst meine verschachtelten Tabellenkonstrukte, die gefallen mir auch nicht... =)

Aber ich möchte, dass die Seite auch auf älteren Browsern einigermaßen ordentlich angezeigt wird. Außerdem kann man eben auch nicht alles über CSS lösen, um Tabellen kommt man manchmal nicht herum.

Allerdings gibt's auch nicht soviel was man ändern und über CSS abwickeln könnte. Falls Dir bspw. eine bessere Lösung für die Tabellen mit abgerundeten Ecken einfällt, immer her damit.

Ich bin für konstruktive Kritik immer zu haben, Betonung auf 'konstruktive'... :)
Mit Zitat antworten
  #8 (permalink)  
Alt 30.08.2004, 23:53
Benutzerbild von toscho
Perplexifikator
XHTMLforum-Kenner
 
Registriert seit: 22.05.2004
Ort: Halle/Saale
Beiträge: 1.565
toscho sorgt für eine eindrucksvolle Atmosphäretoscho sorgt für eine eindrucksvolle Atmosphäre
Standard Re: Nochmal XHTML, PHP, MySQL und UTF-8

Zitat:
Zitat von ollo
Aber sonst fällt Dir auf Anhieb auch keine andere Fehlerquelle ein?
Hm, nein. Hast du mal die Ausgabe vor dem Eintrag probiert?

Zitat:
Ich hab grad mal das Verhalten beim Explorer gecheckt, und das Problem scheint (wenn überhaupt) serverseitig zu sein. 'Wenn überhaupt' deshalb, weil der IE bei der Ausgabe mehr Zeichen richtig darstellt als Firefox.
Hat nichts zu sagen; der IE ignoriert im Zweifelsfall die angegebene Kodierung und rät sich was zurecht.

Zitat:
So, hab mich mal ein bischen kundig gemacht und werde folgende Direktiven senden:

header('Cache-control: private');
header('Cache-control: must-revalidate');
header('Cache-control: max-age=0');
header('Pragma: no-cache');
Du brauchst »Cache-control« nicht dreimal absenden; die Werte können alle hintereinander stehen, durch Kommata getrennt natürlich.

Zitat:
Hab's aber nur kurz überflogen, ist das so sinnvoll?
Ja, scheint so.

Zitat:
Ich nehme an Du meinst meine verschachtelten Tabellenkonstrukte, die gefallen mir auch nicht... =)

Aber ich möchte, dass die Seite auch auf älteren Browsern einigermaßen ordentlich angezeigt wird.
Warum? Mit sauberem Markup und ohne CSS bekommen die doch hübsch übersichtliche Seiten.

Zitat:
Falls Dir bspw. eine bessere Lösung für die Tabellen mit abgerundeten Ecken einfällt, immer her damit.
Es geht, braucht aber einiges an Tests und ziemliche Eingriffe ins Markup. Oder es funktioniert nur in Opera. ;)

Gruß
Thomas
Mit Zitat antworten
  #9 (permalink)  
Alt 31.08.2004, 03:26
Benutzer
neuer user
Thread-Ersteller
 
Registriert seit: 29.08.2004
Beiträge: 59
ollo befindet sich auf einem aufstrebenden Ast
Standard Re: Nochmal XHTML, PHP, MySQL und UTF-8

Zitat:
Zitat von toscho
Hm, nein. Hast du mal die Ausgabe vor dem Eintrag probiert?
Bin grade dabei so einiges auszutesten...
Wenn ich den String, wie er an die DB geht, ausgebe siehts noch normal aus, müsste folglich an der Übertragung hängen...

Jetzt habe ich den Charset auch für die Verbindung und alles mögliche mal auf UTF8 ungestellt, das macht alles nur schlimmer. Dann kommen die Results scheinbar als die UTF8-Kodierung des als ISO-8... interpretierten Tabelleninhalts an... lol =)

Also ein ü, das als ATilde mit 1/4tel in der DB steht (wenn man es als ISO interpretiert), kommt dann als ATilde mit 1/4tel in Unicode aus der DB... :-/

Ich werd mir jetzt wohl mal 'professionelle' Hilfe bei MySQL holen müssen.

Zitat:
Hat nichts zu sagen; der IE ignoriert im Zweifelsfall die angegebene Kodierung und rät sich was zurecht.
Ja, mir ist aufgefallen dass er Zeichen, die im normalen XHTML Text stehen korrekt anzeigt und die gleichen Zeichen in einer Textarea als Rechteck.

Mal wieder: Danke Microsoft!

Zitat:
Zitat:
So, hab mich mal ein bischen kundig gemacht und werde folgende Direktiven senden:

header('Cache-control: private');
header('Cache-control: must-revalidate');
header('Cache-control: max-age=0');
header('Pragma: no-cache');
Du brauchst »Cache-control« nicht dreimal absenden; die Werte können alle hintereinander stehen, durch Kommata getrennt natürlich.
jetzt ist's richtig: =)
header('Cache-control: private, must-revalidate, max-age=0');

Wie checkst Du eigentlich die Header? Hast Du da ein extra Tool für oder schaust Du Dir den gecaptureten Stream an?

Zitat:
Warum? Mit sauberem Markup und ohne CSS bekommen die doch hübsch übersichtliche Seiten.
übersichtlich: Ja.
hübsch: nein.

Also nur Inhalt und keine Präsentation ist nicht besonders ansprechend, was bei einem Medium, wo das Auftreten (beim ersten Blick) wichtiger ist als der Inhalt, fatal sein kann.
Auf lange Sicht ist selbstverfreilich der Content das tragende Element.

Zitat:
Zitat:
Falls Dir bspw. eine bessere Lösung für die Tabellen mit abgerundeten Ecken einfällt, immer her damit.
Es geht, braucht aber einiges an Tests und ziemliche Eingriffe ins Markup. Oder es funktioniert nur in Opera.
Ebend...

gerade in Bereichen, wo es auf pixelgenaue Positionierung ankommt, hat CSS oder besser dessen Implementierung der versch. Browser noch ziemliche Nachteile. Wenn ich nur dran denke was da schon alles lustiges gesehen hab.

BTW, der Administrationsbereich nutzt auch keine Frames, aber über position: fixed; eine Emulation derselben. Leider kennt unser lieber Marktführer diese Methode noch nicht. War eine Heidenarbeit das so hinzubekommen, dass es in IE und FF vernünftig aussieht. Ist markupmäßig durch 0 Pixel breite Bilder auch ähm... suboptimal... =)

Wird Zeit dass wir 2010 haben und man CSS und andere Standards konsequent nutzen kann...
IE kann nicht mal PNGs richtig darstellen. :-/
Mit Zitat antworten
Sponsored Links
  #10 (permalink)  
Alt 31.08.2004, 06:16
Benutzerbild von toscho
Perplexifikator
XHTMLforum-Kenner
 
Registriert seit: 22.05.2004
Ort: Halle/Saale
Beiträge: 1.565
toscho sorgt für eine eindrucksvolle Atmosphäretoscho sorgt für eine eindrucksvolle Atmosphäre
Standard Re: Nochmal XHTML, PHP, MySQL und UTF-8

Zitat:
Zitat von ollo
Ja, mir ist aufgefallen dass er Zeichen, die im normalen XHTML Text stehen korrekt anzeigt und die gleichen Zeichen in einer Textarea als Rechteck.
Es kann passieren, daß dein Text in der Zwischenablage klammheimlich in ANSI ungewandelt wird, der IE wandelt das dann nicht unbedingt in die richtige Kodierung der Webseite um.
Was für eine Windowsversion benutzt du? Hast du die Erweiterung für asiatische Sprachen installiert? Die braucht der IE sowieso an jeder Ecke, auch wenn man gar nichts mit asiatischen Sprachen zu tun hat…

Zitat:
Wie checkst Du eigentlich die Header?
http://web-sniffer.net/
Ich habe im Kontextmenü (Opera) diesen Eintrag:
Code:
Item, "WebSniffer"="Go to page, "http://web-sniffer.net/?url=%u""
Sehr praktisch. :)

Zitat:
Also nur Inhalt und keine Präsentation ist nicht besonders ansprechend, was bei einem Medium, wo das Auftreten (beim ersten Blick) wichtiger ist als der Inhalt, fatal sein kann.
Ich bin Minimalist: Alles, was vom Inhalt ablenken könnte, muß weg. Und damit fahre ich ziemlich gut.
Den meisten ist die Präsentation egal, solange die Inhalte übersichtlich und gut lesbar sind und schnell geladen werden. Dazu braucht man nicht unbedingt ein Stylesheet.

Zitat:
gerade in Bereichen, wo es auf pixelgenaue Positionierung ankommt, hat CSS oder besser dessen Implementierung der versch. Browser noch ziemliche Nachteile.
Obwohl ich selbst schon solche Layouts entwickelt habe, muß ich sagen: Sobald es bei einem Layout auf pixelgenaues Positionieren ankommt, steckt der Wurm nicht in den Browsern, sondern im Layout.

Zitat:
BTW, der Administrationsbereich nutzt auch keine Frames, aber über position: fixed; eine Emulation derselben. Leider kennt unser lieber Marktführer diese Methode noch nicht.
»position:fixed« hat auch in den Browsern, die es können, so viele Nachteile, daß ich einigermaßen froh darüber bin, daß es so selten eingesetzt wird.

Zitat:
IE kann nicht mal PNGs richtig darstellen. :-/
Das ist allerdings Mist. Selbst wenn er es könnte: Die Accessibility-Farbschemata in Windows erfassen keine Bilder. Transparenz birgt deshalb selbst bei GIFs einige oft übersehene Zugänglichkeitsprobleme, zumindest wenn ein Bild Text enthält.

Gruß
Thomas
Mit Zitat antworten
Sponsored Links
Antwort

Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus


Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Wo kann man am besten PHP und MySQL lernen? papalapap Ressourcen 10 11.12.2013 17:56
html 4.01 >> XHTML tupamaro (X)HTML 9 30.09.2012 20:32
Dateien auslagern - Include und PHP ArcVieh Serveradministration und serverseitige Scripte 17 27.03.2008 19:09
Buchempfehlung für PHP und MySQL Einstieg Crizzo Ressourcen 4 04.08.2007 20:57
Xhtml und PHP weightwatcher (X)HTML 11 22.03.2005 21:29


Alle Zeitangaben in WEZ +2. Es ist jetzt 00:01 Uhr.