nicht angemeldet
Gunnar Bittersmann
dedlfix
Der Martin
dedlfix
dedlfix
Gunnar Bittersmann
dedlfix
dedlfix
Gunnar Bittersmann
dedlfix
dedlfix
Bei japanischen Seiten habe ich mit drop-down-listen das Problem, das diese nur mit Fragezeichen ausgefüllt werden. Die Einträge stammen aus einer my-sql-datenbank. Dort werden die Zeichen korrekt eingestellt - die Datenbank unterstützt utf-8. Ebenso mein Editor (notepad2). Auch der Rest der Seite wird richtig dargestellt.
Ich hatte dieses Problem bereits bei polnische Seiten und habe mich mit numerischen Zeichencodes beholfen, um einige der speziellen Buchstaben darzustellen. Beim Japanischen wäre diese Methode ziemlich aufwendig.
Daher such ich ein entweder ein Tool mit dem ein japanischer string in einen string mit numerischen Codes umgewandelt wird oder eine Funktion die mir im Formular das korrekte Zeichen wiedergibt. htmlentities helfen mir übrignes nicht weiter, die Methode habe ich bereits getestet.
@@MaLoRu56:
nuqneH
Bei japanischen Seiten habe ich mit drop-down-listen das Problem, das diese nur mit Fragezeichen ausgefüllt werden.
Zeig mal her! (Link)
Qapla'
Mahlzeit MaLoRu56,
Bei japanischen Seiten habe ich mit drop-down-listen das Problem, das diese nur mit Fragezeichen ausgefüllt werden.
Das sieht grundsätzlich nach einem Zeichensatzcodierungsproblem aus.
Die Einträge stammen aus einer my-sql-datenbank. Dort werden die Zeichen korrekt eingestellt - die Datenbank unterstützt utf-8.
Definiere "dort". Wie schaust Du Dir die Daten an? Direkt per MySQL-Konsole? Oder mit einem Admin-Tool wie phpMySQLadmin?
Ebenso mein Editor (notepad2). Auch der Rest der Seite wird richtig dargestellt.
Trotzdem wird offenbar irgendwo auf dem Weg von den in der Datenbank als UTF-8 gespeicherten Werten bis zum Browser irgendwas konvertiert. Bist Du sicher, dass die Verbindung zwischen PHP und Datenbank auch auf UTF-8 eingestellt ist ("SET NAMES 'utf8';")? Der Webserver ist richtig konfiguriert und liefert das HTML als UTF-8 aus? Was steht in den HTTP-Headern?
MfG,
EKKi
Trotzdem wird offenbar irgendwo auf dem Weg von den in der Datenbank als UTF-8 gespeicherten Werten bis zum Browser irgendwas konvertiert. Bist Du sicher, dass die Verbindung zwischen PHP und Datenbank auch auf UTF-8 eingestellt ist ....?
Genau das wars!
habe jetzt vor der query die Zeile
mysql_query("SET CHARACTER SET utf8");
eingefügt
nun funktioniert es
Besten Dank !
Hi!
habe jetzt vor der query die Zeile
mysql_query("SET CHARACTER SET utf8");
eingefügt
nun funktioniert es
Der bessere Ort als "vor der Query" wäre "direkt nach jedem Connect". Denn du benötigst für sämtliche Kommunikation mit dem MySQL-Server die Klarheit der zu verwendenden Zeichenkodierung. Sie einmal pro Verbindung zu setzen reicht aber. (Wenn es nur eine etwas ungenaue Wortwahl deinerseits war, dann will ich nichts gesagt haben.)
Verwendest du immer noch PHP4 (genauer gesagt: eine Version kleiner als 5.2.3)? Ansonsten bitte die Funktion mysql_set_charset() verwenden. Außerdem war die Empfehlung nicht SET CHARACTER SET sondern SET NAMES. Wenn du den Unterschied zwischen beiden Varianten nicht kennst und es bewusst einsetzt, kann dir SET CHARACTER SET unter bestimmten Umständen wieder Datenverlust bereiten (nämlich dann, wenn die Kodierungseinstellung der Datenbank eine andere ist als du sonst verwendest).
Lo!
Hallo,
Bei japanischen Seiten habe ich mit drop-down-listen das Problem, das diese nur mit Fragezeichen ausgefüllt werden. Die Einträge stammen aus einer my-sql-datenbank. Dort werden die Zeichen korrekt eingestellt - die Datenbank unterstützt utf-8. Ebenso mein Editor (notepad2). Auch der Rest der Seite wird richtig dargestellt.
offensichtlich ein Codierungsproblem, wie EKKi auch schon mutmaßte. Da Fragezeichen angezeigt werden, geht der Browser wohl davon aus, die Daten seien UTF-8 codiert; offensichtlich sind sie es aber nicht. Das Fragezeichen ist das Ersatzzeichen für Codes (Bytefolgen), die in UTF-8 ungültig sind.
Vermutlich behauptet dein Server also, UTF-8 zu liefern, gibt aber in Wirklichkeit irgendeine 1-Byte-Codierung (evtl. ISO-8859-1) aus.
Ich hatte dieses Problem bereits bei polnische Seiten und habe mich mit numerischen Zeichencodes beholfen, um einige der speziellen Buchstaben darzustellen.
Das ist wirklich nur ein Workaround.
htmlentities helfen mir übrignes nicht weiter, die Methode habe ich bereits getestet.
Nein, weil diese Funktion -wie der Name schon sagt- nur ein paar wenige Codes umwandelt, die in HTML u.U. eine Sonderbedeutung haben. Im Wesentlichen sind das nur "<", ">", "&" und die Anführungszeichen.
Ein Online-Beipiel, wie Gunnar auch schon fordert, wäre der beste Punkt, an dem man ansetzen könnte. Dann sehen wir weiter.
So long,
Martin
Ci yi bak!
offensichtlich ein Codierungsproblem, wie EKKi auch schon mutmaßte. Da Fragezeichen angezeigt werden, geht der Browser wohl davon aus, die Daten seien UTF-8 codiert; offensichtlich sind sie es aber nicht. Das Fragezeichen ist das Ersatzzeichen für Codes (Bytefolgen), die in UTF-8 ungültig sind.
Dieses Ersatzzeichen sieht normalerweise aus wie ein weißes Fragezeichen in einem schwarzen Karo (U+FFFD REPLACEMENT CHARACTER), und wenn die verwendete Schriftart ihn nicht hat, sollte ein Kasten erscheinen und kein Fragezeichen.
Das richtige Fragezeichen kenne ich nur vom umgekehrten Fall: Ein Unicode-String wurde in ISO-egal-welches konvertiert, und diejenigen Zeichen, die es da nicht gibt, werden durch Fragezeichen ersetzt. Das ist dann aber auch keine Fehlinterpretation der Bytefolge, sondern ein absichtlicher Fallback.
Beispiel: 丳 (U+4E33)
Bytefolge in UTF-8: E4, B8, B3
Fehlinterpretiert als ISO 8859-1: 丳
Konvertiert in ISO 8859-1: ?
htmlentities helfen mir übrignes nicht weiter, die Methode habe ich bereits getestet.
Nein, weil diese Funktion -wie der Name schon sagt- nur ein paar wenige Codes umwandelt, die in HTML u.U. eine Sonderbedeutung haben. Im Wesentlichen sind das nur "<", ">", "&" und die Anführungszeichen.
Hmm, das macht doch htmlspecialchars(…), oder? htmlentities(…) vergurkt auch die Umlaute, weswegen ich sie nie verwende, macht das aber afaik nur für Zeichen, für die es benamste Entities gibt – bei Japanisch also wirkungslos.
Ein Online-Beipiel, wie Gunnar auch schon fordert, wäre der beste Punkt, an dem man ansetzen könnte. Dann sehen wir weiter.
Full ACK.
Viele Grüße vom Længlich
Hallo,
Das Fragezeichen ist das Ersatzzeichen für Codes (Bytefolgen), die in UTF-8 ungültig sind.
Dieses Ersatzzeichen sieht normalerweise aus wie ein weißes Fragezeichen in einem schwarzen Karo (U+FFFD REPLACEMENT CHARACTER), und wenn die verwendete Schriftart ihn nicht hat, sollte ein Kasten erscheinen und kein Fragezeichen.
eben nochmal ausprobiert:
* IE (5.5 und 6.0) zeigt leere Kästchen und "verschluckt" ggf. ein bis zwei
Folgezeichen, je nachdem, wieviele zusätzliche Bytes das Startbyte ankündigt
* Opera (momentan 8.54) zeigt leere Kästchen, interpretiert aber die
nachfolgenden Zeichen trotzdem einzeln - d.h. er kombiniert nicht die
Folgezeichen, wenn er einen Fehler in der Sequenz erkennt
* Firefox (3.0.11) zeigt Kästchen mit "FF/FD", dem Code des Ersatzzeichens,
verhält sich aber sonst wie Opera (kombiniert nicht stur drauflos)
Ich hätte aber schwören können, dass ich schon einige Male Fragezeichen in einem Webdokument mit fehlerhafter Codierung gesehen habe ...
Das richtige Fragezeichen kenne ich nur vom umgekehrten Fall: Ein Unicode-String wurde in ISO-egal-welches konvertiert, und diejenigen Zeichen, die es da nicht gibt, werden durch Fragezeichen ersetzt. Das ist dann aber auch keine Fehlinterpretation der Bytefolge, sondern ein absichtlicher Fallback.
Vielleicht verwechsle ich es tatsächlich mit dieser Art Unfall.
Nein, weil diese Funktion -wie der Name schon sagt- nur ein paar wenige Codes umwandelt, die in HTML u.U. eine Sonderbedeutung haben. Im Wesentlichen sind das nur "<", ">", "&" und die Anführungszeichen.
Hmm, das macht doch htmlspecialchars(…), oder? htmlentities(…) vergurkt auch die Umlaute, weswegen ich sie nie verwende, macht das aber afaik nur für Zeichen, für die es benamste Entities gibt – bei Japanisch also wirkungslos.
Stimmt. ich verwende htmlentities() auch nie, hatte aber in Erinnerung, dass diese Funktion nur wenige Sonderzeichen mehr als htmlspecialchars() behandelt.
So long,
Martin
Hi!
Da Fragezeichen angezeigt werden, geht der Browser wohl davon aus, die Daten seien UTF-8 codiert; offensichtlich sind sie es aber nicht. Das Fragezeichen ist das Ersatzzeichen für Codes (Bytefolgen), die in UTF-8 ungültig sind.
Vermutlich behauptet dein Server also, UTF-8 zu liefern, gibt aber in Wirklichkeit irgendeine 1-Byte-Codierung (evtl. ISO-8859-1) aus.
Unwahrscheinlich, denn japanische Zeichen sind in ISO-8859-1 nicht enthalten. Wer auch immer ISO-8859-1 daraus macht hat schon ein Problem und kann nur Fragezeichen liefern. Ungültige UTF-8-Sequenzen werden ansonsten eigentlich mit den Fragezeichen im auf der Spitze stehenden Viereck angezeigt.
Ich vermute, dass die Kodierung auf der Verbindung zwischen MySQL und PHP nicht ausgehandelt wurde und per Default auf Latin1 steht. Das wäre meiner Meinung nach der plausibelste Grund. MySQL soll (aufgrund der Default-Einstellung) Nicht-Latin1-Zeichen nach Latin1 konvertieren, das Fragezeichen im Viereck existiert ebenfalls nicht in Latin1, also kommt das normale Fragezeichen zum Einsatz.
htmlentities helfen mir übrignes nicht weiter, die Methode habe ich bereits getestet.
Nein, weil diese Funktion -wie der Name schon sagt- nur ein paar wenige Codes umwandelt, die in HTML u.U. eine Sonderbedeutung haben. Im Wesentlichen sind das nur "<", ">", "&" und die Anführungszeichen.
htmlentities() schrieb er, du hast das gerade mit htmlspecialchars() verwechselt. Und wenn htmlentites() trotz Angabe des charset-Parameters (hat er hoffentlich bei seinem Test nicht vergessen) nicht richtig arbeiten kann, dann ist schon vorher was schief gelaufen.
Lo!
Vermutlich behauptet dein Server also, UTF-8 zu liefern, gibt aber in Wirklichkeit irgendeine 1-Byte-Codierung (evtl. ISO-8859-1) aus.
Ja, denke ich auch. Die Datenbank sehe ich mir mit PHPMyAdmin an.
Wo genau stelle ich denn den das "set names" ein - im php-script, in der Datenbank?
Ein Online-Beipiel, wie Gunnar auch schon fordert, wäre der beste Punkt, an dem man ansetzen könnte. Dann sehen wir weiter.
siehe http://www.beko.de/deutsch/produkte/download_manager/dok_search_jp.php
Vielen Dank, Manfred
Hi!
Wo genau stelle ich denn den das "set names" ein - im php-script, in der Datenbank?
Dein PHP-Script unterhält eine Vebindung zum MySQL-Server. Um darüber Daten auszutauschen muss bekannt sein, welche Kodierung verwendet werden soll. Wenn du das nicht explizit nach dem Öffnen der Verbindung machst, nimmt MySQL einen Default-Wert, der bei dir vermutlich Latin1 lautet. mysql_set_charset(), mysqli_set_charset() oder ein Statement mit SET NAMES utf8 schafft für beiden Seiten Klarheit. Die erstgenannten Funktionen sind gegenüber dem SET NAMES vorzuziehen, da sie auch die Kodierung von Funktionen wie mysql_real_escape_string() beeinflussen. Das ist bei ISO-8859-1 und UTF-8 nicht weiter wichtig, weil sich damit nichts ändert, aber bei mindestens einer der ostasiatischen Kodierungen hat das Auswirkungen.
siehe http://www.beko.de/deutsch/produkte/download_manager/dok_search_jp.php
Hier offenbart sich eine vermutlich Unachtsamkeit deinerseits. Der Webserver sendet in seinem HTTP-Header Content-Type als charset-Angabe UTF-8, dein gleichnamiges Meta-Element allerdings sagt shift-jis. Da der HTTP-Header Vorrang vor dem Meta-Element hat, wirst du später beim lokalen Speichern der Webseite ein Problem bekommen, denn wenn ein Browser diese gespeicherte Seite anzeigen soll, hat er nur noch diese Meta-Element-Angabe.
Lo!
@@MaLoRu56:
nuqneH
siehe http://www.beko.de/deutsch/produkte/download_manager/dok_search_jp.php
Mal so nebenbei gefragt: Waozu dient das dritte 'select'? Doch nicht etwa zur Sprachauswahl?
Die Problematik ist in [NAVIGATION-SELECT] nachzulesen. Auch [WHEN-LANG-NEG] könnte für dich interessant sein.
Qapla'
Hi!
siehe http://www.beko.de/deutsch/produkte/download_manager/dok_search_jp.php
Mal so nebenbei gefragt: Waozu dient das dritte 'select'? Doch nicht etwa zur Sprachauswahl?
Ja, aber vermutlich nicht so, wie du das gerade vermutet hast. Wenn Google-Translate nicht gelogen hat, geht es um einen Download von Produktkatalogen in verschiedenen Sprachen, nicht aber um eine Umschaltung der Sprache der Seite. Eine automatische Vorauswahl der Sprache wäre zwar sicher nicht unsinnig, aber nur unwesentliches Beiwerk.
Lo!
Mal so nebenbei gefragt: Waozu dient das dritte 'select'? Doch nicht etwa zur Sprachauswahl?
Sprachauswahl nicht direkt, sondern es werden dann Dokumente aufgelistet, in denen diese Sprache vorkommt, Bedienungsanleitungen (auch mehrsprachig z.b.)
Die Problematik ist in [NAVIGATION-SELECT] nachzulesen. Auch [WHEN-LANG-NEG] könnte für dich interessant sein.
Qapla'
OK- schau ich mir mal an
Gruß an die Klingongen
@@MaLoRu56:
nuqneH
Sprachauswahl nicht direkt, sondern es werden dann Dokumente aufgelistet, in denen diese Sprache vorkommt, Bedienungsanleitungen (auch mehrsprachig z.b.)
OK, dann ist 'select' unproblematisch.
Qapla'
hi,
Ein Online-Beipiel, wie Gunnar auch schon fordert, wäre der beste Punkt, an dem man ansetzen könnte. Dann sehen wir weiter.
siehe http://www.beko.de/deutsch/produkte/download_manager/dok_search_jp.php
Ich vermisse den Link zum Download der Schriftart ;-)
Hotti
Bei japanischen Seiten habe ich mit drop-down-listen das Problem, das diese nur mit Fragezeichen ausgefüllt werden.
Auf welchem Betriebssystem und mit welcher Sprachversion? Wie sieht den die Seite auf einem Rechner mit japanischen OS aus?
UTF-8 ist nicht alles, auf dem System muss auch die Schriftart drauf sein, die dargestellt werden soll.
Hotti
Hi!
Ach, hotti san ...
Bei japanischen Seiten habe ich mit drop-down-listen das Problem, das diese nur mit Fragezeichen ausgefüllt werden.
Auf welchem Betriebssystem und mit welcher Sprachversion? Wie sieht den die Seite auf einem Rechner mit japanischen OS aus?
Auch ein japanisches OS kann ein ? nur als ? darstellen. Das Betriebssystem ist bei Problemen mit Webanwendungen weniger relevant. Eine passende Schriftart reicht (wenn es kein Kodierungsproblem gibt). Es gibt auch Nachrüstpacks für "exotische" Fonts, ohne dass man die grundsätzliche Sprache des OS wechseln muss.
Auch der Rest der Seite wird richtig dargestellt.
Auch dieser Satz deutet darauf hin, dass deine Vermutung in die falsche Richtung abzielt und es kein Schriftart-Problem ist.
UTF-8 ist nicht alles, auf dem System muss auch die Schriftart drauf sein, die dargestellt werden soll.
Bei einigen Browsern reicht es bereits, wenn irgendeine Schriftart mit Glyphen für die darzustellenden Zeichen auffindbar ist. Zumindest, dass irgendwas lesbares zu sehen ist.
Lo!
@@dedlfix:
nuqneH
Auch der Rest der Seite wird richtig dargestellt.
Auch dieser Satz deutet darauf hin, dass deine Vermutung in die falsche Richtung abzielt und es kein Schriftart-Problem ist.
Für mich deutet es gerade darauf hin, dass es ein Schriftart-Problem ist: dass hotti keine Schriftart installiert hat, die japanische Glyphen enthält.
Qapla'
hi,
Auch ein japanisches OS kann ein ? nur als ? darstellen.
Stümmt. Aber in der Response sind nicht nur Fragezeichen:
BEKOÒâòÒéíÒéñÒâ½Òü«ÒâÇÒéªÒâ│Òâ¡Òâ╝Òâë
die mein Browser als BEKOファイルのダウンロード darstellt.
Nur mal so nebenbei ;-)
Hotti
Hi!
Auch ein japanisches OS kann ein ? nur als ? darstellen.
Stümmt. Aber in der Response sind nicht nur Fragezeichen:
BEKOÒâòÒéíÒéñÒâ½Òü«ÒâÇÒéªÒâ│Òâ¡Òâ╝Òâë
die mein Browser als BEKOファイルのダウンロード darstellt.
Das müsstest du als Bild zeigen, denn mein Browser zeigt das an, was er soll. Es ist schon so, wie du sagst. Richtig interpretieren (können) ist die eine Seite der Medaille, richtig darstellen (können) die andere.
Lo!
hi,
[..] Richtig interpretieren (können) ist die eine Seite der Medaille, richtig darstellen (können) die andere.
ja, da hätte ich jetzt gerne den Rechner wieder mit dem japanischen NT, was ich fürs Team mal aufgesetzt habe. Für meine japanischen Kolleginnen hab ich damals (fast) alles gemacht ;-)
NT in englisch, französisch, italienisch und spanisch installieren war ein Klacks dagegen.
Also um aufs Problem zurückzukommen, vermutlich fehlen ganz einfach die Zeichen in der verfügbaren Schriftart oder die Schriftart ist auf dem Zielsystem nicht verfügbar. Obwohl ich mir bei den jp Zeichen da nicht ganz sicher bin, ob mit der Schriftart allein auch alles 'rüberkommt ;-)
Viele Grüße,
Maya-Hotte (Motte)
Hi!
Also um aufs Problem zurückzukommen, vermutlich fehlen ganz einfach die Zeichen in der verfügbaren Schriftart oder die Schriftart ist auf dem Zielsystem nicht verfügbar.
Wenn du mit Zielsystem deinen Rechner meinst, dann kann das sein. Ansonsten hat der OP das Problem ja schon geklärt und fast richtig gelöst.
Obwohl ich mir bei den jp Zeichen da nicht ganz sicher bin, ob mit der Schriftart allein auch alles 'rüberkommt ;-)
Also wenn du das jetzt nicht im übertragenen Sinne meinst, reicht es von Seiten des Servers, die ausgelieferten Texte mit der korrekt ausgezeichneten Zeichenkodierung zu versenden. Anzeigeprobleme auf Clients kann er nicht lösen, nur Hinweise geben (per CSS font-family zum Beispiel), mit welcher Schriftart das Problem vielleicht nicht entsteht.
Lo!
Cheh sha la!
Also um aufs Problem zurückzukommen, vermutlich fehlen ganz einfach die Zeichen in der verfügbaren Schriftart oder die Schriftart ist auf dem Zielsystem nicht verfügbar. Obwohl ich mir bei den jp Zeichen da nicht ganz sicher bin, ob mit der Schriftart allein auch alles 'rüberkommt ;-)
Auch wenn Japanisch als das komplizierteste Schriftsystem der Welt gilt: Vom Standpunkt des Font-Renderings betrachtet ist es eines der einfachsten. Alle Zeichen sind gleich breit, keine Diakritika, keine Ligaturen, kein Kerning, keine stellungsabhängigen Varianten – die Zeichen werden einzeln von links nach rechts hingemalt und fertig. Man braucht weder OpenType-Features noch Language Packs; eine beliebige Unicode-Schriftart, die die Zeichen hat, genügt.
(Ein krasses Beispiel, wo das nicht so ist, sind die meisten indischen Schriften. Die haben zwar auf den ersten Blick viel weniger Zeichen, warten aber mit kompliziert positionierten Diakritika und Ligaturen auf. Trotz der relativ wenigen Codepoints braucht man z.T. mehrere tausend Glyphen, um sie wirklich richtig darstellen zu können.)
Viele Grüße vom Længlich
@@Længlich:
nuqneH
Auch wenn Japanisch als das komplizierteste Schriftsystem der Welt gilt: Vom Standpunkt des Font-Renderings betrachtet ist es eines der einfachsten. Alle Zeichen sind gleich breit
Klammern sind schmaler. Und wenn lateinische Zeichen im Text vorkommen, fallen die japanischen Zeichen auch aus dem Raster.
Satzzeichen (Punkt, Komma) stehen ggfs. außerhalb des Rahmens. (Sie beginnen keine neue Zeile.)
keine Diakritika
が U+304C ≡ か U+304B ゙ U+3099 – Kann man das nicht als Äquivalent unserer Diakritika sehen?
die Zeichen werden einzeln von links nach rechts hingemalt
Oder von oben nach unten (die „Zeilen“ dann von rechts nach links).
und fertig.
Ganz so einfach ist es dann doch nicht. [Requirements for Japanese Text Layout]
Ein krasses Beispiel, wo das nicht so ist, sind die meisten indischen Schriften.
Oder die arabische, wo Zeichen verbunden werden und unterschiedliche Formen haben. Kann man auch falsch machen: United Airlines doesn’t speak Arabic.
Qapla'
'E!
Klammern sind schmaler. Und wenn lateinische Zeichen im Text vorkommen, fallen die japanischen Zeichen auch aus dem Raster.
Wenn man verschiedene Schriften mischt, wird es immer etwas komplexer. Die ostasiatischen Satzzeichen haben dieselbe Breite wie die Ideographen, auch die Klammern. Das spielt beim Rendering aber sowieso keine große Rolle, weil sie nicht in ein Raster eingesetzt, sondern in Schreibrichtung nacheinander ausgegeben werden.
Satzzeichen (Punkt, Komma) stehen ggfs. außerhalb des Rahmens. (Sie beginnen keine neue Zeile.)
Zeilenumbruchsverhalten u.ä. habe ich gar nicht betrachtet; das ist aber auch in allen Schriften ein Thema.
keine Diakritika
が U+304C ≡ か U+304B ゙ U+3099 – Kann man das nicht als Äquivalent unserer Diakritika sehen?
Ja, kann man. Hier hätte ich nicht versuchen sollen, einen etwas komplexeren Gedanken in einem Wort auszudrücken. ;-)
Für sämtliche sinnvollen Kombinationen gibt es nämlich schon fertige Zeichen, so wie ja z.B. auch die deutschen Umlaute vorgefertigt existieren. Das ist aber nicht immer so – für einige Sprachen werden auch im lateinischen Alphabet Kombinationen gebraucht, für die es keinen Codepoint gibt. Hier müssen die Diakritika horizontal und vertikal in Abhängigkeit vom vorhergehenden Glyphen positioniert werden. In manchen Schriften, z.B. den meisten indischen, verbinden sie sich auch noch irgendwie mit den Basisglyphen oder können über, unter, rechts von, links von oder in den Basisglyphen stehen. Das geht nur noch, indem man den ganzen Haufen durch einen vorgefertigten Kombi-Glyphen ersetzt, der selbst gar keinen Codepoint hat.
Für Japanisch wird nichts davon gebraucht, hier genügt eine Normalisierungsform, die die vorgefertigten Glyphen verwendet.
die Zeichen werden einzeln von links nach rechts hingemalt
Oder von oben nach unten (die „Zeilen“ dann von rechts nach links).
Das kommt auf Webseiten nicht vor, oder? Hier ging es ja erstmal nur um die korrekte Darstellung im Browser.
und fertig.
Ganz so einfach ist es dann doch nicht. [Requirements for Japanese Text Layout]
Ja, es gibt noch einige Aspekte, die ich nicht erwähnt hatte. Beim ersten Überfliegen sieht es aber immer noch relativ einfach aus. Daß z.B. bei Blocksatz der überzählige Freiraum nach gewissen Regeln verteilt werden muß, ist ja auch in allen Schriften so – und diese Regeln erscheinen mir für Japanisch nicht außergewöhnlich kompliziert.
Worauf ich hinauswollte, ist folgendes: Wenn Du Dir eine Schriftart mit den japanischen Zeichen installierst, dann reicht das aus, damit ein korrekter und lesbarer japanischer Text angezeigt werden kann (auch wenn eventuell irgendwelche Layoutfeinheiten nicht ganz stimmen). Und das ist eben nicht bei allen Schriften so. Bei Thai z.B. müssen Diakritika gestapelt werden, was ein gewöhnliches westeuropäisches Windows ohne Language Pack und/oder spezielle OpenType-Fonts eben nicht richtig macht. Da können sie so ungeschickt übereinanderfallen, daß der entstehende Klumpen gar nicht mehr lesbar ist.
Ein krasses Beispiel, wo das nicht so ist, sind die meisten indischen Schriften.
Oder die arabische, wo Zeichen verbunden werden und unterschiedliche Formen haben. Kann man auch falsch machen: United Airlines doesn’t speak Arabic.
Oh ja, sowas habe ich sogar schon mal als Tätowierung gesehen. Soweit ich weiß, sehen unverbundene Buchstaben für Araber wie A.B.K.Ü.R.Z.U.N.G.E.N. aus. Lam und Alef nicht zu einer speziellen Ligatur zu verbinden ist auch explizit falsch.
Viele Grüße vom Længlich
@@Længlich:
nuqneH
für einige Sprachen werden auch im lateinischen Alphabet Kombinationen gebraucht, für die es keinen Codepoint gibt.
Welche sollten das sein?
Oder von oben nach unten (die „Zeilen“ dann von rechts nach links).
Das kommt auf Webseiten nicht vor, oder?
Warum sollte es nicht?
Alltägliches und Technisches wird sicher von links nach rechts geschrieben. Aber wenn jemand japanische Poesie ins Web stellt?
Qapla'
E kú àárò!
für einige Sprachen werden auch im lateinischen Alphabet Kombinationen gebraucht, für die es keinen Codepoint gibt.
Welche sollten das sein?
Yoruba zum Beispiel, und einige weitere afrikanische und amerikanische Sprachen. Und natürlich das IPA.
Alltägliches und Technisches wird sicher von links nach rechts geschrieben. Aber wenn jemand japanische Poesie ins Web stellt?
Dann ist es wünschenswert, aber nicht notwendig, daß der Text vertikal dargestellt wird. Korrekt und lesbar ist er auch von links nach rechts.
Zudem ist vertikaler Text keine Spezialität des Japanischen; den gibt es auch in Chinesisch, Mongolisch, Phags-Pa, Ogham, … Ich würde ihn eher als generelles Feature internationalisierter, Unicode-basierter Textverarbeitung ansehen denn als spezielle Voraussetzung für Japanisch.
Viele Grüße vom Længlich
Hi!
Die ostasiatischen Satzzeichen haben dieselbe Breite wie die Ideographen, auch die Klammern.
Da scheint es aber Unterschiede zwischen japanisch und chinesisch zu geben, wenn ich mir nur mal die Wikipedia-Startseiten der beiden Sprachen ansehe. Aus dem Chinesischen kenne ich, dass die Satzzeichen üblicherweise die volle Breite einnehmen. Bei japanisch scheint das nicht der Fall zu sein.
Lo!
