Benutzer:Wassermaus/persönliche Spielwiese
Es gibt die Vorlagr xx. Diele beinhaltet Eibe Graphik von nn großen transneptunischen Objekten, als phanatadiezeichnzjgen (ausser saß pluto-system) anklickbar.
Ich lehn diese Vorlage nicht ab (auch wenn ich prinzipiell etwas gegen "künstlerische Darstellungen" von astronomischen Objekten habe, weil ich sie für unenzyklopädisch und fast schon irreführend hatte, aber ich weiß manche sehen das anders
Aber diese Graphik ist in eine Vielzahl von Artikeln zu einzelnen Objekten eingebunden, uns das geht gar nicht. Es widerspricht den Prinzipien der Wikipedia
- zum Artikel eines Objekts im weitesten Sinne gehört nur Information zu diesem Objekt. Eine vergleichende Liste oder Tabelle gehört nur in einen Artikel zur Objektklasse, Das ist absoluter Standard.
- Beispiel: eine Tabelle mit Fläche, Bevölkerungszahl und Bruttosozialprodukt aller EU-Staaten kann in einen Artikel zur EU oder zur Wirtschaft der EU, aber nicht in die Artikel zu Frankreich, Irland, Portugal...
- Beispiel: eine Liste der Könige von England gehört nicht in die Artikel von Elisabth II, Charles III etc
- eine Einbindung solcher Listen ist nur als Navigationsleiste statthaft - und da gelten klare Regeln: nur wo es sinnvoll ist und wo Vollständigkeit gewährleiste ist - also (Zwerg)Planeten ja, TNOs nein
- und auch dann nur als Mittel zur Navigation
- die Abbildung ist als "Vergleich" deklaroetz und, ja, es gibt anderswo auch Vergleiche - zB zwischen Sirius und Sonne. Aber tweck solcher Vergleiche ist, dem Leser statt nacktec"astronomuscher" Zahlen eiern Vergleich mit etwas halbwegs Gekläzufigerem zu liefern, also als Maßeinheit,. So mag in einem Artikel stehen: die Oberfläche von X ist so groß wie Hessen
- das Argument: Dias St eine Einbindung @- ist doch schön, das. Das nur 1x gepflegt werden muss zieht nicht, es geht darum, was der Ö
Leser sieht
- ähnliche Diskussiohen gab es übrigens in der Redaktion Physik Umrechnungstabellen für Einheiten
Kodierung
[Bearbeiten | Quelltext bearbeiten]Algorithmus
[Bearbeiten | Quelltext bearbeiten]Unicode-Zeichen mit Werten aus dem Bereich von 0 bis 127 (0 bis 7F hexadezimal) werden in der UTF-8-Kodierung als ein Byte mit dem gleichen Wert wiedergegeben.
Unicode-Zeichen größer als 127 werden in der UTF-8-Kodierung zu 2 bis 4 Byte langen Bytefolgen. Dabei beginnt das erste Byte immer mit 11, die weiteren Bytes mit 10. Die Anzahl der Einsen 1 vor der ersten Null 0 im ersten Byte ist gleich der Gesamtzahl der Bytes für das Zeichen. Die Bits, die in Unicode ein Zeichen darstellen, werden bündig angeordnet – das niedrigste Bit (least significant bit) des Unicode-Zeichens steht also immer im niedrigsten Bit des letzten UTF-8-Bytes.
Das erste Byte eines UTF-8-kodierten Zeichens nennt man dabei Start-Byte, weitere Bytes heißen Folge-Bytes. Start-Bytes beginnen also immer mit 0 oder 11, Folge-Bytes immer mit 10.
| Unicode-Bereich (hexadezimal) |
UTF-8-Codierung | Anzahl codierbarer Zeichen | ||||||
|---|---|---|---|---|---|---|---|---|
| Byte 1 | Byte 2 | Byte 3 | Byte 4 | im Standard erlaubt | theoretisch möglich | |||
| 00 – 7F | 0 a6a5a4a3a2a1a0 | 27 | 128 | 27 | 128 | |||
| 0080 – 07FF | 1 1 0 b2b1b0a7a 6 | 1 0 a5a4a3a2a1a0 | 211 − 27 | 1920 | 211 | 2048 | ||
| 0800 – FFFF | 1 1 1 0 b7b6b5b4 | 1 0 b3b2b1b0a7a6 | 1 0 a5a4a3a2a1a0 | 216 − 211 | 63.488 | 216 | 65.536 | |
| 01 0000 – 10 FFFF | 1 1 1 1 0 c4c3c2 | 1 0 c1c0b7b6b5b4 | 1 0 b3b2b1b0a7a6 | 1 0 a5a4a3a2a1a0 | 220 | 1.048.576 | 221 | 2.097.152 |
Dieser Algorithmus lässt theoretisch längere Bytesequenzen zu. Ursprünglich wurde eine Folge aus einem ersten Byte mit bis zu 1111110x (FChex und FDhex) und fünf Folge-Bytes der Form 10xxxxxx definiert, in denen so insgesamt 31 Bit für den enthaltenen Unicode-Wert kodiert werden konnten. In seiner Verwendung als UTF-Kodierung ist er aber auf den gemeinsamen Coderaum aller Unicode-Kodierungen beschränkt, also von 0 bis 0010 FFFF (1.114.112 Möglichkeiten) und weist maximal vier Bytes lange Byteketten auf. Längere Bytefolgen und größere Werte gelten heute als unzulässige Codes und sind entsprechend zu behandeln. Außerdem gibt es weitere Einschränkungen:
- Nach diesem Algorithmus könnten Zeichen auf unterschiedliche Weise kodiert werden – zum Beispiel der Buchstabe „a“ als 01100001 (61hex) oder fälschlich als 11000001 10100001 (C1A1hex). Jedoch erlaubt der Standard nur die jeweils kürzestmögliche Kodierung. Aus diesem Grund können C0hex und C1hex niemals in gültigem UTF-8-Code vorkommen. Diese Mehrdeutigkeit hat mehrfach zu Problemen geführt, wenn Programme bei ungültigen Kodierungen abstürzen, diese als gültig interpretieren oder einfach ignorieren. Die Kombinationen der letzten beiden Verhaltensweisen führte z. B. zu Firewalls, die gefährliche Inhalte auf Grund der ungültigen Kodierung nicht erkennen, wo jedoch der zu schützende Client diese Kodierungen als gültig interpretiert und dadurch gefährdet ist.
- Die Unicode-Bereiche U+D800 bis U+DBFF und U+DC00 bis U+DFFF sind ausdrücklich keine Zeichen, sondern dienen nur in UTF-16 zur Kodierung von Zeichen außerhalb der Basic Multilingual Plane, sie wurden früher als Low und High surrogates bezeichnet. Folglich sind Bytefolgen, die diesen Bereichen entsprechen, kein gültiges UTF-8. Zum Beispiel wird U+10400 in UTF-16 als D801,DC00 dargestellt, sollte in UTF-8 aber als F0,90,90,80 und nicht als ED,A0,81,ED,B0,80 ausgedrückt werden. Java unterstützt dies seit der Version 1.5.[1] Aufgrund der weiten Verbreitung der falschen Kodierung, insbesondere auch in Datenbanken, wurde diese Kodierung nachträglich als CESU-8 normiert.
Kann eine Byte-Sequenz nicht als UTF-8-Zeichen interpretiert werden, so wird es beim Lesen in der Regel durch das Unicode-Replacement-Zeichen U+FFFD bzw. EF,BF,BD ersetzt.
Aus dem Algorithmus ergeben sich folgende Eigenschaften von UTF-8:
- Ist das höchste Bit des ersten Bytes 0, handelt es sich um ein ASCII-Zeichen, da ASCII eine 7-Bit-Kodierung ist und die ersten 128 Unicode-Zeichen den ASCII-Zeichen entsprechen. Damit sind alle ASCII-Zeichenketten automatisch aufwärtskompatibel zu UTF-8, oder anders ausgedrückt: Alle Daten, für die ausschließlich ASCII-Zeichen verwendet werden, sind in beiden Darstellungen identisch. Für alle auf dem lateinischen Alphabet basierenden Schriften ist UTF-8 daher eine besonders platzsparende Methode zur Abbildung von Unicode-Zeichen.
- Ist das höchste Bit des ersten Bytes 1, handelt es sich um ein Mehrbytezeichen, also ein Unicode-Zeichen mit einer Zeichennummer größer als 127. Sind die höchsten beiden Bits eines Bytes 11, handelt es sich um das Startbyte eines Mehrbytezeichens, sind sie 10, um ein Folgebyte.
- Die lexikalische Ordnung nach Bytewerten entspricht der lexikalischen Ordnung nach Zeichennummern, da höhere Zeichennummern mit entsprechend mehr 1-Bits im Start-Byte kodiert werden.
- Startbytes (0… oder 11…) und Folgebytes (10…) lassen sich eindeutig voneinander unterscheiden. Somit kann ein Bytestrom auch in der Mitte gelesen werden, ohne dass es Probleme mit der Dekodierung gibt, was insbesondere bei der Wiederherstellung defekter Daten wichtig ist. Bytes beginnend mit 10 werden einfach übersprungen, bis 0… oder 11… erkannt wird. Dass Startbytes und Folgebytes eindeutig voneinander unterschieden sind, ist ein Vorteil der UTF-8-Kodierung. Bei Kodierungen ohne diese Eigenschaft ist das Lesen eines Datenstroms, dessen Beginn unbekannt ist, unter Umständen nicht möglich.
- ↑ Norbert Lindenberg, Masayoshi Okutsu: Supplementary Characters in the Java Platform. In: Oracle Website. Sun Microsystems, Mai 2004, abgerufen am 9. Juni 2019 (englisch).