nicht angemeldet
Griechisch und Unicode / Einen hab ich noch ...
Einen wunderschönen verregneten guten Morgen Forum,
vor einigen Tagen las ich auf der mysql home, dass UTF-8 erst ab der Version 4.1 unterstützt wird.
Wenn ich nun aber Griechisch aus einer Word Datei kopiere und dieses in phpmyadmin einfüge, wird dieses konvertiert und in hex Zeichen abgespeichert.
Auf meinem Rechner ist aber mySQL 4.0.20 installiert. Kann man dort nun Unicode abspeichern oder nicht.
Das ist wirklich die letzte Frage(hoffe ich sehr), dann nerve ich mit diesem Thema nicht mehr. ;)
-
Moin!
vor einigen Tagen las ich auf der mysql home, dass UTF-8 erst ab der Version 4.1 unterstützt wird.
Wenn ich nun aber Griechisch aus einer Word Datei kopiere und dieses in phpmyadmin einfüge, wird dieses konvertiert und in hex Zeichen abgespeichert.
Definiere "Hex-Zeichen"?
UTF-8 ist eine Codierung, die durchaus ASCII-kompatibel ist. Du kannst also im Prinzip ohne Probleme UTF-8-Strings in die Datenbank tun und auch wieder herauslesen. Knackpunkte sind ein paar Details.
Ein VARCHAR(10) für maximal 10 Zeichen nimmt beispielsweise 10 normale ASCII-Zeichen auf - wenn UTF-8-codierte Umlaute auftauchen, passen davon aber nur 5 hinein, da jeder Umlaut aus 2 Zeichen besteht. MySQL 4.1 hingegen berücksichtigt diese Problematik und legt das Feld im Zweifel etwas länger an.Wenn du aber (was sinnvoll erscheint) TEXT oder BLOB als Spaltentyp für deinen Text nutzt, stört das relativ wenig.
Bleibt das Problem der HEX-Zeichen. Das liegt eindeutig an der Schnittstelle zur Datenbank.
Die einzelnen Browser verhalten sich leider höchst ekelhaft, wenn das Formular nicht mit 'accept-charset="utf-8"' arbeitet. Idealerweise sollte schon die Formularseite als UTF-8 ausgeliefert werden. Wenn das Formular mit den Texten als ISO-8859-1 verschickt wird, gibts Chaos. Einige Browser wandeln nicht codierbare Zeichen (bei dir also alles griechische) in Fragezeichen um und schicken den Text dann so. Andere Browser wandeln diese Zeichen in numerische Entities um (Ӓ), codieren eingegebene &-Zeichen aber nicht als & - man kann also nicht mehr ermitteln, ob der Benutzer ein Sonderzeichen eingab, oder in seinem Text die Entity ausgeben wollte.
- Sven Rautenberg
-
Hallo Sven Rautenberg,
Definiere "Hex-Zeichen"?
Na ja, nachdem ich mit phpmyadmin hinzugefügt habe. Stehen anstatt der griechischen - solche Zeichen in der DB: Ӓ, etc.
MySQL 4.1 hingegen berücksichtigt diese Problematik und legt das Feld im Zweifel etwas länger an. Wenn du aber (was sinnvoll erscheint) TEXT oder BLOB als Spaltentyp für deinen Text nutzt, stört das relativ wenig.
Aha. So ist das also gemeint. Dann benutze ich halt für alle Felder den Typ "text". Was ich schon immer wissen wollte und nie verstanden habe ist: Wozu ist das Feld "blob"?
Die einzelnen Browser verhalten sich leider höchst ekelhaft, wenn das Formular nicht mit 'accept-charset="utf-8"' arbeitet.
Wo stellt man das denn ein ? Weißt Du vielleich wie man das bei phpmyadmin ändern kann?
Idealerweise sollte schon die Formularseite als UTF-8 ausgeliefert werden. Wenn das Formular mit den Texten als ISO-8859-1 verschickt wird, gibts Chaos. Einige Browser wandeln nicht codierbare Zeichen (bei dir also alles griechische) in Fragezeichen um und schicken den Text dann so.
Nein, nein. Der wandelt den Text nicht in Fragezeichen um, es bleibt griechisch, wenn ich es in ein "text"-Feld bei phpmyadmin einfüge. Wenn ich aber dann auf "OK" klicke und die Tabelle browser, dann habe ich halt nur solche numerischen entities in der Tabelle. Ist das Unicode ? Habe es nämlich noch nicht mittels php wieder aus der DB herausgeholt und in einer html Seite dargestellt.
-
Hallo nochmal,
warum wird das Unicode copyright Zeichen nin nicht angezeigt?
Aus Latin-1 Supplement http://www.unicode.org/charts/ sehe ich in der Tabelle, dass das Copyright Zeichen © ist, oder?
Die Seite ist nun UTF-8 kodiert und alles sieht gut aus.
Jetzt geht das Copyright Zeichen nicht mehr: © zeichnet ein blaues Viereck mit einem Fragezeichen drin.PS: Mozilla 1.71 /Win 2000
-
Moin!
Die Seite ist nun UTF-8 kodiert und alles sieht gut aus.
Jetzt geht das Copyright Zeichen nicht mehr: © zeichnet ein blaues Viereck mit einem Fragezeichen drin.Entweder verwendest du die Entity © - das ist schlauer, weil es auch jeder versteht, der den Quelltext lesen kann. Oder du codierst dein Copyright-Zeichen als echtes UTF-8-Zeichen (das sind dann zwei Bytes) im Text - die Entity ist absolut unnötig dafür.
Warum sie trotzdem nicht funktioniert, kann immer noch am verwendeten Font liegen, der vielleicht für dieses Zeichen einfach nichts darstellbares zu bieten hat.
- Sven Rautenberg
-
Hallo Sven,
als erstes nochmals ein großes Lob an Dich. Finde es toll, wie Du hartnäckig versuchst durch ausführliche Erläuterungen anderen zu helfen. Bemerkenswert und auch gut für Deutschland.
Entweder verwendest du die Entity © - das ist schlauer, weil es auch jeder versteht, der den Quelltext lesen kann. Oder du codierst dein Copyright-Zeichen als echtes UTF-8-Zeichen (das sind dann zwei Bytes) im Text - die Entity ist absolut unnötig dafür.
Aha, Du meinst also direkt als lesbares copyright Zeichen im Quelltext? Woher aber nehmen, wenn nicht stehlen ? Auf meiner Tastatur ist kein Copyright Zeichen vorhanden.
Warum sie trotzdem nicht funktioniert, kann immer noch am verwendeten Font liegen, der vielleicht für dieses Zeichen einfach nichts darstellbares zu bieten hat.
Ich benzute:
font-family: Verdana, Arial, Helvetica, Geneva, sans-serif;
Woher weiß man aber welcher Font ein Unicode Zeichen darstellen kann?
Gibt es da irgendwo eine Übersicht ? Dann kann man ja niemals entspannt eine HTML Seite in Unicode erstellen und ausgefallene Zeichen benutzen!Danke
-
Moin!
Entweder verwendest du die Entity © - das ist schlauer, weil es auch jeder versteht, der den Quelltext lesen kann. Oder du codierst dein Copyright-Zeichen als echtes UTF-8-Zeichen (das sind dann zwei Bytes) im Text - die Entity ist absolut unnötig dafür.
Aha, Du meinst also direkt als lesbares copyright Zeichen im Quelltext? Woher aber nehmen, wenn nicht stehlen ? Auf meiner Tastatur ist kein Copyright Zeichen vorhanden.
Wenn du deine ALT-Taste gedrück hälst und "0" plus dem dezimalen Unicode des gewünschten Zeichens tippst, dann erscheint dieses nach Loslassen der ALT-Taste.
Das Copyright-Zeichen "©" erscheint bei mir also durch ALT + "0169" auf dem Nummernblock.
Warum sie trotzdem nicht funktioniert, kann immer noch am verwendeten Font liegen, der vielleicht für dieses Zeichen einfach nichts darstellbares zu bieten hat.
Ich benzute:
font-family: Verdana, Arial, Helvetica, Geneva, sans-serif;
Woher weiß man aber welcher Font ein Unicode Zeichen darstellen kann?
Gibt es da irgendwo eine Übersicht ? Dann kann man ja niemals entspannt eine HTML Seite in Unicode erstellen und ausgefallene Zeichen benutzen!http://www.alanwood.net/unicode/fonts.html
Da gibts zum einen viele Infos über existierende Zeichensätze und deren Unicode-Fähigkeit, zum anderen einen Link auf http://www.microsoft.com/typography/property/property.htm, unter dem man sich eine Erweiterung für Windows herunterladen kann und dann bei Schriftarten künftig ganz viele erweiterte Informationen in den Eigenschaften sieht - unter anderem deren Abdeckung von Unicode-Schriftarten.
Zu Verdana steht dort u.a.:
Verdana 893 glyphs in version 2.35
Ranges: Basic Latin; Latin-1 Supplement; Latin Extended-A; Greek; Cyrillic; Latin Extended Additional- Sven Rautenberg
-
Hallo,
Wenn du deine ALT-Taste gedrück hälst und "0" plus dem dezimalen Unicode des gewünschten Zeichens tippst, dann erscheint dieses nach Loslassen der ALT-Taste.
Unfassbar. Beschäftige mich nun mittlerweile seit 10 Jahren mehr oder weniger mit Rechnern. Denkst Du, dass wusste ich ? Wahnsinn. Man lernt nie aus. Sag mal weißt du eigentlich _Alles_ ? Unglaublich.
Das Copyright-Zeichen "©" erscheint bei mir also durch ALT + "0169" auf dem Nummernblock.
Bei mir auch. Herrlich. :) Aber wie kommst Du auf 0169 ? Ich aheb auf Unicode.org in der Latin1-supplement. Für das Copyright Zeichen �a9 gefunden. Allerdings klappt es nicht. Wenn ich im Quelltext in Dreamweaver an der benötigten Stelle "ALT 0169" tippe und loslasse, aheb ich zwar ein schönes Copyright Zeichen im Quelltext, aber wenn ich mir die eigentliche html Seite anzeigen lasse erscheint an der Stelle wieder nur ein blauen Quadrat mit einem Fragezeichen drin.
Was allerdings klappt ist, wenn ich im Unicode Editor unipad ein copyright Zeichen eingebe und es als UTF-8 kopiere,in den Dreamweaver Quelltext paste, dann pastet der nicht nur ein copyright Zeichen sondern ein großes A mit einem Dreieck über dem A. Diese beiden Zeichen zusammen werden dann in der eigentlichen html Seite dann zum Copyright Zeichen.
Das ist alles merkwürdig.
-
Moin!
Unfassbar. Beschäftige mich nun mittlerweile seit 10 Jahren mehr oder weniger mit Rechnern. Denkst Du, dass wusste ich ? Wahnsinn. Man lernt nie aus. Sag mal weißt du eigentlich _Alles_ ? Unglaublich.
Nein, ich weiß definitiv nicht alles. Ich erscheine dir nur gerade so schlau, weil deine Wissenslücken von mir optimal gefüllt werden. :)
Das Copyright-Zeichen "©" erscheint bei mir also durch ALT + "0169" auf dem Nummernblock.
Bei mir auch. Herrlich. :) Aber wie kommst Du auf 0169 ?
Die Null muß wohl vorgetippt werden - eigenes Ausprobieren.
Und 169 ist die dezimale Darstellung von hexadezimal A9. Kannst du selbst ja mal umrechnen.
Allerdings klappt es nicht. Wenn ich im Quelltext in Dreamweaver an der benötigten Stelle "ALT 0169" tippe und loslasse, aheb ich zwar ein schönes Copyright Zeichen im Quelltext, aber wenn ich mir die eigentliche html Seite anzeigen lasse erscheint an der Stelle wieder nur ein blauen Quadrat mit einem Fragezeichen drin.
Ist irgendwie logisch. Wenn du das Copyright-Zeichen eintippst, wird ein Unicode-Zeichen in den Dreamweaver-Quelltext eingefügt. Wenn der Dreamweaver dieses Zeichen aber nicht als UTF-8-codiert in die Datei speichert, versteht es der Browser nicht, wenn du ihm sagst, dass alle Sonderzeichen UTF-8 sind.
Was allerdings klappt ist, wenn ich im Unicode Editor unipad ein copyright Zeichen eingebe und es als UTF-8 kopiere,in den Dreamweaver Quelltext paste, dann pastet der nicht nur ein copyright Zeichen sondern ein großes A mit einem Dreieck über dem A. Diese beiden Zeichen zusammen werden dann in der eigentlichen html Seite dann zum Copyright Zeichen.
Das ist auch logisch. Dreamweaver kann offensichtlich kein UTF-8, sondern nur ISO-8859-1 - und vielleicht den einen oder anderen Windows-Zeichensatz.
Das bedeutet: Eine UTF-8-Sequenz wird im Dreamweaver immer als Zwei-, Drei- oder Vier-Zeichen-Kombination angezeigt (je nachdem, welches Unicode-Zeichen darzustellen ist). Die Zeichen aus "Latin 1 Supplement" beginnen hierbei gerne mit "A-Tilde".
Das ist alles merkwürdig.
Es ist alles irgendwie logisch. Trotzdem würde ich im Zweifel fürs Copyright einfach auf © ausweichen. Das ist zu allen Codierungen kompatibel.
- Sven Rautenberg
-
Hallo,
Nein, ich weiß definitiv nicht alles. Ich erscheine dir nur gerade so schlau, weil deine Wissenslücken von mir optimal gefüllt werden.
Nein, nein. War früher schon öfter hier im Forum. Und habe Deine Beiträge gelesen. Keine falsche Scham. Du hast es drauf.
Und 169 ist die dezimale Darstellung von hexadezimal A9. Kannst du selbst ja mal umrechnen.
Dann habe ich von den ganzen Tabellen auf unicode.org garnix. Denn die zeigen alle Hex Zahlen. :(
Ist irgendwie logisch. Wenn du das Copyright-Zeichen eintippst, wird ein Unicode-Zeichen in den Dreamweaver-Quelltext eingefügt. Wenn der Dreamweaver dieses Zeichen aber nicht als UTF-8-codiert in die Datei speichert, versteht es der Browser nicht, wenn du ihm sagst, dass alle Sonderzeichen UTF-8 sind.
Wie sage ich dem Dreamy, dass er das Copyright Zeichen als UTF-8 abspeichern soll. Ich dachte, dass würde ich ihm durch die Meta Zeichensatzangabe mitteilen. Geht das nur über den Umweg des Unicode editors und mit A Tilde+copyright Zeichen ?
Das ist auch logisch. Dreamweaver kann offensichtlich kein UTF-8, sondern nur ISO-8859-1 - und vielleicht den einen oder anderen Windows-Zeichensatz.
Aber warum stehen die griechischen Zeichen dann alle schön im Quelltext. Die sind doch auch im Unicode.
Es ist alles irgendwie logisch. Trotzdem würde ich im Zweifel fürs Copyright einfach auf © ausweichen. Das ist zu allen Codierungen kompatibel.
Und genau das klappt nicht in meiner UTF-8 Zeichensatz kodierten Datei. Wenn ich in Mozilla auf View/Character Encoding auf Western Latin umschalte, wird es korrekt angezeigt.
Müssten die html entities nicht in _jedem_ Zeichensatz korrekt angezeigt werden. Sind doch Teil von HTML, oder nicht ?
-
-
-
Hallo,
Entweder verwendest du die Entity © - das ist schlauer, weil es auch jeder versteht, der den Quelltext lesen kann. Oder du codierst dein Copyright-Zeichen als echtes UTF-8-Zeichen (das sind dann zwei Bytes) im Text - die Entity ist absolut unnötig dafür.
Was mich nun aber wirklich überrascht ist, dass © ebenfalls nicht funktioniert. Da wird kein blaues Quadrat mit Fragezeichen angezeit, sondern ein schwarzes Quadrat mit Fragezeichen drin.
© ist doch eine HTML Entity. Müsste doch auf jeden Fall gehen.
Äußerst merkwürdig.
-
-
-
-
-
Moin!
Definiere "Hex-Zeichen"?
Na ja, nachdem ich mit phpmyadmin hinzugefügt habe. Stehen anstatt der griechischen - solche Zeichen in der DB: Ӓ, etc.
Dein Browser wandelt die griechischen Zeichen in Entities, weil er sie nicht gültig im Formularzeichensatz codieren kann (der vermutlich ISO-8859-1 ist).
Das ist böse - hatte ich aber schon ausführlich beschrieben. :)
MySQL 4.1 hingegen berücksichtigt diese Problematik und legt das Feld im Zweifel etwas länger an. Wenn du aber (was sinnvoll erscheint) TEXT oder BLOB als Spaltentyp für deinen Text nutzt, stört das relativ wenig.
Aha. So ist das also gemeint. Dann benutze ich halt für alle Felder den Typ "text".
Nein, so war das nicht gemeint. TEXT und BLOB haben andere Aufgaben als CHAR und VARCHAR. Sie sind bei Suchoperationen langsamer, weil in der eigentlichen Datenbank nur Zeiger auf Speicher stehen, der sich ganz woanders auf der Platte befinden kann.
Was ich schon immer wissen wollte und nie verstanden habe ist: Wozu ist das Feld "blob"?
TEXT ist für Text ohne Berücksichtigung der Klein/Großschreibung, BLOB für Text MIT Berücksichtigung - und für Binärdaten.
Die Sache mit Klein-/Großschreibung gilt allerdings für eine UTF-8-unfähige Datenbank nicht für dein griechisch.
Die einzelnen Browser verhalten sich leider höchst ekelhaft, wenn das Formular nicht mit 'accept-charset="utf-8"' arbeitet.
Wo stellt man das denn ein ? Weißt Du vielleich wie man das bei phpmyadmin ändern kann?
Ich habs noch nicht nachgeschaut, aber du hast ja den kompletten Quellcode von PHPMyAdmin da. Suche nach "<form" und prüfe, was da jeweils ausgegeben wird - ändere es ggf. um.
Vielleicht gibts auch eine zentrale Option dafür - ein Blick in die Config-Datei wäre sicher lohnend.
Nein, nein. Der wandelt den Text nicht in Fragezeichen um, es bleibt griechisch, wenn ich es in ein "text"-Feld bei phpmyadmin einfüge. Wenn ich aber dann auf "OK" klicke und die Tabelle browser, dann habe ich halt nur solche numerischen entities in der Tabelle. Ist das Unicode ?
ALLES ist Unicode. Unicode ist die Grundlage von SGML, und damit von HTML und XML. Unicode kann man aber ohne zugehörige Codierung nicht wirklich "anfassen" bzw. speichern. Unicode ist zunächst mal eine abstrakte Zuordnung von existierenden Zeichen zu Zahlenwerten. Das deutsche "A" kriegt die 65, das griechische Alpha die 913.
Und jetzt kommt dein Browser ins Spiel. Du gibst ein griechisches Alpha ein. Das läßt der Browser noch zu. Aber beim Abschicken stellt er fest, dass er ISO-8859-1 schicken soll - und in dieser Zeichencodierung ist ein griechisches Alpha nicht enthalten. Was also tun?
Möglichkeit 1: Den Benutzer drauf hinweisen, dass sein Formular Zeichen enthält, die nicht gesendet werden können. Das tut leider kein Browser.
Möglichkeit 2: Die uncodierbaren Zeichen in Fragezeichen umwandeln und abschicken. Dann werden beim Benutzer hoffentlich auch Fragezeichen auftreten, aber immerhin sind alle gesendeten Zeichen in der Codetabelle enthalten.
Möglichkeit 3: Die uncodierbaren Zeichen in HTML-Entities umwandeln und senden. Das funktioniert dann ganz gut, wenn sich niemand um den Zeichensatz kümmert, aber es hat extreme Nachteile, WENN man sich drum kümmert.
Möglichkeit 3 wirkt so: Du kriegst das ISO-codierte Formular zusammen mit der Zeichenfolge Α anstelle des Alphas. Das speicherst du in deiner DB, und gibst es irgendwann als Zeichenfolge in deiner Seite aus. Wenn du nichts weiter codierst oder in Entities umwandelst, wird im Quelltext 1:1 die Zeichenfolge Α stehen, und das bewirkt die Ausgabe eines großen Alphas.
Wenn du aber vernünftig vorgehst, dann wirst du dem Benutzer erlauben wollen, den Text 1:1 einzugeben, was bedeutet, dass er auch <, > und & direkt eingeben darf, ohne es als Entities schreiben zu müssen. Du speicherst diese Zeichen dann 1:1 in der Datenbank, aber bei der Ausgabe läßt du htmlspecialchars() oder htmlentities() drüberlaufen. Das bedeutet: alle &-Zeichen werden zu "&" umgewandelt, und der Browser zeigt dann ein einzelnes &-Zeichen an.
Wenn du aber in deinem gesendeten Formular das Alpha eingegeben hast, der Browser das aber in Α umgewandelt hat, dann wird die Datenbank diese Zeichenfolge auch wieder ausspucken - htmlspecialchars() wird das &-Zeichen erkennen und ein "&" draus machen, und das Quelltext-Resultat "&#913;" wird im Browser eben NICHT als Alpha angezeigt.
Jetzt könnte man natürlich schlau sein und alle Entities vor dem Speichern in die Datenbank oder nach dem Auslesen z.B. in UTF-8 wandeln. Aber was ist, wenn der Benutzer die Zeichenfolge "Α" ins Formular und damit in die Datenbank geschrieben hat. Beispielsweise in dem Satz "Das griechische wird als Entity Γ geschrieben." Ich denke, du erkennst die Problematik.
Deswegen führt kein Weg dran vorbei, alle Formulare als UTF-8 (oder einer anderen Unicode-Codierung) zu versenden. UTF-8 hat den Vorteil, dass es 8-Bit-ASCII-kompatibel ist, man also in Umgebungen, die mit ISO-8859-1 zurechtkommen, im Grundsatz nichts ändern muß - bis eben auf die Details, die ich jetzt nicht noch mal aufzähle. :)
Habe es nämlich noch nicht mittels php wieder aus der DB herausgeholt und in einer html Seite dargestellt.
Es wird scheinbar funktionieren, dich aber nicht 100% glücklich machen. Und den Besucher auch nicht. Mindestens weil die Seiten durch die Entities ziemlich aufgebläht sind.
- Sven Rautenberg
-
Dein Browser wandelt die griechischen Zeichen in Entities, weil er sie nicht gültig im Formularzeichensatz codieren kann (der vermutlich ISO-8859-1 ist).
Habe mir gerade mal eine HTML Seite ausgeben lassen. Mit den numerischen Codes aus der DB. Scheint doch Unicode zu sein, da sie korrekt als griechisch auf der html-Seite erscheinen, die ja UTF-8 kodiert ist.
Nein, so war das nicht gemeint. TEXT und BLOB haben andere Aufgaben als CHAR und VARCHAR. Sie sind bei Suchoperationen langsamer, weil in der eigentlichen Datenbank nur Zeiger auf Speicher stehen, der sich ganz woanders auf der Platte befinden kann.
OK.
Möglichkeit 3 wirkt so: Du kriegst das ISO-codierte Formular zusammen mit der Zeichenfolge Α anstelle des Alphas. Das speicherst du in deiner DB, und gibst es irgendwann als Zeichenfolge in deiner Seite aus. Wenn du nichts weiter codierst oder in Entities umwandelst, wird im Quelltext 1:1 die Zeichenfolge Α stehen, und das bewirkt die Ausgabe eines großen Alphas.
Ja, in der DB stehen solche Dezimalzahlen. Was ich aber immer noch nicht verstehe ist, ob das Unicode ist. Muss es ja sein, oder?
Wenn du aber vernünftig vorgehst, dann wirst du dem Benutzer erlauben wollen, den Text 1:1 einzugeben, was bedeutet, dass er auch <, > und & direkt eingeben darf, ohne es als Entities schreiben zu müssen. Du speicherst diese Zeichen dann 1:1 in der Datenbank, aber bei der Ausgabe läßt du htmlspecialchars() oder htmlentities() drüberlaufen. Das bedeutet: alle &-Zeichen werden zu "&" umgewandelt, und der Browser zeigt dann ein einzelnes &-Zeichen an.
Gute Idee.
Wenn du aber in deinem gesendeten Formular das Alpha eingegeben hast, der Browser das aber in Α umgewandelt hat, dann wird die Datenbank diese Zeichenfolge auch wieder ausspucken - htmlspecialchars() wird das &-Zeichen erkennen und ein "&" draus machen, und das Quelltext-Resultat "&#913;" wird im Browser eben NICHT als Alpha angezeigt.
Mist.
Jetzt könnte man natürlich schlau sein und alle Entities vor dem Speichern in die Datenbank oder nach dem Auslesen z.B. in UTF-8 wandeln. Aber was ist, wenn der Benutzer die Zeichenfolge "Α" ins Formular und damit in die Datenbank geschrieben hat. Beispielsweise in dem Satz "Das griechische wird als Entity Γ geschrieben." Ich denke, du erkennst die Problematik.
Verstehe, was du meinst. Mann das ist echt übel. Was da alles für Probleme auftauchen.
Es wird scheinbar funktionieren, dich aber nicht 100% glücklich machen. Und den Besucher auch nicht. Mindestens weil die Seiten durch die Entities ziemlich aufgebläht sind.
Ja es funktioniert. Im Moment hantiere ich aber noch nicht mit Formularen. Alles was die fremdsprachlichen Seiten tun sollen ist, griechischen Text aus der DB holen. Solange der richtig dargestllt wird ist es doch egal, ob im Quelltext Α steht oder das wirkliche griechische Alpha. Also ich entnehme dieser Formulierung, dass du im Moment auch keine Alternative siehst als Entities im Quelltext zu haben wenn man mit mysql 4.0.20 arbeitet ?
Aber du sagst es - dadurch, dass entities im Quelltext stehen, werden die html Seiten natürlich bei längeren Texten, wie z.B. AGB, sehr groß.
Aber was soll ich machen. Die mySQL Version 4.1 befindet sich noch in der beta Phase.
Also
-
Moin!
Dein Browser wandelt die griechischen Zeichen in Entities, weil er sie nicht gültig im Formularzeichensatz codieren kann (der vermutlich ISO-8859-1 ist).
Habe mir gerade mal eine HTML Seite ausgeben lassen. Mit den numerischen Codes aus der DB. Scheint doch Unicode zu sein, da sie korrekt als griechisch auf der html-Seite erscheinen, die ja UTF-8 kodiert ist.
Die Codierung als UTF-8 ist vollkommen uninteressant für diese numerischen Entities. Die sind extra dafür da, bei einer Zeichencodierung, die ein bestimmtes Sonderzeichen nicht erlaubt, dieses dennoch anzugeben. Wenn du beispielsweise eine ISO-8859-1-Seite mit deutschem Text hast, und über irgendwelche Winkel redest, dann werden hier und da griechische kleine Buchstaben auftauchen: "Die Winkel , und im Dreieck ergeben immer 180 Grad".
Bei einer UTF-8-Seite ist dir das vollkommen egal: Text eintippen, speichern - paßt schon. Bei ISO-8859-1 mußt du entweder die numerischen Entities, oder beispielsweise die benannten Zeichen α, β und γ verwenden (siehe auch http://de.selfhtml.org/html/referenz/zeichen.htm).
Ja, in der DB stehen solche Dezimalzahlen. Was ich aber immer noch nicht verstehe ist, ob das Unicode ist. Muss es ja sein, oder?
Ja, es ist in gewisser Weise Unicode. Die dezimale Zahl gibt exakt das Unicode-Zeichen an. Aber es ist erstens nur in HTML verwendbar (nur Browser wandeln das in die richtigen Zeichen), und zweitens das ineffizienteste Format, was man sich vorstellen kann.
Ja es funktioniert. Im Moment hantiere ich aber noch nicht mit Formularen.
Aber PHPMyAdmin hantiert mit Formularen! Auf die bezieht sich die Aussage zuerst! Denn mit PHPMyAdmin kriegst du ja die Texte in die DB - derzeit eben nur schlecht, weil dein Browser kein UTF-8 schickt.
Alles was die fremdsprachlichen Seiten tun sollen ist, griechischen Text aus der DB holen. Solange der richtig dargestllt wird ist es doch egal, ob im Quelltext Α steht oder das wirkliche griechische Alpha. Also ich entnehme dieser Formulierung, dass du im Moment auch keine Alternative siehst als Entities im Quelltext zu haben wenn man mit mysql 4.0.20 arbeitet ?
Falsch gelesen. UTF-8 ist auch mit mysql 4.0 und davor eine Alternative. Nur mußt du halt an jeder Stelle echt mit UTF-8 arbeiten. MySQL 4.1 würde dir genauso Probleme machen, wenn du ein schlechtes, UTF-8-ignorierendes PHPMyAdmin verwenden würdest. Du brauchst ein UTF-8-sendendendes PHPMyAdmin-Formular - alternativ baust du dir dein eigenes Formular. Texte in eine DB speichern kann so schlimm ja nicht sein, rauskriegen tust du sie ja auch schon. Vergiß nur nie, deine zu speichernden Strings vorher zu escapen: mysql_escape_string()!
Aber was soll ich machen. Die mySQL Version 4.1 befindet sich noch in der beta Phase.
PHPMyAdmin auf UTF-8-Formulare umstellen hilft dir. Der Rest mit der Datenbank ist uninteressant.
- Sven Rautenberg
-
Hallo,
Ja, es ist in gewisser Weise Unicode. Die dezimale Zahl gibt exakt das Unicode-Zeichen an. Aber es ist erstens nur in HTML verwendbar (nur Browser wandeln das in die richtigen Zeichen), und zweitens das ineffizienteste Format, was man sich vorstellen kann.
Hmm, dann werde ich das natürlich nicht so machen. Danke.
Aber PHPMyAdmin hantiert mit Formularen! Auf die bezieht sich die Aussage zuerst! Denn mit PHPMyAdmin kriegst du ja die Texte in die DB - derzeit eben nur schlecht, weil dein Browser kein UTF-8 schickt.
OK, hmm. Ob ich mal versuche einen Programmierer von phpmyadmin zu kontaktieren ? Aber ich kann doch nicht der einzige sein, der andere Sprachen speichern will. Man kann doch in phpmyadmin die Sprache einstellen in der man die Benutzeroberfläche haben will. Wenn ich nun griechisch oder Japanisch wähle, aber kein griechisch oder japanisch eingeben kann, weil kein utf-8 gesendet wird, was habe ich(bzw. die reichen oder Japaner) dann von phpmyadmin ?
Aber wie erstellt man ein Formular, dass UTF-8 sendet. Kommt der Zeichensatz da in den Formtag ? Besser wäre natürlich phpmyadmin umstellen.
-
Moin!
Aber wie erstellt man ein Formular, dass UTF-8 sendet. Kommt der Zeichensatz da in den Formtag ? Besser wäre natürlich phpmyadmin umstellen.
Das Formular wird in dem Zeichensatz versendet, in dem die Seite ausgeliefert wurde. Oder in dem Zeichensatz, der im Attribut accept-charset des <form> steht, wenn einer angegeben ist. Jedenfalls theoretisch.
Wenn es bei deinem konkreten Browser Probleme gibt, sorge dafür, dass sowohl accept-charset angegeben ist, als auch dass die Seite und der accept-charset die gleiche Zeichencodierung nutzen: UTF-8. Dann sollte eigentlich nichts mehr schiefgehen.
- Sven Rautenberg
-
-
-
-
-
-