nicht angemeldet
Gunnar Bittersmann
dedlfix
Der Martin
Gunnar Bittersmann
Der Martin
Gunnar Bittersmann
dedlfix
Gunnar Bittersmann
Gunnar Bittersmann
Der Martin
dedlfix
Felix Riesterer
Hallo,
nachfolgende Website füllt sich per Sprachkennzeichen aus einer Datenbank
www.badener-weinkeller.de/baseportal/speisen&language=RU
Die kyrillischen Zeichen werden auch korrekt dargestellt.
Nun stellt mein Provider serverseitig ein Tool namens HTMLDOC zur Verfügung, mit dem ich aus den Daten on the fly ein PDF-Dokument erstellen kann.
Leider werden hier bestimmte Zeichen falsch umgesetzt -> pdf.baseportal.de/?url=http://www.badener-weinkeller.de/baseportal/speisen%26cmd%3ddo_pdf%26language%3dRU&bodycolor=ffffff&footer=d/T
Kennt jemand HTMLDOC bzw. ist dieses Problem bekannt und hat vielleicht jemand einen Lösungsansatz?
Danke und Gruss
Claus
Tach,
Kennt jemand HTMLDOC bzw. ist dieses Problem bekannt und hat vielleicht jemand einen Lösungsansatz?
ich würde mal vermuten, das liegt daran, dass die Zeichen als Referenzen und nicht als wirklicher Text in der Datei stehen. Hast du mal versucht das Dokument mit einer passenden Kodierung (UTF-8!) und ohne Referenzen in ein PDF umzuwandeln?
mfg
Woodfighter
Hallo,
was meinst Du in diesem Fall mit Referenzen?
Die Daten wurden teils über Tastatur, teils aus einem Worddomument des russischen Übersetzers herauskopiert, in die Datenbank eingegeben.
Was das abspeichern betrifft siehe Antwort an Felix.
Gruss Claus
Tach,
Kennt jemand HTMLDOC bzw. ist dieses Problem bekannt und hat vielleicht jemand einen Lösungsansatz?
ich würde mal vermuten, das liegt daran, dass die Zeichen als Referenzen und nicht als wirklicher Text in der Datei stehen. Hast du mal versucht das Dokument mit einer passenden Kodierung (UTF-8!) und ohne Referenzen in ein PDF umzuwandeln?
mfg
Woodfighter
Tach,
was meinst Du in diesem Fall mit Referenzen?
statt "Предложение недели" steht im Quelltext "Предложение недели" das sind Zeichenreferenzen und sie sind in deinem Falle nötig, da du die Seite als ISO-8859-1 auslieferst. Wie du das änderst, ist recht gut bei Gunnars Link beschreiben.
mfg
Woodfighter
Tach,
»»
Hallo,
was meinst Du in diesem Fall mit Referenzen?
statt "Предложение недели" steht im Quelltext "Предложение недели" das sind Zeichenreferenzen und sie sind in deinem Falle nötig, da du die Seite als ISO-8859-1 auslieferst. Wie du das änderst, ist recht gut bei Gunnars Link beschreiben.
Habe ich mir angeschaut, erschien mir auch nachvollziehbar,
habe also den meta auf utf-8 gesetzt und dann die Seite mit einem Einfacheditor aufgerufen und als UTF-8 abgespeichert,
Ergebnis
www.badener-weinkeller.de/baseportal/speisen2&language=RU im Vergleich zu vorher www.badener-weinkeller.de/baseportal/speisen&language=RU
und das ist der PDF-Output http://pdf.baseportal.de/?url=http://www.badener-weinkeller.de/baseportal/speisen2%26cmd%3ddo_pdf%26language%3dRU&bodycolor=ffffff&footer=d/T im Vergleich zu vorher http://pdf.baseportal.de/?url=http://www.badener-weinkeller.de/baseportal/speisen%26cmd%3ddo_pdf%26language%3dRU&bodycolor=ffffff&footer=d/T
Von einer Verbesserung würde ich da nicht sprechen
mfg
Woodfighter
Gruss
Claus
@@Claus:
nuqneH
Von einer Verbesserung würde ich da nicht sprechen
Du hast auch immer noch Zeichenreferenzen im Quellcode, keine kyrillischen Zeichen.
Qapla'
PS: Zitiere bitte sinnvoll, nicht alles!
Hallo,
habe es jetzt geschafft, dass die Daten nun auch in der Datenbank korrekt abgespeichert werden und damit auch im Quelltext in "Klartext" und nicht als Referenzen angezeigt werden.
Also ist das Problem mit der korrekten Anzeige der kyrillischen Zeichen gelöst. Allerdings werden nun im Browser die deutschen Umlaute mit einem Ersatzzeichen (Schwarzes Karo mit Fragezeichen) dargestellt.
Wie kommt das zustande bzw. wie kann ich das fixen?
Danke und Gruss
Claus
Hi!
Also ist das Problem mit der korrekten Anzeige der kyrillischen Zeichen gelöst. Allerdings werden nun im Browser die deutschen Umlaute mit einem Ersatzzeichen (Schwarzes Karo mit Fragezeichen) dargestellt.
Das passiert üblicherweisen, wenn die Umlaute ISO-8859-1-kodiert sind und das Dokument als UTF-8 ausgeliefert wird. Letzteres willst du ja für die kyrillischen Zeichen haben.
Wie kommt das zustande bzw. wie kann ich das fixen?
An der Quelle der Umlaute besteht noch Konvertierungsbedarf. (Auch andere Ursachen sind denkbar.)
Lo!
Hallo,
was meinst Du in diesem Fall mit Referenzen?
statt "Предложение недели" steht im Quelltext "Предложение недели" das sind Zeichenreferenzen und sie sind in deinem Falle nötig, da du die Seite als ISO-8859-1 auslieferst.
Habe ich mir angeschaut, erschien mir auch nachvollziehbar
hmm, den Eindruck habe ich nicht.
habe also den meta auf utf-8 gesetzt und dann die Seite mit einem Einfacheditor aufgerufen und als UTF-8 abgespeichert
Da hast du ja Glück gehabt, dass dein Server im HTTP-Header keine Angabe zur Zeichencodierung mitsendet, sonst wäre die meta-Angabe völlig bedeutungslos.
Aber was immer du gemacht hast - die UTF-8-BOM im geänderten Dokument deutet zwar auf eine UTF-8-Codierung hin, die Fehler/Ersatzzeichen U+FFFD in der Nähe des Wortes "Remoulade" ebenfalls. Aber die unsäglichen numerischen Zeichenreferenzen sind immer noch drin.
und das ist der PDF-Output http://pdf.baseportal.de/?url=http://www.badener-weinkeller.de/baseportal/speisen2%26cmd%3ddo_pdf%26language%3dRU&bodycolor=ffffff&footer=d/T
Sieht aus, als hätte dein PDF-Generator nicht die leiseste Ahnung davon, dass es sich beim Quellmaterial um UTF-8 handelt, und versucht alle Bytes als einzelne Zeichen zu interpretieren. Immerhin löst er wenigstens die numerischen Zeichenreferenzen auf, das scheint also nicht das Problem zu sein. Man müsste ihm nur "irgendwie" mitteilen, dass es UTF-8 ist.
So long,
Martin
Hallo Martin,
Da hast du ja Glück gehabt, dass dein Server im HTTP-Header keine Angabe zur Zeichencodierung mitsendet, sonst wäre die meta-Angabe völlig bedeutungslos.
Aber was immer du gemacht hast - die UTF-8-BOM im geänderten Dokument deutet zwar auf eine UTF-8-Codierung hin, die Fehler/Ersatzzeichen U+FFFD in der Nähe des Wortes "Remoulade" ebenfalls. Aber die unsäglichen numerischen Zeichenreferenzen sind immer noch drin.
»»
Also was habe ich dann bei der Umsetzung (Setzen und Abspeichern als UTF-8) falsch gemacht bzw. unterlassen?
und das ist der PDF-Output http://pdf.baseportal.de/?url=http://www.badener-weinkeller.de/baseportal/speisen2%26cmd%3ddo_pdf%26language%3dRU&bodycolor=ffffff&footer=d/T
Sieht aus, als hätte dein PDF-Generator nicht die leiseste Ahnung davon, dass es sich beim Quellmaterial um UTF-8 handelt, und versucht alle Bytes als einzelne Zeichen zu interpretieren. Immerhin löst er wenigstens die numerischen Zeichenreferenzen auf, das scheint also nicht das Problem zu sein. Man müsste ihm nur "irgendwie" mitteilen, dass es UTF-8 ist.
Was den PDF-Generator angeht, wenn ich mich mal direkt an den Hersteller
So long,
Martin
Danke und Gruss
Claus
Tach,
Also was habe ich dann bei der Umsetzung (Setzen und Abspeichern als UTF-8) falsch gemacht bzw. unterlassen?
du hast die Zeichenreferenzen nicht durch Text ersetzt. Entweder sie stehen schon als Referenz in der Datenbank, dann sollte sie da schleunigst ersetzt werden oder deine Ausgabe wird durch irgendwas gejagt, das sie erzeugt.
Sieht aus, als hätte dein PDF-Generator nicht die leiseste Ahnung davon, dass es sich beim Quellmaterial um UTF-8 handelt, und versucht alle Bytes als einzelne Zeichen zu interpretieren. Immerhin löst er wenigstens die numerischen Zeichenreferenzen auf, das scheint also nicht das Problem zu sein. Man müsste ihm nur "irgendwie" mitteilen, dass es UTF-8 ist.
Ich vermute mal der Generator wird bei fehlendem HTTP-Header Iso als Fallback annehmen und nicht im Meta-Tag nachschauen.
mfg
Woodfighter
Also was habe ich dann bei der Umsetzung (Setzen und Abspeichern als UTF-8) falsch gemacht bzw. unterlassen?
1. Du hast eine ISO-Datei unter utf-8 abgespeichert aber eigentlich hättest du das Ding konvertieren müssen. Und ja es gibt Editoren die konvertieren können meiner ist der SC-Unipad. Aber der kostet ...
2. Der charset gehört in den HTTP-Header.
@@Wolfgang:
nuqneH
- Du hast eine ISO-Datei unter utf-8 abgespeichert
Was (von evtl. BOM abgesehen) nichts geändert hat.
Eine ISO-8859-1 codierte Textdatei, die nur aus ASCII-Zeichen besteht, unterscheidet sich in nichts von einer ohne BOM UTF-8-codierten Datei mit demselben Text.
Qapla'
Guten Tag,
habe ein ähnlich gelagertes Problem,
habe diesen Thread aufmerksam verfolgt, bin aber jetzt etwas durcheinander ob der verschiedenen Aussagen: Sollte man nun grundsätzlich alles Websiten in UTF-8 abspeichern? Was bedeutet, den charset in den HTTP-Header zu schreiben, könnte ich hierzu bitte ein Beispiel haben? Un d was ist ein BOM?
Danke für Eure Unterstützung!
Merci Beat
Hallo,
habe diesen Thread aufmerksam verfolgt, bin aber jetzt etwas durcheinander ob der verschiedenen Aussagen
so verschieden sind die gar nicht. ;-)
Sollte man nun grundsätzlich alles Websiten in UTF-8 abspeichern?
Wenn alle Komponenten, die man verwendet, damit umgehen können, ist das keine schlechte Idee. Dann hat man zumindest dafür gesorgt, dass alle Zeichen eindeutig sind, und man hat eine einheitliche, durchgängige Festlegung, die einem manche Stolperfalle erspart.
Was bedeutet, den charset in den HTTP-Header zu schreiben, könnte ich hierzu bitte ein Beispiel haben?
HTTP verschickt immer Datenblöcke bestehend aus Header und Nutzdaten (wobei in einigen Fällen die Länge der Nutzdaten 0 sein kann). Der Header enthält dabei sowohl technische Angaben über den Datentransfer, wie etwa den Statuscode vom Server, als auch Metainformationen über die folgenden Nutzdaten:
* Art der Daten (Content-Type)
* Zeichencodierung bei textbasierten Formaten
* Länge des Datenblocks (Anzahl der Bytes)
* Transfer-Codierung (z.B. gzip)
* Caching-Informationen
Diese Informationen kann man teilweise durch die Serverkonfiguration beeinflussen; wenn man eine serverseitige Scriptsprache wie z.B. PHP oder Perl verwendet, kann man diese Headerdaten auch komplett selbst erzeugen - wenn man weiß, was man tut.
Unter anderem ist es eben empfehlenswert, bei textbasierten Dokumenten (HTML, Plaintext, CSS, Javascript) auch die verwendete Textcodierung anzugeben. In manchen Fällen ist das sogar die einzige Stelle, an der man diese Information unterbringen kann, denn beispielsweise reine Textdateien haben sonst keine Möglichkeit.
Un d was ist ein BOM?
So long,
Martin
@@Beat:
nuqneH
Sollte man nun grundsätzlich alles Websiten in UTF-8 abspeichern?
Ja (zumindest solche in lateinischer, kyrillischer, griechischer, … Schrift).
Was bedeutet, den charset in den HTTP-Header zu schreiben
Zum Beispiel das.
Un d was ist ein BOM?
Ein BOM ist ein BOM ist ein BOM. Und was ist LMGTFY?
Merci Beat
Und wer schreibt hier als Beat? Offenbar nicht Beat.
Qapla'
Hallo Gunnar,
Merci Beat
Und wer schreibt hier als Beat? Offenbar nicht Beat.
vielleicht ist "Beat" ein seltener Vorname - einzigartig ist er aber sicher nicht, und unser Schweizer Stammgast ist sicher nicht der einzige, der so heißt.
So long,
Martin
Und wer schreibt hier als Beat? Offenbar nicht Beat.
Nein, den hier registrierten Beat erkennt man am Anhang ;)
mfg Beat
heute mit:
Lese/Hör/Sehtipp:
Die NATO
<o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
@@Beat:
nuqneH
Nein, den hier registrierten Beat erkennt man am Anhang ;)
Der hier registrierte Beat hat seinen Namen nicht geschützt?
Man könnte die mit Beat (dem anderen) verwechseln. Das bekäme dir nicht gut.
Qapla'
Hallo :)
Nein, den hier registrierten Beat erkennt man am Anhang ;)
Der hier registrierte Beat hat seinen Namen nicht geschützt?
Man könnte die mit Beat (dem anderen) verwechseln. Das bekäme dir nicht gut.
<o(((°> ><o(((°> ><o(((°> ><o(((°>
<°)))o>< <°)))o>< <°)))o>< <°)))o><
Der Geruch nach Surströmming im Archiv ist unverwechselbar.
mfg
cygnus
Hi!
Sollte man nun grundsätzlich alles Websiten in UTF-8 abspeichern?
Website ist nicht Webseite.
Ja (zumindest solche in lateinischer, kyrillischer, griechischer, … Schrift).
Diese Aussage ist mir nicht verständlich/eindeutig genug. Dass das "ja" aufgrund der Einschränkung schon logisch falsch ist, ist nicht so tragisch. Aber das "…" bedarf einer Erläuterung. Das schließt nämlich auch CJK und anderes mit ein, das mit 3 und 4 Byte kodiert wird. Oder anders gesagt: "…" schließt diese Zeichen nicht aus. Und das wolltest du ja mit deiner Einschränkung zum Ausdruck bringen. Außerdem müsste in die Einschränkung noch ein "vorwiegend" eingebaut werden, denn wenn ein Text in lateinischen Buchstaben drei chinesische Zeichen enthält, lohnt sich eine Umcodierung nach UTF-16 auch nicht richtig.
Die ganze Betrachtung berücksichtigt allerdings nur die Effizienz der Texte eines Webdokuments. Wenn viel Markup (verwendet ASCII-Zeichen) enthalten ist, kommt man wieder mit UTF-8 günstiger. Wenn das Backend (PHP, DBMS, etc.) nicht fähig ist, mit UTF-16 umzugehen, ist es auch wieder ein Punkt, der gegen die Verwendung von UTF-16 sprechen kann. (MySQL beispielsweise kann zwar UTF-16 (bzw. UCS-2) als Speicherformat verwenden, nicht jedoch als Übertragungsformat.)
Zurück zur eigentlichen Frage, die eher auf einen Vergleich mit Ein-Bye-Kodierungen wie ISO-8859-1 und Win-1252 abzielt: Es kann natürlich auch Gründe gegen UTF-8 geben. Beispielsweise wenn man für die Datenverarbeitung ein altes System verwenden muss, das partout nicht mit UTF-8 umgehen kann, die Daten nicht nur durchreicht sondern unter Umständen sogar UTF-8-Byte-Sequenzen auseinander reißt. Für neue Projekte ist es in der Regel jedoch sinnvoll, zu betrachten, ob man UTF-8 verwenden kann und dies dann zu tun, wenn nichts gravierendes dagegenspricht.
Lo!
@@dedlfix:
nuqneH
Diese Aussage ist mir nicht verständlich/eindeutig genug. […] das "…" bedarf einer Erläuterung.
Die hielt ich an dieser Stelle nicht für zwingend erforderlich, aber an jener.
Qapla'
Was bedeutet, den charset in den HTTP-Header zu schreiben, könnte ich hierzu bitte ein Beispiel haben?
Da gibt es für die .htaccess verschiedene Anweisungen und ob das dann geht, das sieht man zum Beispiel am Websniffer. So kann ich meine Webseite auch über den Sniffer aufrufen. Das kann ich natürlich nicht nur mit der html resp. der php-Seite tun, sondern auch mit der CSS-Datei und der Sniffer sagt mir dann mit der Zeile "Content-Type: text/css; charset=utf-8" dass die Seite in utf-8 ausgeliefert wird.
Eine solche Auslieferung - also eine Info über die Seite bevor sie gesendet wird - ist wesentlich aussagekräftiger als ein Metatag oder irgend was anderes. Der Browser stellt diesen Wert automatisch ein, ohne weitere Prüfungen. Der Seitenaufbau ist schneller usw.
Allgemein reicht
AddDefaultCharset utf-8
Aber für die css braucht man noch:
AddType 'text/css; charset=utf-8' .css
Im übrigen kann man damit auch prüfen, ob die Datei gezippt wird, also komprimiert ausgeliefert wird. Das reduziert die Datenmenge und macht auch den Seitenaufbau schneller -> Siehe: Page-Speed-Probleme mit CSS-Dateien von Textpattern
Also mit der .htaccess und einem Sniffer kann man viel verbessern an seiner Seite.
Und was ist ein BOM?
Die ersten beiden Bytes in der utf-8 Datei können diese als solche markieren. Das ist eine Info, die einem Editor sagt: Hier kommt utf-8. Im Web sollte man das nicht verwenden. Es ist jedenfalls nach meinen Infos kein wirklicher Standard.
Danke Martin und Wolfgang für Eure konstruktiven und hilfreichen Antworten,
es ist gut zu wissen, dass es Euch gibt ...
... neben den selbstverliebten Oberlehrern und Brandstiftern wie Gunnar (und Cheatah), die unter dem Deckmäntelchen der Hilfe zur Selbsthilfe das Forum für ihre eigenen Zwecke missbrauchen
Beat aus Lörrach
Hallo,
es ist gut zu wissen, dass es Euch gibt ...
... neben den selbstverliebten Oberlehrern und Brandstiftern wie Gunnar (und Cheatah), die unter dem Deckmäntelchen der Hilfe zur Selbsthilfe das Forum für ihre eigenen Zwecke missbrauchen
du tust ihnen Unrecht.
Beide sind gern bereit zu helfen, stellen aber zugegebenermaßen auch hohe Ansprüche an die Bereitschaft der Fragesteller, im Rahmen ihrer Möglichkeiten selbst an der Lösung mitzuwirken, mitzudenken und sich selbständig zu informieren, gegebenen Stichworten selbst nachzugehen.
Auch meine Hilfsbereitschaft steigt übrigens in dem Maß, wie ich merke, dass die Hinweise auch auf fruchtbaren Boden fallen. Wenn ich aber merke, dass der Fragesteller keinerlei Initiative zeigt, sich einfach nur Lösungen vorsetzen lässt oder die gegebenen Hinweise einfach ignoriert, verliere ich auch die Lust. Das geht vermutlich vielen so.
Schönes Wochenende,
Martin
Hallo :)
Schönes Wochenende,
Martin
--
Programmierer (m), seltener auch P~in (w):
Irdische, i.a. humanoide Lebensform, die in einem komplizierten biochemischen Prozess Kaffee, Cola und Pizza in maschinenlesbaren Programmcode umwandelt.
P~ bilden gelegentlich mit ihresgleichen kleine Gruppen, sogenannte Communities, sind aber ansonsten meist scheue Einzelgänger.
P~ sind vorwiegend nachtaktiv und ohne technische Hilfsmittel nur eingeschränkt lebensfähig.
mfg
cygnus
@@Beat (der andere):
nuqneH
... neben den selbstverliebten Oberlehrern und Brandstiftern wie Gunnar (und Cheatah)
Was bist du denn für einer? Zu dumm, um selbst zu suchen, zu faul, um einen Artikel durchzulesen, aber die große Klappe aufreißen?
Qapla'
Hi!
Eine solche Auslieferung - also eine Info über die Seite bevor sie gesendet wird - ist wesentlich aussagekräftiger als ein Metatag oder irgend was anderes.
Sie ist nicht aussagekräftiger. (Die Aussagekraft hängt vom Wahrheitsgehalt ab. Aufgrund von Fehlkonfiguration kann die Angabe schließlich auch falsch sein.) Sie hat lediglich eine höhere Priorität gegenüber der Angabe im Meta-Element. Letzteres benötigt man zusätzlich für den Fall, dass ein Webdokument lokal abgespeichert wird, denn das geschieht ohne HTTP-Header. Die Meta-Angabe ist dann die einzig verfügbare.
Der Browser stellt diesen Wert automatisch ein, ohne weitere Prüfungen.
Was für Prüfungen meinst du? Auch wenn nur die Meta-Angabe vorhanden ist, stellt sich der Browser auf diesen Wert ein. Nur wenn gar nichts vorhanden ist, fängt er an zu raten oder nimmt eine möglicherweise unpassende Default-Einstellung.
Der Seitenaufbau ist schneller usw.
Falls überhaupt ein Unterschied messbar ist, so glaube ich nicht, dass der irgendeine gravierende Rolle spielt. Wichtiger ist hier der technische Aspekt (Vorhandensein und Priorität). Und welche Gedankengänge verstecken sich hinter dem "usw."?
Und was ist ein BOM?
Die ersten beiden Bytes in der utf-8 Datei können diese als solche markieren.
Bei UTF-8 sind es 3 Bytes.
Das ist eine Info, die einem Editor sagt: Hier kommt utf-8. Im Web sollte man das nicht verwenden. Es ist jedenfalls nach meinen Infos kein wirklicher Standard.
Ab HTML5 ist die Möglichkeit einer BOM vorgesehen: Writing HTML documents.
Lo!
Eine ISO-8859-1 codierte Textdatei, die nur aus ASCII-Zeichen besteht, unterscheidet sich in nichts von einer ohne BOM UTF-8-codierten Datei mit demselben Text.
Das ist falsch. Alle Zeichen oberhalb von 7F werden falsch dargestellt und das war hier der Fall.
@@Wolfgang:
nuqneH
Eine ISO-8859-1 codierte Textdatei, die nur aus ASCII-Zeichen besteht, unterscheidet sich in nichts von einer ohne BOM UTF-8-codierten Datei mit demselben Text.
Das ist falsch.
Nein, meine Aussage war richtig …
Alle Zeichen oberhalb von 7F werden falsch dargestellt und das war hier der Fall.
… sie bezog sich auf ASCII-Zeichen. Es gibt keine ASCII-Zeichen oberhalb von U+007F.
Qapla'
… sie bezog sich auf ASCII-Zeichen. Es gibt keine ASCII-Zeichen oberhalb von U+007F.
Das ist falsch. In iso 8859-1 und folgende (iso 8859-n) sind definiert bis FF. Nur ist in utf-8 das höchste Bit immer auf 1 gesetzt und das impliziert, dass das folgende Bit mitausgewertet werden muss.
, nur sind die Zeichen zwischen U+0080 und U+00FF anders definiert als die Zeichen 80 bis FF von iso 8859-1.
Das deutsche Ä zum Beispiel hat in iso 8859-1 den Wert C4. In Unicode hat es auch den Wert U+00C4, nur müsste man dort die Zeichenfolge C400 schreiben wenn ich das so richtig in Erinnerung habe.
@@Wolfgang:
nuqneH
… sie bezog sich auf ASCII-Zeichen. Es gibt keine ASCII-Zeichen oberhalb von U+007F.
Das ist falsch.
Erzähl bitte keine Unsinn! Informiere dich!
In iso 8859-1 und folgende (iso 8859-n) sind definiert bis FF.
8 Bit eben. Davon war aber nicht die Rede, sondern von 7 Bit.
Das deutsche Ä zum Beispiel hat in iso 8859-1 den Wert C4. In Unicode hat es auch den Wert U+00C4, nur müsste man dort die Zeichenfolge C400 schreiben wenn ich das so richtig in Erinnerung habe.
Unterscheide zwischen Zeichensatz (Unicode) und Zeichencodierung (du meinst UTF-16)!
Es gibt UFT-16LE (little endian, Bsp. C4 00) und UTF-16BE (big endian, Bsp. 00 C4). Eben dazu dient ja das BOM, beides voneinander zu unterscheiden.
Qapla'
Erzähl bitte keine Unsinn! Informiere dich!
Ich habe die unicode-Seite referenziert und die ist für mich relevant. Sorry aber meine Software resp. meine Seiten müssen funktionieren und nicht Wikipedia-Kompatibel sein.
8 Bit eben. Davon war aber nicht die Rede, sondern von 7 Bit.
Ich will nicht in Abrede stellen, dass ASCII irgendwann mal ein 7 Bit Code war. Nach der Unicode-Seite ist er das nicht mehr.
Das deutsche Ä zum Beispiel hat in iso 8859-1 den Wert C4. In Unicode hat es auch den Wert U+00C4, nur müsste man dort die Zeichenfolge C400 schreiben wenn ich das so richtig in Erinnerung habe.
Unterscheide zwischen Zeichensatz (Unicode) und Zeichencodierung (du meinst UTF-16)!
Ich habe das Wort Zeichensatz gar nicht verwendet. Ich habe von der Zeichenfolge gesprochen und aus dem Zusammenhang sollte klar sein, dass die Zeichenfolge C400 die Folge der Bytes "C", "4", "0" und "0" ist.
Es gibt UFT-16LE (little endian, Bsp. C4 00) und UTF-16BE (big endian, Bsp. 00 C4). Eben dazu dient ja das BOM, beides voneinander zu unterscheiden.
Wobei das big endian der Defaultwert ist und damit weggelassen werden kann
@@Wolfgang:
nuqneH
Ich will nicht in Abrede stellen, dass ASCII irgendwann mal ein 7 Bit Code war. Nach der Unicode-Seite ist er das nicht mehr.
Da habe ich meine Zweifel. Aber das sagten ja auch schon Woodfighter und dedlfix.
Das deutsche Ä zum Beispiel hat in iso 8859-1 den Wert C4. In Unicode hat es auch den Wert U+00C4, nur müsste man dort die Zeichenfolge C400 schreiben wenn ich das so richtig in Erinnerung habe.
Unterscheide zwischen Zeichensatz (Unicode) und Zeichencodierung (du meinst UTF-16)!
Ich habe das Wort Zeichensatz gar nicht verwendet.
Du erwähntest Unicode. Unicode ist ein Zeichensatz.
Weiter schriebst du: „müsste man dort [in Unicode] die Zeichenfolge C400 schreiben“.
Nein, müsste man nicht; sondern das Zeichen U+00C4 'Ä' wird in UTF-16BE durch die Bytefolge C4 00 codiert.
Du beziehst dich mit „dort“ (womit Unicode gemeint war) auf die Zeichencodierung. Unicode ist aber keine Zeichencodierung.
Nochmals: Unterscheide zwischen Zeichensatz und Zeichencodierung!
Ich habe von der Zeichenfolge gesprochen und aus dem Zusammenhang sollte klar sein,
dass dir der Begriff „Zeichenfolge“ nicht verständlich ist. 'abc' ist eine Zeichenfolge, ebenso 'αβγ', 'абв', 'אבג' (wobei letztere die Folge der Zeichen 'א' gefolgt von 'ב' und 'ג' ist).
dass die Zeichenfolge C400 die Folge der Bytes "C", "4", "0" und "0" ist.
Das ist Unsinn. Ein Byte (8 Bit) kann die Werte von 0 bis xFF = 255 annehmen.
Die Zeichenfolge 'C400' ist die Folge der Bytes 43 34 30 30 in UTF-8 genauso wie in ISO 8859-1. UTF-16BE-codiert ist es die Bytefolge 43 00 34 00 30 00 30 00 (alle Bytewerte hexadezimal).
Qapla'
Hi!
Erzähl bitte keine Unsinn! Informiere dich!
Ich habe die unicode-Seite referenziert und die ist für mich relevant.
Wenn es um ASCII geht?
Hallo,
… sie bezog sich auf ASCII-Zeichen. Es gibt keine ASCII-Zeichen oberhalb von U+007F.
Das ist falsch.
nein, ist es nicht.
In iso 8859-1 und folgende (iso 8859-n) sind definiert bis FF.
Stimmt. Aber Zeichencodes oberhalb von 7F sind kein ASCII, ASCII umfasst nur den Bereich von 00..7F.
Das deutsche Ä zum Beispiel hat in iso 8859-1 den Wert C4. In Unicode hat es auch den Wert U+00C4, nur müsste man dort die Zeichenfolge C400 schreiben wenn ich das so richtig in Erinnerung habe.
Auch nicht richtig: Das Unicode-Zeichen U+00C4 ('Ä') wird zwar in UTF-16 durch die zwei Bytes C4, 00 repräsentiert, in UTF-8 aber durch die zwei Bytes C3, 84.
Ciao,
Martin
Stimmt. Aber Zeichencodes oberhalb von 7F sind kein ASCII, ASCII umfasst nur den Bereich von 00..7F.
Nun ich beziehe mich mit meiner Aussage auf das Programm unibook.exe von der Unicode-Seite. Dort ist in der Codepage 20127 der US-ASCII-Zeichensatz deklariert. Die deklarieren zwar alle Zeichen oberhalb von 7F genauso wie nm-80 also wie das um 80 tiefer sitzende Zeichen, aber dort sind alle Zeichen von 00 bis FF entsprechend definiert.
Und das ist für mich eine offizielle Seite. So haben die das festgelegt.
Auch nicht richtig: Das Unicode-Zeichen U+00C4 ('Ä') wird zwar in UTF-16 durch die zwei Bytes C4, 00 repräsentiert, in UTF-8 aber durch die zwei Bytes C3, 84.
Richtig, ich war beim Konvertieren eine Zeile zu tief gerutscht. Ich hatte mich schon gewundert.
Tach,
Nun ich beziehe mich mit meiner Aussage auf das Programm unibook.exe von der Unicode-Seite.
[...]
Und das ist für mich eine offizielle Seite. So haben die das festgelegt.
nope, die offizielle Seite ist die vom American National Standards Institute, und auch in der letzten Revision von 1986 ist Ascii 7-bittig. Auch in Unicode ist Ascii 7-bittig, nämlich in der ersten Codepage 0000-007F.
mfg
Woodfighter
Hi!
Nun ich beziehe mich mit meiner Aussage auf das Programm unibook.exe von der Unicode-Seite. Dort ist in der Codepage 20127 der US-ASCII-Zeichensatz deklariert.
Die Codepage 20127 ist von Microsoft für Windows definiert worden. Abweichungen vom offiziellen Standard definieren diesen nicht um.
Jedenfalls finde ich diese Nummer nur im Zusammenhang mit Windows und keine offiziellen Dokumente von standardisierenden Organisationen, die sich darauf beziehen.
Die deklarieren zwar alle Zeichen oberhalb von 7F genauso wie nm-80 also wie das um 80 tiefer sitzende Zeichen, aber dort sind alle Zeichen von 00 bis FF entsprechend definiert.
Und das ist für mich eine offizielle Seite. So haben die das festgelegt.
Wenn du so argumentierst, dann haben "die" auch alles andere festgelegt, wie EBCDIC, MAC, ISO-8859-x und OEM-spezifischen Kram. Das was du da fandest, ist einfach nur eine Auflistung dessen, was Windows kennt. Es ist jedenfalls nicht des Unicode-Consotiums Aufgabe oder Zielstellung, die anderen Zeichenkodierungen zu definieren oder zu dokumentieren.
Lo!
Hallo,
- Du hast eine ISO-Datei unter utf-8 abgespeichert aber eigentlich hättest du das Ding konvertieren müssen. Und ja es gibt Editoren die konvertieren können meiner ist der SC-Unipad. Aber der kostet ...
notepad++ kann wunderbar konvertieren ...
Empfehlende Grüße
Vinzenz
Lieber Claus,
benutzt <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
Die kyrillischen Zeichen werden auch korrekt dargestellt.
Na, da hast Du Glück gehabt.
Kennt jemand HTMLDOC
Ich kenne die Software nicht. Aber ein kurzes Googlen führte mich zur Herstellerseite, und dort habe ich in den Anleitungen gesehen, dass es das Tool auch für Linux gibt. Unter Linux meine ich mich zu erinnern benutzen Applikationen überwiegend UTF-8 als Standard-Textkodierung.
Fazit: Versuche Deine Dokumente in UTF-8 kodiert abzuspeichern, ändere die Meta-Informationen und versuche es erneut.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer:
nuqneH
benutzt
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />Die kyrillischen Zeichen werden auch korrekt dargestellt.
Na, da hast Du Glück gehabt.
Wieso Glück? Es sind keine Zeichen, die sich mit ISO 8859-1 nicht codieren ließen, im Quelltext.
Dass man das nicht tun sollte, steht auf einem anderen Blatt. Auf diesem.
Qapla'
Hallo Gunnar,
das habe ich leider nicht verstanden.
Gruss
Claus
@@Felix Riesterer:
nuqneH
benutzt
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />Die kyrillischen Zeichen werden auch korrekt dargestellt.
Na, da hast Du Glück gehabt.Wieso Glück? Es sind keine Zeichen, die sich mit ISO 8859-1 nicht codieren ließen, im Quelltext.
Dass man das nicht tun sollte, steht auf einem anderen Blatt. Auf diesem.
Qapla'
@@Claus:
nuqneH
das habe ich leider nicht verstanden.
Was genau nicht?
Dass zwar "Вина" aus kyrillischen Zeichen besteht; "Вина" aber nicht?
Qapla'
PS: Die Übersetzung der Seite ist unvollständig. Der Seitentitel ist noch deutsch, die Tooltips auch. Letztere sind sowieso völlig überflüssig und sollten weg.
PPS: Bitte kein TOFU!
Hallo Felix,
das hatte ich schon probiert (UTF-8), hat nichts gebracht, ausser das die deutschen Umlaute nicht mehr dargestellt werden.
Im übrigen habe ich das bei der (russischen) Startseite so gemacht, da dies die einzige statische ist, also meta utf-8 und als utf-8 abgespeichert, da er sonst die kyrillischen Zeichen nicht richtig darstellen würde.
Die anderen Seiten sind dynamisch, also z.B. eine Speisekarte für alle Sprachen, die Daten kommen aus der Datenbank und werden ja richtig dargestellt, lediglich die Umsetzung zum PDF klappt nicht durchgängig.
Gruss
Claus
Lieber Claus,
benutzt
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />Die kyrillischen Zeichen werden auch korrekt dargestellt.
Na, da hast Du Glück gehabt.
Kennt jemand HTMLDOC
Ich kenne die Software nicht. Aber ein kurzes Googlen führte mich zur Herstellerseite, und dort habe ich in den Anleitungen gesehen, dass es das Tool auch für Linux gibt. Unter Linux meine ich mich zu erinnern benutzen Applikationen überwiegend UTF-8 als Standard-Textkodierung.
Fazit: Versuche Deine Dokumente in UTF-8 kodiert abzuspeichern, ändere die Meta-Informationen und versuche es erneut.
Liebe Grüße,
Felix Riesterer.
Hallo
das hatte ich schon probiert (UTF-8), hat nichts gebracht, ausser das die deutschen Umlaute nicht mehr dargestellt werden.
Dann hast du da was falsch gemacht. Von der Datei selbst bis zu allen Charset Angaben in der Datei und (Datenank und anderen Dateien die eingebunden werden) muss alles auf UTF-8 laut. Dann klappt das auch.
Aber ob es das PDF Problem löst weiß ich nicht. Würde ich aber vermuten.
