nicht angemeldet
Gunnar Bittersmann
dedlfix
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
hi,
s. Thema. Was an Vorteilen ergeben sich eigentlich daraus? Die Frage mal eingeschränkt auf die reine Darstellung von Inhalten in HTML, also nicht_interaktive Webseiten wie Gästebuch z.B.
In meinem Fall ist eine solche Umstellung auch nur rein technischer Natur, ich hab da nur die Header anzupassen und die Inhalte bei der Übertragung zum Server umzuwandeln. Dann kommts halt in utf-8, sieht aber ansonsten ganz genauso aus. Wirds evntl. suchmaschinenfreundlicher?
Mal so gefragt,
Horst
s. Thema. Was an Vorteilen ergeben sich eigentlich daraus?
Du musst Zeichen ausserhalb des definierten Zeichenvorrats nicht als entities notieren - du kannst jedes beliebige Zeichen im Klartext einfügen. Ob das Irgend ein mathematisches Symbol ist, ein Pfeilchen oder sonstige Scherze - du kannst aus einem von (in Zahlen ausgedrückt) "irre vielen" Zeichen wählen.
Ansonsten bieten sich keine nennenswerten Vorteile wenn du eine lediglich Zeichen in der definierten Codierung verwendest.
hi,
s. Thema. Was an Vorteilen ergeben sich eigentlich daraus?
Du musst Zeichen ausserhalb des definierten Zeichenvorrats nicht als entities notieren - du kannst jedes beliebige Zeichen im Klartext einfügen.
Naja, das kann ich mit iso-8859-1 genauso und mach das ja auch, bis auf ein paar Ausnahmen.
Ansonsten bieten sich keine nennenswerten Vorteile wenn du eine lediglich Zeichen in der definierten Codierung verwendest.
Bisher gibts nur Einen: Mein CGI zur Log-Auswertung ist utf-8, weil die Referrer, die ich aufzeichne von google & so kommen und utf-8-kodiert sind. Es gibt jedoch auch Referrer, die von meiner eigenen Suchmaschine kommen und die sind iso-8859-1-kodiert. Also mehr ne persönliche Sache womit ich eigentlich leben kann, obwohl das ein bischen liederlich aussieht...
Hotti
Naja, das kann ich mit iso-8859-1 genauso und mach das ja auch, bis auf ein paar Ausnahmen.
Ich würde eher sagen umgekehrt - 2^8 = 256 zeichen mit ISO-8859-1, 2^32 = 4.294.967.296 (theoretisch, ist ja nicht alles belegt) mit UTF-8. Ein paar Millionen zeichen als "ein paar Ausnahmen" zu bezeichnen ist schon fast lustig :D
Nimm das:
焊接是一种连接金属或热塑性塑料的制造或雕塑过程。焊接过程中，工件和焊料熔化形成熔融区域，熔池冷却凝固后便形成材料之间的连接。这一过程中，通常还需要施加压力。焊接的能量来源有很多种，包括气体焰、电弧、激光、电子束、摩擦和超声波等。19世纪末之前，唯一的焊接工艺是铁匠沿用了数百年的金属锻焊。最早的现代焊接技术出现在19世纪末，先是弧焊和氧燃气焊，稍后出现了电阻焊。20世纪早期，随着第一次和第二次世界大战开战，对军用器材廉价可靠的连接方法需求极大，故促进了焊接技术的发展。今天，随着焊接机器人在工业应用中的广泛应用，研究人员仍在深入研究焊接的本质，继续开发新的焊接方法，以进一步提高焊接质量。
(Artikel des Tages, zh.wikipedia.org)
Versuch das mit ISO-8859-1 ohne Entites oder nummerische Zeichenreferenzen darzustellen.
Naja, das kann ich mit iso-8859-1 genauso und mach das ja auch, bis auf ein paar Ausnahmen.
Ich würde eher sagen umgekehrt - 2^8 = 256 zeichen mit ISO-8859-1, 2^32 = 4.294.967.296 (theoretisch, ist ja nicht alles belegt) mit UTF-8. Ein paar Millionen zeichen als "ein paar Ausnahmen" zu bezeichnen ist schon fast lustig :D
Ich war schon immer etwas wortkarg ;-)
Hottä
@@hotti:
nuqneH
Du musst Zeichen ausserhalb des definierten Zeichenvorrats nicht als entities notieren
Oder gar (im Quelltext noch unleserlicher) als numerische Zeichenreferenz.
du kannst jedes beliebige Zeichen im Klartext einfügen.
Und solltest es auch. [ESCAPES]
Naja, das kann ich mit iso-8859-1 genauso
Nein, schon fürs Deutsche sind die Latin-1-Zeichen nicht ausreichend: Es fehlen das Eurozeichen, Anführungszeichen, Gedankenstriche, …
Qapla'
Nein, schon fürs Deutsche sind die Latin-1-Zeichen nicht ausreichend: Es fehlen das Eurozeichen, Anführungszeichen, Gedankenstriche, …
Gut, da gibts dann das gefakte Latin-1 welches ungefragt auf Windows-1252 übersetzt wird :)
Hallo,
Nein, schon fürs Deutsche sind die Latin-1-Zeichen nicht ausreichend
Gibt es denn einen Zeichensatz der auch alle deutschen Zeichen beinhaltet?
Hi!
Nein, schon fürs Deutsche sind die Latin-1-Zeichen nicht ausreichend
Gibt es denn einen Zeichensatz der auch alle deutschen Zeichen beinhaltet?
Definiere "alle deutschen Zeichen". Meinst du nur die Buchstaben, oder auch Satzzeichen? Wie sieht es mit wissenschaftlichen Symbolen aus? Willst du nicht-deutsche Zeichen generell ausschließen, und somit auf die Möglichkeit der korrekten Schreibung von beispielsweise fremdsprachigen Namen verzichten?
Aber egal, wie die Antwort lautet, die auf deine Frage ist Unicode. Du kommst nur vom Regen in die Traufe, wenn du Latin1/ISO-8859-1 gegen einen anderen begrenzten Zeichensatz eintauschst. Abgesehen davon musst du auch die Verbreitung in der Prxis betrachten, irgendein Exot (so es ihn gäbe) wird dir keine Freude machen.
Lo!
s. Thema. Was an Vorteilen ergeben sich eigentlich daraus?
Das ist eine politische Entscheidung.
Bei iso zwingst du alle dazu, die gleichen Fragezeichen zu lesen.
Bei utf-8 hat jeder seine eigene Freiheit, welche Fragezeichen er unwissentlich erzeugen darf.
Es ist also:
iso: Die Freiheit des Verständnisses des anderen.
utf8: Die Freiheit des eigenen Ausdrucks.
mfg Beat
@@hotti:
nuqneH
Wirds evntl. suchmaschinenfreundlicher?
Eine Suchmaschine liest Text genauso wie andere Clients (bspw. Browser) auch: Sie wandelt die ankommenden Bytesequenzen entsprechend der mitgeteilten Zeichencodierung (bzw. der Defaultzeichencodierung) in Zeichen um. Wie die Zeichen codiert sind, kann einem Client egal sein, solange er sie decodieren kann.
Qapla'
Wie schon vorgemerkt: prinzipiell hast Du nur dann Nachteile, wenn Du in einem Projekt mit zwei Codierungen gleichzeitig arbeitest, da man in solchen Fällen leicht vergißt, die damit verbundenen Probleme zu berücksichtigen.
UTF-8 bietet vor allem den Vorteil, dass man deutlich mehr Zeichen zur Verfügung hat. Das wiederum ist jedoch mit dem Nachteil verbunden, dass diese teilweise verwechselt werden können. Als zusätzlichen kleinen Vorteil kann man ansehen, dass UTF-8 inzwischen zum Esperanto der Zeichensätze geworden ist - beim Austausch zwischen Servern erspart man sich die Konvertierungsproblematik, wenn alle Beteiligten UTF-8 beherrschen.
Gruß, LX
@@LX:
nuqneH
UTF-8 bietet vor allem den Vorteil, dass man deutlich mehr Zeichen zur Verfügung hat.
?? Was genau meinst du mit „zur Verfügung hat“? Der Zeichensatz eines jeden HTML-Dokuments ist Unicode – völlig unabhängig von der Zeichencodierung. [DOC-CHARSET]
Der Vorteil einer geeigneten Zeichencodierung (also UTF-8) ist, dass man alle Zeichen auch als solche im Quelltext verwenden kann und nicht auf Escapes ausweichen muss.
Das wiederum ist jedoch mit dem Nachteil verbunden, dass diese teilweise verwechselt werden können.
?? Du meinst, dass man lateinisches 'a' und kyrillisches 'а' schwer unterscheiden kann? Auch das hat nichts mit der Zeichencodierung zu tun.
Als zusätzlichen kleinen Vorteil kann man ansehen, dass UTF-8 inzwischen zum Esperanto der Zeichensätze geworden ist
Nein!! UTF-8 ist kein Zeichensatz! Lies Zeichencodierung für Anfänger.
Qapla'
@@Gunnar:
Hallo, Du alter Besserwisser!
1. Ein solches Projekt besteht ja nicht nur aus HTML-Dokumenten. Bei Datenbanken kann es bspw. zuweilen recht praktisch sein, sich nicht um die Zeichenkodierung sorgen zu müssen.
2. Das Problem mit identisch aussehenden Zeichen mit unterschiedlichen Zeichencodes verdeutlicht sich insbesondere beim Phishing. Natürlich ist auch hier die Zeichencodierung unerheblich, jedoch ist es bei ISO-Kodierung geringfügig schwerer, ein kyrillisches a 'einzuschmuggeln'.
3. Esperanto ist an sich auch keine eigene lebende Sprache, sondern vielmehr ein zusammengestelltes Konglomerat anderer gesprochener Sprachen. Insofern ist die Metapher zutreffend.
Gruß, LX
@@LX:
nuqneH
- Das Problem mit identisch aussehenden Zeichen mit unterschiedlichen Zeichencodes verdeutlicht sich insbesondere beim Phishing. Natürlich ist auch hier die Zeichencodierung unerheblich
Du sagst es.
jedoch ist es bei ISO-Kodierung geringfügig schwerer, ein kyrillisches a 'einzuschmuggeln'.
Nicht wirklich: а und drin isses (im @href bspw.).
Nicht-ASCII-Zeichen in URIs ist eine andere Geschichte. Natürlich sollten Nicht-ASCII-Zeichen in URIs vorkommen dürfen. Und ein Browser hat die Aufgabe, den Nutzer vor Phishing zu warnen.
- Esperanto ist an sich auch keine eigene lebende Sprache, sondern vielmehr ein zusammengestelltes Konglomerat anderer gesprochener Sprachen. Insofern ist die Metapher zutreffend.
Es ging auch nicht um die Metapher „Esperanto“, sondern um „der Zeichensätze“. Nochmal zum Mitmeiseln: UTF-8 ist kein Zeichensatz.
Qapla'
Hallo
Nochmal zum Mitmeiseln: UTF-8 ist kein Zeichensatz.
Hättest'e den nicht dorthin verlinkt, wohin du den verlinkt hast, hätt' ich dich hochnotpeinlich zu Inge M. befragen müssen. :-)
Tschö, Auge
UTF-8 bietet vor allem den Vorteil, dass man deutlich mehr Zeichen zur Verfügung hat.
?? Was genau meinst du mit „zur Verfügung hat“? Der Zeichensatz eines jeden HTML-Dokuments ist Unicode – völlig unabhängig von der Zeichencodierung. [DOC-CHARSET]
Hm: Interpreter nehmen an, dass die Bits und Bytes nach einer Unicode-umsetzenden Charset Ideologie zu erfassen seien.
Eine Datei kann nicht deklarieren
"Ich-bin-LittleEnding-32Bit-Unicodekompatibel"
und die BOM ist so eine Sache, die auf meinem Windows-Perl schief läuft.
Der Vorteil einer geeigneten Zeichencodierung (also UTF-8) ist, dass man alle Zeichen auch als solche im Quelltext verwenden kann und nicht auf Escapes ausweichen muss.
Ja. Ich warte auf einen Unicodepunkt für Delimiter-Start-HTML, Delimiter-End-HTML.
Ganz praktisch wären ja Codepunkte, welchen den Kontextwechsel einer Sprache andeuten. Damit würde sich all das maskieren von selbst aufheben.
Das wiederum ist jedoch mit dem Nachteil verbunden, dass diese teilweise verwechselt werden können.
?? Du meinst, dass man lateinisches 'a' und kyrillisches 'а' schwer unterscheiden kann? Auch das hat nichts mit der Zeichencodierung zu tun.
Nein es hat primär damit zu tun, dass der Mensch mit 0 und 1 relativ wenig anfangen kann, wenn diese massenweise auftreten.
Als zusätzlichen kleinen Vorteil kann man ansehen, dass UTF-8 inzwischen zum Esperanto der Zeichensätze geworden ist
Nein!! UTF-8 ist kein Zeichensatz! Lies Zeichencodierung für Anfänger.
Das falsche Label haftet auch einigen HTML und HTTP Angaben an.
Wir hantieren nicht mehr mit Setzkästen, es sei denn, wir sehen unsere Tastatur als eine Art Setzkasten... Es ist der Setzkasten, der zur praktischen Anwendung von Unicode-Punkten im Wege steht.
Ich fühle mich mit Unicode dennoch nicht sehr glücklich. Es gibt einfach keinen direkten Weg, \b über einen ASCII erweiterten Raum zu definieren.
Unicode hat kein binäres System für Zeichenklassen, und die verschiedenen Encodings, die Unicode darstellen, deshalb auch nicht. Es geht nur mit Bibliotheken.
Gerade die Idee einer Weltsyntax ist in Unicode überhaupt nicht vorhanden. es ist in sich selbst auch nur ein grosser Setzkasten, und niemand will die Buchstaben noch umsortieren.
Böses bleibt immer entwicklungsfähig. Nur Gutes ist Gut.
mfg Beat
@@Beat:
nuqneH
Eine Datei kann nicht deklarieren
"Ich-bin-LittleEnding-32Bit-Unicodekompatibel"
Doch, mittels BOM.
und die BOM ist so eine Sache, die auf meinem Windows-Perl schief läuft.
Problem deines Windows-Perl, nicht von UTF.
Ja. Ich warte auf einen Unicodepunkt für Delimiter-Start-HTML, Delimiter-End-HTML.
Ganz praktisch wären ja Codepunkte, welchen den Kontextwechsel einer Sprache andeuten.
Not Unicode’s job.
Damit würde sich all das maskieren von selbst aufheben.
?? Escapet werden müssen Zeichen, die im jeweiligen Kontext eine Sonderbedeutung haben. Bspw. wenn " einen String begrenzen, müssen in ihm vorkommende " escapet werden. < und & haben in XML und HTML Sonderbedeutungen, müssen also in Texten und Attributwerten escapet werden.
Ich fühle mich mit Unicode dennoch nicht sehr glücklich. Es gibt einfach keinen direkten Weg, \b über einen ASCII erweiterten Raum zu definieren.
Problem der Implementierung von RegExps, nicht von Unicode.
Unicode hat kein binäres System für Zeichenklassen
Was meinst du damit?
Unicode hält zu jedem Zeichen einige Metainfos bereit. Bspw. für U+0061 'a':
General category: Ll - Letter, lowercase
Canonical combining class: 0 - Spacing, split, enclosing, reordrant, & Tibetan subjoined
Bidirectional category: L - Left-to-right
Uppercase mapping: 0041
Titlecase mapping: 0041
Decimal: 97
Gerade die Idee einer Weltsyntax ist in Unicode überhaupt nicht vorhanden. es ist in sich selbst auch nur ein grosser Setzkasten, und niemand will die Buchstaben noch umsortieren.
Du meinst, dass alle lateinischen Zeichen hintereinander stehen sollten, ohne Zeichen anderer Schriften dazwischen? Hm, das ist nunmal historisch so gewachsen. Ich sehe auch nicht, was sich durch Umsortierung verbessern sollte. Außer dass es geringfügig einfacher sein könnte herauszufinden, zu welcher Schrift ein Zeichen gehört. Dafür müsste man aber ständig Lücken lassen für spätere Erweiterungen.
Qapla'
Tja, liebe Leut und Webkollegen,
da sag ich auf jeden Fall mal danke für Eure Hinweise, Meinungen usw.!!!
Also, wenn mein Editor (das ist das Teil, womit ich meine CGIs und HTML schreibe) utf-8-fähig wäre, ich würde alle meine Seiten in UTF-8 präsentieren.
Nur, dieser Editor, der kennt kein utf-8. So schön wie der ist, er kann das eben nicht. Ich lass nun alles doch auf iso. Nur um der "Sache willen" umstellen, ja, geht, aber wozu.
Der Euro ist übrigens der Knackpunkt. Es gibt zwar verschiedene Kodes für ein 'ü' was so das Umwandeln eines 'ü' in verschiedene gewünschte Kodierungen ermöglicht, aber beim € gibts das nicht.
Tschüüüüüüys ;-9
Hotte
Moin
Nur, dieser Editor, der kennt kein utf-8. So schön wie der ist, er kann das eben nicht. Ich lass nun alles doch auf iso. Nur um der "Sache willen" umstellen, ja, geht, aber wozu.
Dann installier dir nen vernünftigen Editor. Dein jetziger scheint ja keine Editor mit Vernunft zu sein. Die Umstellung auf Unicode lohnt auf alle Fälle, auch wenn es erstmal Arbeit bedeutet. Im Nachgang hat man bei weitem weniger Scherereien. Das kann ich dir versprechen.
Gruß Bobby
Moin
Nur, dieser Editor, der kennt kein utf-8. So schön wie der ist, er kann das eben nicht. Ich lass nun alles doch auf iso. Nur um der "Sache willen" umstellen, ja, geht, aber wozu.
Dann installier dir nen vernünftigen Editor.
Seufz ;-)
Dein jetziger scheint ja keine Editor mit Vernunft zu sein.
Es ist ein uralter TextPad und außer utf kann der Alles was meinen Wünschen entspricht.
Die Umstellung auf Unicode lohnt auf alle Fälle, auch wenn es erstmal Arbeit bedeutet.
Wenn ich alles in utf _schreiben_ würde, wäre der Aufwand für die Umstellung von iso-8859 auf utf-8 kein Thema und auch keine Mehrarbeit.
Im Nachgang hat man bei weitem weniger Scherereien. Das kann ich dir versprechen.
Scherereien? Hab ich mit iso auch nicht ;-)
Ziemlich sinnbefreit ists jedoch, eine in ISO-8859 bestehende Publikation nach utf-8 zu konvertieren und am Prozess der Konvertierung weiterhin festzuhalten sofern neue Inhalte publiziert werden sollen. Genau an dieser Stelle sollte der alte Editor einem Neuen weichen, oder ich bleibe halt bei ISO. Gerade am Euro-Beispiel ists mir deutlich geworden, dass eine Konvertierung nicht die Basis sein kann, das ist unproduktiv.
Hotte
Moin
Es ist ein uralter TextPad und außer utf kann der Alles was meinen Wünschen entspricht.
|
Wenn ich alles in utf _schreiben_ würde, wäre der Aufwand für die Umstellung von iso-8859 auf utf-8 kein Thema und auch keine Mehrarbeit.
Dann nimm z.B. für Windows den PSPad. Der ist wirklich gut. Und ist relativ flexibel. Im Linux bei OpenSuse gibts "KDevelop". Auch recht vernünftig.
Scherereien? Hab ich mit iso auch nicht ;-)
Doch. Versuch mal eine andere Sprache ohne ISO-Wechsel in der selben Webseite darzustellen. :D
Gruß Bobby
Es ist ein uralter TextPad und außer utf kann der Alles was meinen Wünschen entspricht.
Nimm doch einen HEX Editor. Da hast du volle Kontrolle.
mfg Beat
Es ist ein uralter TextPad und außer utf kann der Alles was meinen Wünschen entspricht.
Nimm doch einen HEX Editor. Da hast du volle Kontrolle.
*G* Nein ;-)
Für mich gibts nur eine Alternative zum TextPad und das ist der vi. Also mal so nebenbei bemerkt, das ist wirklich bemerkenswert, dass der vi mit Zeichenkodierungen überhaupt keine Probleme hat. Locale wird in der .bashrc gesetzt und schon kannst losgehen, der vi spurt zuverlässlich. Manchmal könnt ich da schon so richtig neidisch werden mit meine facking XP.
Hotte
Hallo
Für mich gibts nur eine Alternative zum TextPad und das ist der vi. Also mal so nebenbei bemerkt, das ist wirklich bemerkenswert, dass der vi mit Zeichenkodierungen überhaupt keine Probleme hat. Locale wird in der .bashrc gesetzt und schon kannst losgehen, der vi spurt zuverlässlich. Manchmal könnt ich da schon so richtig neidisch werden mit meine facking XP.
WinVi (man beachte auch den RetroLook der Seite) :-)
Tschö, Auge
WinVi (man beachte auch den RetroLook der Seite) :-)
Grausam. Das Ding hat eine der kürzesten Softwarezyklen auf meinem XP.
Abgesehen vom Java-Übel[1] fand ich JEdit recht reichhaltig in diesem Segment.
[1] Kaffee gehört in meine Röhre, nicht auf den Flatscreen.
mfg Beat
Hallo
WinVi (man beachte auch den RetroLook der Seite) :-)
Grausam. Das Ding hat eine der kürzesten Softwarezyklen auf meinem XP.
Wollte es hotti gegenüber nur erwähnt haben. Ich kenne den Editor selbst auch nicht (finde vi ansich auch nicht wirklich prickelnd).
Abgesehen vom Java-Übel[1] fand ich JEdit recht reichhaltig in diesem Segment.
Ja, ein Kumpel schwärmt auch von JEdit. Der ist bei ihm sowohl unter Linux als auch unter Windows (falls das heute noch zutrifft) im Einsatz. Geht ja schließlich überall, wo die Kaffeetasse im Einsatz ist.
[1] Kaffee gehört in meine Röhre, nicht auf den Flatscreen.
So 'ne Kathodenstrahlröhre hat doch ein innenliegendes Vakuum. Wird das mit Kaffee nicht ad absurdum geführt? ;-)
Tschö, Auge
Hallo
WinVi (man beachte auch den RetroLook der Seite) :-)
Grausam. Das Ding hat eine der kürzesten Softwarezyklen auf meinem XP.
Wollte es hotti gegenüber nur erwähnt haben. Ich kenne den Editor selbst auch nicht (finde vi ansich auch nicht wirklich prickelnd).
Hotti kenntn schon. Das Original in der richtigen Umgebung ist besser ;-)
Meine ersten c-Programme hab ich mit dem vi geschrieben in einer Multi-User-Umgebung auf UNIX. WUNIX war da meine Lieblingslektüre in der Zeit... those where the days ;-)
Meine Fresse und den ganzen Abend hab ich mich hier was rumgequält, eine Internetverbindung über den Computer meines Sohnes herzustellen. "Internet-Freigabe" heißt das bei Micropfft und der Hostcomputer kriegt da die 192.168.0.1/24. Das hätten die aber auch mal irgendwo in die Hülfe schreiben können, denn die 192.168.0.1 hatte nochn anderes Gerät bei mir irgendwo im LAN, aber mit ner anderen Maske. Als ob es nur 192.0.0.0/24 Netze auf dieser Welt gäbet mit 192.168.0.1 als Gateway. Naja, jetzt geht alles und ich geh schlafen.
Gute Nacht,
Hotte
@@hotti:
nuqneH
Es ist ein uralter TextPad und außer utf kann der Alles was meinen Wünschen entspricht.
Dann mach ein Update!
Auch wenn TextPad immer noch nicht Unicode-fähig ist*, als UTF-8 speichern (mit oder ohne BOM) kann er schon lange.
Qapla'
* Textpad (das GIF unter den Texteditoren) kann nur Paletten.
Auge