nicht angemeldet
Griechische Pfirsiche
suit
Marc
Gunnar BittersmannHallo liebe Webgemeinde,
ich mache gerade einen Severumzug einer Seite für Griechenland. Auf dem neuen Server werden die Zeichen im FF erst richtig angezeigt wenn man manuell unter Ansicht das Charset 1253 wählt. Dabei steht im Metatag
<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=windows-1253">
Auf dem alten Sever läuft das auch. Wie kann das sein?
Gruß
Eure Sahra
-
Yerf!
<META http-equiv="Content-Type" content="text/html; charset=windows-1253">
Auf dem alten Sever läuft das auch. Wie kann das sein?
Der neue Webserver sendet anscheinend selbst einen HTTP-Header mit einer anderen Charste-Angabe mit. Diese gewinnt über den Meta-Tag (die ja nur ein Ersatz für den HTTP-Header ist, daher das http-equiv)
Das muss somit in der Konfiguration des Webservers entsprechend eingestellt werden.
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Ok,
das leuchtet ein. Die Frage ist nur wo das konfiguriert ist und warum die Angabe im HTML generell nicht bevorzugt wird.
Bis dann
Sahra-
Yerf!
Die Frage ist nur wo das konfiguriert ist
Hängt vom Webserver ab. Wenn's ein Apache ist kann man es per .htaccess umstellen. dazu sollte sich im Forums-Archiv was finden lassen.
und warum die Angabe im HTML generell nicht bevorzugt wird.
Das wurde eben so festgelegt (und hat durchaus auch Vorteile, da man beim Meta-Tag das Dokument schon parsen muss bevor man überhaupt weis, welches Encoding es eigentlich hat).
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Suit hat hier recht,
wenn ich das HTML Dokument im Texteditor auf UTF8 speicher und dann die Zeichen noch einmal einfüge dann geht es...
Danke
Sahra-
wenn ich das HTML Dokument im Texteditor auf UTF8 speicher und dann die Zeichen noch einmal einfüge dann geht es...
dann schickt der server offenbar utf-8, das solltest du ggf nochmal verifizieren - wenn dem so ist: alles umcodieren und "nie wieder probleme haben"
-
Hi,
dann schickt der server offenbar utf-8, das solltest du ggf nochmal verifizieren - wenn dem so ist: alles umcodieren und "nie wieder probleme haben"
genau. UTF-8 ist meiner Ansicht nach allem anderen unbedingt vorzuziehen.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hi,
ja das ist auf jeden Fall so vorallem weil es unsere meisten Seiten und Datenbanken nutzen. Die Frage ist nur ob man es irgendwie einfacher umformatieren kann. War jetzt heftig Copy Paste. Kann man nicht iregdwie convert windows 1253 to utf8 machen?
Bis dann
Sahra-
War jetzt heftig Copy Paste.
wie oft? 20x? 30x? 100x?
Kann man nicht iregdwie convert windows 1253 to utf8 machen?
mein editor kann das auch ohne copy&paste, der hat eine funktion dafür ;)
-
Hi,
Kann man nicht iregdwie convert windows 1253 to utf8 machen?
gibt sicher Tools dafür. Wenn es nicht gerade allzu viele Dateien sind, kann ich Dir Textpad ans Herz legen: Dort nutze ich einfach "Speichern unter" und kann UTF-8 als Zeichensatz auswählen. Mit anderen Editoren geht es sicher ähnlich.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hallo,
Kann man nicht iregdwie convert windows 1253 to utf8 machen?
gibt sicher Tools dafür. Wenn es nicht gerade allzu viele Dateien sind, kann ich Dir Textpad ans Herz legen: Dort nutze ich einfach "Speichern unter" und kann UTF-8 als Zeichensatz auswählen. Mit anderen Editoren geht es sicher ähnlich.
Ja. Sogar mit dem Windows-Editor. - Man kann es gaum glauben :-)
Viele Grüße,
Marc.-
echo $begrüßung;
Ja. Sogar mit dem Windows-Editor. - Man kann es gaum glauben :-)
Der kann aber nur mit BOM speichern und die stört im Falle von HTML.
Das Problem an den Editoren ist, dass man die Datei auch gezielt in Kodierung X öffnen können muss oder Windows die als Default-Kodierung eingestellt hat. Unter Unix gibt es iconv zum Umkodieren. Vielleicht gibt es das auch als Windows-Version.
echo "$verabschiedung $name";
-
-
-
-
genau. UTF-8 ist meiner Ansicht nach allem anderen unbedingt vorzuziehen.
nicht ganz - utf-16 ist zb dann sinnvoll, wenn man sehr viele zeichen hat, die im unicodebereich 000800 bis 00FFFF liegen
utf-8 benötigt hierbei 3 bytes pro zeichen, utf-16 nur 2
-
Hi,
genau. UTF-8 ist meiner Ansicht nach allem anderen unbedingt vorzuziehen.
nicht ganz - utf-16 ist zb dann sinnvoll, wenn man sehr viele zeichen hat, die im unicodebereich 000800 bis 00FFFF liegenstimmt auch wieder. Ich postuliere jetzt einfach mal, dass dieser Fall eher sehr spezieller Natur ist, der hoffentlich von Leuten bearbeitet wird, die die fachlichen Grundlagen zu einer betreffenden Entscheidung besitzen, und habe mich damit fein rausgeredet ;-)
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
zeichen die in diesem unicode-bereich liegen sind vorrangig asiatische schriftzeichen (sanskrit bis chinesisch ist da wahrscheinlich alles dabei), traditionellerweise werden die mit tusche auf pergament geschrieben - da dürfte weder utf-8 noch utf-16 von belang sein
wenn doch, dann werden die wohl zu utf-8 greifen - auf einem schriftrolle mit gebeten macht sich ein byte-order-mark am textanfang nicht so gut :D
-
-
utf-8 benötigt hierbei 3 bytes pro zeichen, utf-16 nur 2
Die Etablierung *einer* hinreichenden Unicode-Kodierung wie UTF-8 in der Software-Welt hat auch wenig mit Speicherplatzersparnis zu tun. So ist Latin-1 für deutschsprachige Texte auch platzsparenter, dennoch hat UTF-8 viele Vorteile. Bei UTF-16 ist es anders herum, weil viel Software, die UTF-8 unterstützt, auch ISO-8859-1 unterstützt (auch wenn dabei Probleme auftreten), aber längst nicht UTF-16. Im Webkontext würde man sich wahrscheinlich für UTF-8 entscheiden, weil es die Standardkodierung ist, die mittlerweile breit unterstützt wird.
Mathias
-
Hallo molily,
Die Etablierung *einer* hinreichenden Unicode-Kodierung wie UTF-8 in der Software-Welt hat auch wenig mit Speicherplatzersparnis zu tun.
UTF-16 ist zumindest als Format für die Textverarbeitung (im Unterschied zur Speicherung) sehr verbreitet. Strings werden oft als UTF-16 gespeichert (nicht nur in Java).
So ist Latin-1 für deutschsprachige Texte auch platzsparenter, dennoch hat UTF-8 viele Vorteile.
Ja, aber kaum, die Umlaute und ß machen nur wenig aus. Wenn man aber z.B. asiatische Sprachen kodiert, hat man mit UTF-8 wirklich einen Faktor drei.
Bei UTF-16 ist es anders herum, weil viel Software, die UTF-8 unterstützt, auch ISO-8859-1 unterstützt (auch wenn dabei Probleme auftreten), aber längst nicht UTF-16.
Für Browser gilt das wohl nicht. Mit Windows-Texteditoren kenne ich mich nicht aus, aber da muss man dann eben einen entsprechenden wählen.
Im Webkontext würde man sich wahrscheinlich für UTF-8 entscheiden, weil es die Standardkodierung ist, die mittlerweile breit unterstützt wird.
Wo mangelt es denn an UTF-16-Unterstützung? Bei Browsern wohl nicht, auf der Serverseite eher auch nicht, Unicode-fähige Programmiersprachen benutzen oft UTF-16.
Für Sprachen mit im Wesentlichen lateinischem Alphabet ist UTF-8 natürlich optimal, für Sprachen, deren Zeichen dann 3-Byte benötigen, also vor allem wohl asiatische, zweifle ich etwas.
Grüße
Daniel
-
echo $begrüßung;
Wenn man aber z.B. asiatische Sprachen kodiert, hat man mit UTF-8 wirklich einen Faktor drei.
Hat man nicht, denn ein einzelnes asiatisches Zeichen lässt sich sowieso nicht mit nur einem Byte darstellen. Dafür sind es einfach zu viele. Außerdem ist es zumindest im Chinesischen und Japanischen so, dass ein Zeichen für eine Silbe oder vielfach auch für ein ganzes Wort steht. 你好 benötigt 6 Bytes, »Guten Tag« hingegen 9.
echo "$verabschiedung $name";
-
Hallo dedlfix,
Hat man nicht, denn ein einzelnes asiatisches Zeichen lässt sich sowieso nicht mit nur einem Byte darstellen.
Ja es ist ein Faktor 1,5 oder so. Bei UTF-8 bliebe es so.
Dafür sind es einfach zu viele. Außerdem ist es zumindest im Chinesischen und Japanischen so, dass ein Zeichen für eine Silbe oder vielfach auch für ein ganzes Wort steht.
Naja, relevant ist der Faktor bezüglich der Gleichen Sprache. Man kann natürlich sagen, dass Textdaten sowieso nur noch einen geringen Anteil der Daten ausmachen und wenn man sie komprimiert, ist der Zeichensatz ohnehin nicht mehr relevant. Allerdings verwendet z.B. UTF-32 trotzdem niemand, obwohl es so toll einfach ist.
你好 benötigt 6 Bytes, »Guten Tag« hingegen 9.
"Hi" benötigt nur zwei Bytes, da kann Japanisch gar nicht mehr drunter kommen ;-)
Grüße
Daniel
-
-
@@Daniel Thoma:
Für Sprachen mit im Wesentlichen lateinischem Alphabet ist UTF-8 natürlich optimal, für Sprachen, deren Zeichen dann 3-Byte benötigen, also vor allem wohl asiatische, zweifle ich etwas.
Wobei evtl. durch die Auszeichnungssprache (HTML, LaTeX, …) zu den japanischen/chinesischen/… Zeichen noch haufenweise Basic-Latin-Zeichen hinzukommen, so dass auch bei solchen Texten je nach Verhältnis Textinhalt-/Markupsyntax-Zeichen die Codierung in UTF-8 effizienter sein kann.
Live long and prosper,
Gunnar--
Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.
-
-
-
-
-
-
-
Hängt vom Webserver ab. Wenn's ein Apache ist kann man es per .htaccess umstellen. dazu sollte sich im Forums-Archiv was finden lassen.
bitte solche sachen nach möglichkeit [1] in der serverconfig erledigen (oder jeweiligen vhost) .htaccess ist zwar eine "feine sache" aber zerpflückt die konfiguration
[1] eigener server - bei hostern hat man meisten nur die möglichkeit ein .htaccess-file zu erstellen
-
-
-
-
ich mache gerade einen Severumzug einer Seite für Griechenland. Auf dem neuen Server werden die Zeichen im FF erst richtig angezeigt wenn man manuell unter Ansicht das Charset 1253 wählt. Dabei steht im Metatag
<META http-equiv="Content-Type" content="text/html; charset=windows-1253">das http-equiv besitzt kein gewicht gebenüber einen echten http-header, diese angabe ist nur äquivalent, wenn eben kein http-header vorhanden ist
Auf dem alten Sever läuft das auch. Wie kann das sein?
im http-header wird eine andere zeichencodierung verwendet?
du solltest dich mit zeichencodierung auseinandersetzen und nach möglichkeit auf utf-8 umstellen