Beitrag #11

die Ursache des Problems ist einfach der Meta-Tag, wie frostschutz schon geschrieben hat. Das Problem ist bekannt, irgendwo haben wir schon mal darüber diskutiert. Apple wird da, so fürchte ich, keine neuen Erkenntnisse bringen können. Standardmäßig ist der Code bei Rapidforen ISO. Wir haben ihn einmal umgestellt auf UTF-8, leider gab es aber dann bei vielen Leuten Probelem mit den alten Beiträgen. Weil davon weniger betroffen waren als Apple-User, haben wir dann wieder auf ISO zurückgestellt.

Ich benutze übrigens auch auf dem Mac Firfox, weil ich die Suchmaschineneinbindung eleganter finde. Außerdem kommt er mir fast ein wenig schneller vor als Safari.

Beitrag #12

Ma-kun,
da es Firefox fuer den Mac gibt, schlage ich vor nichts zu aendern.
Ich bin zufrieden was die einzelnen Programme koennen.
Fuer das Netzwerk, benutze ich ausschliesslich Firefox. Und da dies funktioniert, bleibe ich auch dabei.


Ich hab mir den Quellcode angesehen.
ISO-8859-1 ist die Schrift die hier verwendet wird.
Sollte man denn keine solche Schrift fuer den Mac installieren.
Ich bin Neu, was Mac angeht. Und eine Erfahrung von xx Jahren PC ist so leicht nicht mit Mac zu erzielen.
Dazu benoetigt man Zeit.

Deshalb weiss ich auch nicht, wie man eine solche Schrift in den Mac und wohin installieren muss, damit die Einstellungen daraufhin zugreifen koennen.

ISO-8859-1 gibt es wie Sand am Meer.

Beitrag #13

ISO 1 ist keine Schrift. Die Notation gibt an, welcher Zeichensatz benutzt werden soll. Kanji und Kana sind leider im ISO - Zeichensatz nicht enthalten. Das beste wäre UTF-8, das so ziemlich alle aktuell verwendeten Zeichen der Welt enthält. Aber wie gesagt, es gibt dann Probleme mit dem Lesen der alten Beiträge.

Beitrag #14

Welche Probleme hatte das denn bei den alten Beiträgen ausgelöst? Umlaute futsch? Oder wurden in alten Beiträgen auch andere Japanisch-Zeichensätze verwendet?

Die Umlaute könnte man ganz eventuell korrigieren. Das Rapidforum bietet ja eine Textersetzung. Die ist zwar eigentlich für Smileys gedacht, aber vielleicht funktioniert sie ja auch mit Umlauten...

Beitrag #15

Die Umlaute und das "ß" waren futsch. Es erschien bei allen stattdessen ein Fragezeichen. Wie könnte man der Textersetzung denn erklären, wann sie was durch was ersetzen soll?

Beitrag #16

funktioniert nicht, oder?

Beitrag #17

Nein funktioniert nicht.
Auch wenn ich Unicode einstelle und Netzwerk sendet ISO8859-1 was ja Europaweit die Norm fuer Deutsch und deren öäü ist. Bekomme ich hier Kanji oder sonstige Zeichen angezeigt.

Da kommt mir eine Idee.
Kann man 2 (zwei) Charset in einer Seite einbauen?
Oder hebt der zweite Charset den ersten Automatisch auf?
http://forum.de.selfhtml.org/archiv/2006/2/t123246/


Oder kann man durch ein : seek : Symbol eine Codierung einbauen damit man dann nur die Kanji dahinter stellt und mit [ / : seek : ] diesen dann wieder ausschaltet?

Mit
[ CODE ]
geht es auch nicht.
[ / CODE ]

[CHARSET=UTF8]
?????????????????OK???
[/CHARSET=UTF8]

Da hab ich noch folgenden Text gefunden.
ISO8859-15, Similar to ISO8859-1, but includes euro symbol support. SJIS, Shift JIS KANJI. big5, Big 5. TACTIS, Thai Industrial Standard ...

http://h30097.www3.hp.com/unix/i18n.htm

Kann das vielleicht helfen?

Beitrag #18

(17.08.07 23:10)zongoku schrieb:Kann man 2 (zwei) Charset in einer Seite einbauen?

Nein, kann man nicht. Man kann bei Formularen allerdings gesondert angeben, mit welchem Zeichensatz der Browser den Text an den Server schicken soll. Aber eine HTML-Seite, die nicht durchgehend den gleichen Zeichensatz verwendet (und es sich nicht um separate Seiten in Frames handelt), ist nicht darstellbar, auch mit manueller Umstellung des Zeichensatzes nicht.

Beitrag #19

@Makun

Bei Iso 8859-1 ist z.b. das ä E4 (also 11100100), das Problem ist dabei, dass es das in UTF-8 so nicht gibt. Nur Ascii-Buchstaben haben einen Byte, und die müssen eine 0 als erstes Bit haben. Alle die eine 1 am Anfang haben sind Zeichen mit mehreren Bytes. Dieses Byte wäre jetzt das Anfangsbyte von einem Zeichen, das 3 Byte einnimmt (das sind z.b. Kanji). Deswegen ist es vielleicth etwas schwierig, das durch suchen/ersetzen zu machen, weil dieses Byte soweit erstmal kein gültiges UTF-8-Byte ist, soweit ich weiß.

Es gibt da aber Programme, die das automatisch konvertieren. Unter Linux hab ich da recode (vielleicht gibts das auch beim mac), dem gibt man die Ursprungskodierung und die Zielkodierung und eine Datei, und dann wird das konvertiert.

Allerdings wüsste ich jetzt nicht, wie man das automatisch einbauen könnte. Kann man vielleicht die ganze Datenbank exportieren, verändern und wieder hochladen?

Der Befehl ist im Grunde ganz einfach:

recode latin1..u8 < eingabedatei > ausgabedatei

Kanji und so wären dann denke ich nicht betroffen, wenn man das konvertiert, weil die ja sowieso nicht in UTF-8 hier gespeichert werden

Edit: hab mir grade mal irgendeinen Forumseintrag auf der Festplatte gespeichert, die html-datei dann durch recode laufen lassen und dann wieder angezeigt. Ergebnis: Alles funktioniert (ich musste nur in Firefox die Kodierung einmal manuell auf UTF-8 umstellen, weil die in der HTML-Datei ja noch auf ISO-8859-1 steht). Auch Kanji gehen. Das hängt damit zusammen, weil ein Kanji halt nicht direkt in UTF-8 hier gespeichert werden kann, sondern das escaped werden muss. z.b. ist U+9F8D 龍 = & #40845; (zwischen & und # ist keine Lücke, aber musste ich jetzt machen, damit der das hier anzeigt). Und da das nur Ascii ist, wird das von einer Kodierung nicht betroffen.
Der Vorteil von UTF-8 ist dann auch noch, dass man bei Kanji viel platz sparen würde (gut, das würde wahrscheinlich durch den erhöhten Platzgebrauch der Umlaute dann wohl wieder zunichte gemacht werden... ). Dann braucht man für so ein Kanji nur noch 3 Byte, keine 8.
Aber ich hab mal gelesen, ein deutscher Text bläht sich durch UTF-8 um ca. 5% auf wegen den Umlauten. ich denke mal, das geht noch.

Das Problem ist imho nur, an die Rohdaten in der Datenbank heranzukommen. Die müsste man dann einmal alle konvertieren und dann noch die Kodierung des Forums einstellen, ich denke, dann geht das.

Mit Safari würden dann bei alten Posts die Kanji zwar auch nicht besser angezeigt, denke ich, aber zumindest bei neuen Posts nach der Umstellung ginge das dann, weil dann die Kanji direkt in UTF-8 gespeichert werden könnten. Aber viellecith gibts ja auch eine Möglichkeit, dieses &#-Dingsbums automatisch in richtiges UTF-8 umzuwandeln.

@Zongoku
Nein, eigentlich hilft kein Zeichensatz außer Unicode. Die haben alle irgendwelche Probleme. Daher wurde ja Unicode entworfen. Ich finde es nur blöd, dass sich so viele Webseiten immer noch an ISO-8859-1 klammern. Das hat wirklich nur Nachteile. jeder Webbrowser unterstützt Unicode. Gibt eigentlich keinen Grund, das nicht zu benutzen.

Beitrag #20

(18.08.07 16:41)Hellstorm schrieb:Kann man vielleicht die ganze Datenbank exportieren, verändern und wieder hochladen?

Bei Rapidforum hat man keinen Zugriff auf die Datenbank... zwecks Kundenbindung

Und ob das mit dem Suchen/Ersetzen klappt, müsste man halt mal ausprobieren... habe leider meinen rapidforum Testaccount verschlampt.

Zitat:weil ein Kanji halt nicht direkt in UTF-8 hier gespeichert werden kann, sondern das escaped werden muss

Ach du lieber Himmel, so genau hatte ich mir das gar nicht angeschaut. Wenn die Kanji alle mit HTML-Codes escaped sind, dann stimmt der ISO-8859 Zeichensatz im Meta-Tag ja sogar. Die große Frage ist dann, wer oder was diese Zeichen in HTML-Sequenzen umwandelt. Werden sie vom Browser so an das Forum geschickt, oder nimmt das Forum UTF-8 Text vom Browser an und escaped diesen selbst?

EDIT: Gerade getestet, der Firefox schickt die Kanji schon escaped an das Forum, www-urlencoded schimpft sich das wohl...