Beitrag #1

Fortsetzung von Lernmethoden -> Jap. sprechen lernen

Doitsuyama hat eine lange Unicode-preisende mail verfaßt. Dazu gäbe es viel zu sagen.

1.) Unicode erlaubt es, auf der ganzen Welt fast alle Schriften simultan darzustellen. D.h. man kann auf einer HTML-Seite gleichzeitig Kyrillisch und Kanji darstellen. Aber wer von uns braucht gleichzeitig Kyrillisch und Kanji? Was wir jedoch brauchen, sind die dt. Umlaute und Kanji, und dafür ist Unicode tatsächlich geeignet.

2.) Der Nachteil von Unicode: die Datei-Größe. Ein Unicode-Zeichen braucht 7-8 Byte. Dasselbe Zeichen in JIS benötigt 2 Byte. D.h. reine japanische Unicode-Texte sind ca. 4mal speicherplatzintensiver als JIS-codierte Texte. Schon aus diesem Grunde wird sich Unicode in Japan nicht so schnell durchsetzen. In Europa codieren wir unsere Texte ja auch nicht in Unicode, oder? Für das J-N ist dies jedoch ohne Belang, denn die Kanji-Menge ist auf diesen Seiten verschwindend klein.

3.) Unicode kann (meines Wissens) nicht alle Sprachen, insbesondere kein Arabisch und einige indische Sprachen. In diesen Sprachen hängt die Form/das Aussehen eines Zeichens vom Kontext/den umgebenden Zeichen ab. Dieses Wissen, die Zeichen kontextabhängig darzustellen, ist im Unicode einfach nicht implementiert. Unicode ist eine 1:1 Zuordnung Zahlenwert:Zeichen und kümmert sich nicht um den Kontext.

4.) Es ist durchaus möglich, verschiedene Codierungen auf einer Seite anzuzeigen.

5.) Zu dem grauenvollen bug, der die Unicode-Zeichen verstümmelt: Nora sollte einfach die Breite des Posting-Eingabe-Fensters von derzeit 60 auf z.B. 100 hochsetzen.
Dadurch wird die Zahl solcher Verstümmelungen verringert (aber nicht gänzlich verhindert). Und man wird auch längere Links posten können. Das Problem ist, dass die Forum-SW (Software) ein <br> (=Zeilenumbruch) vor jeder Zeile einfügt. Manchmal glaubt die SW, dass eine neue Zeile mitten in einem Unicode beginnt... Dann wird eifrig ein <br> in die Mitte des Unicodes eingefügt und statt "が" heißt es "&#12<br>364;" Der erste Teil "&#12" wird dann als unvollständiger Unicode interpretiert (was für ein Schwachsinn) und "364;" wird in der neuen Zeile dargestellt und ist so sichtbar. Ist das die Verstümmelung, die Ihr meint?: statt "が" sieht man "
364;"
Dieses Rroblem tritt vor allem beim nachträglichen Editieren von bereits geposteten Beiträgen auf.

Meine Empfehlungen:
a.) Nora setzt die Eingabefeldbreite von 60 auf 100
b.) Jeder postet nur in Unicode, kein JIS oder S-JIS
c.) Beim Posten ggfl. öfters umbrechen statt langen Kanji Zeilen

Beitrag #2

Ich habe jetzt die Breite hochgesetzt, allerdings nur auf 90, damit Menschen mit kleineren Auflösungen nicht beim Schreiben scrollen müssen. Allerdings hat das, denke ich, nur auf die verstümmelten Links auswirkungen und mit den Problemen bei der Eingabe von japanischen Schriftzeichen nichts zu tun. Aber da bin ich mir nicht sicher; man wird ja sehen.

Beitrag #3

Zitat:Doitsuyama hat eine lange Unicode-preisende mail verfaßt. Dazu gäbe es viel zu sagen.

Ich bin kein Experte, dafür müsste ich mich erst tiefer einarbeiten. Meine Absicht war lediglich, einen Denkanstoß zu geben, um das Forum zu verbessern. Ich begrüße dieses neue Thema auf jeden Fall.

Zitat:2.) Der Nachteil von Unicode: die Datei-Größe. Ein Unicode-Zeichen braucht 7-8 Byte. Dasselbe Zeichen in JIS benötigt 2 Byte. D.h. reine japanische Unicode-Texte sind ca. 4mal speicherplatzintensiver als JIS-codierte Texte. Schon aus diesem Grunde wird sich Unicode in Japan nicht so schnell durchsetzen. In Europa codieren wir unsere Texte ja auch nicht in Unicode, oder? Für das J-N ist dies jedoch ohne Belang, denn die Kanji-Menge ist auf diesen Seiten verschwindend klein.

Moment mal, Unicode-Zeichen sind genau so zwei Byte wie JIS-Zeichen. Jedenfalls, solange man die Texte als Text-Dateien abspeichert. Dein Beispiel weiter unten が hat tatsächlich 8 Byte, eine Unicode-Datei würde hierfür aber nur zwei Byte brauchen, nämlich für die hexadezimale Darstellung von 12364. In den HTML-Dateien dieses Forums werden Unicodes wohl tatsächlich mit der &#-Codierung abgelegt, was aber auch nicht zwingend ist.

Zitat:5.) Zu dem grauenvollen bug, der die Unicode-Zeichen verstümmelt: Nora sollte einfach die Breite des Posting-Eingabe-Fensters von derzeit 60 auf z.B. 100 hochsetzen.
Dadurch wird die Zahl solcher Verstümmelungen verringert (aber nicht gänzlich verhindert). Und man wird auch längere Links posten können. Das Problem ist, dass die Forum-SW (Software) ein
(=Zeilenumbruch) vor jeder Zeile einfügt. Manchmal glaubt die SW, dass eine neue Zeile mitten in einem Unicode beginnt... Dann wird eifrig ein
in die Mitte des Unicodes eingefügt und statt "が" heißt es "
364;" Der erste Teil "" wird dann als unvollständiger Unicode interpretiert (was für ein Schwachsinn) und "364;" wird in der neuen Zeile dargestellt und ist so sichtbar. Ist das die Verstümmelung, die Ihr meint?: statt "が" sieht man "
364;"
Dieses Rroblem tritt vor allem beim nachträglichen Editieren von bereits geposteten Beiträgen auf.

Deine Erklärung klingt zwar plausibel, aber auch ich glaube nicht, dass die Breite des Eingabefensters etwas damit zu tun hat. Das Eingabefenster bricht die Zeilen nämlich ganz von alleine um, ohne dass der Benutzer Zeilenumbrüche einfügt. Der SEND-Befehl des Buttons "neue Antwort erstellen" dürfte ja wohl nur den Text ohne Umbrüche versenden. Außerdem trat der Fehler bei mir durchaus auch bei sehr kurzen Zeilen auf. Und die Fehler waren sehr zuverlässig, egal ob Neuanlegen oder Editieren eines Beitrags.

Beitrag #4

Hier eine Internetseite zu den meist ueblichen Codierungen.

EUC-JIS, Shift-JIS, Unicode, JIS-Code, und vieles mehr.
http://ftp.ftp.cc.monash.edu.au/pub/nihongo/cjkvconv.pl

Beitrag #5

@Hallo,
Hier noch ein Tip. Fuer den Fall einer will mal umrechnen was aus Hexadezimal in Dezimal und umgekehrt so rauskommt.
Wo steht dieser Rechner.
Na ja, wieder mal wadokuwa mit der :-Taste kommt man an dieses Tool ran.
Aus der Zahl 12364 wird Hexadezimal 304c.

Tschuess.

Beitrag #6

Auch wenn dieser Eintrag etwas spät kommt, aber ichmöchte trotzdem etwas zu den Codierungen sagen. Es sind mir jetzt schon zu viele falsche Aussagen darüber über den Weg gelaufen.

Unicode-Zeichen weden zwar immer wieder als 2-Byte Zeichen bezeichnet. Dies glit jedoch nur für den "Standard"-Teil der CJK und Kana (Extention A). Die Extention B sind bereits 4-Byte Zeichen!

Ich habe bei meiner Webseite sehr viel mit den Codierungen probiert. Und ich bin aus bereits oben beschriebenen Problemen (Umlaute) bei der einzig funktionierenden Lösung gelandet. Dem Unicodesystem. Da ich die Zeichen aber nicht Hexadezimal codiert eingebe (macht einfach zu viel Arbeit) sondern als 8-bit-Zeichengruppe (UTF-8) ist mir sehr schnell aufgefallen, das die an für sich 2-Byte Zeichen alle mit 3! Zeichen übersetzt sind. Die der Extention B sind sogar mit 4 (oder 5) -Byte gespeichert.

Deshalb denke ich ist die Aussage, das Unicode 2Byte Zeichen hat, nicht ganz richtig. Und SJIS hat zwar immer 2Byte, verträgt sich aber weder mit deutschen Umlauten noch mit Formularen, jedenfalls bei mir.