Diskussion:Byte-Reihenfolge

Byte und Bytes

Das alte Problem. Darf man, soll man oder eben doch nicht im Plural "Bytes" schreiben? Im Artikel zu Byte ist das eindeutig angewendet und in der Diskussion ebenso angesprochen. Einigen wir uns doch darauf, dass in einer Enzyklopädie die Umgangssprache so weit wie möglich unterdrückt wird, solange dadurch der Sinn nicht entstellt wird, und benennen wir (Größen-)Einheiten wie physikalische immer im Singular. Es sollte also heißen: "1 Byte, 2 Byte". (http://www.canoo.net/services/OnlineGrammar/Wort/Nomen/Numerus/Menge.html?MenuId=Word1212) --Mrsurrender 12:50, 27. Jul 2006 (CEST)

Ich denke, es ist ein Unterschied ob man "Byte" als Maßeinheit benutzt wie in "... hat eine Speicherkapazität von 10 Byte", oder "Bytes" als Objekte sieht bzw. als normale Substantive benutzt wie etwa "diese 2 Bytes werden vertauscht" oder "Die Reihenfolge der Bytes ist unterschiedlich.".

Zahlen im Arabischen

Es ist zwar richtig, dass sich Zahlen im Arabischen in gleicher Weise wie in der westlichen Welt schreiben, also mit der höchstwertigen Stelle links, aber es ist nicht richtig, dass sich die Zahl konsequent von rechts nach links liest. So heißt die Zahl 1234 auf Arabisch: 'alf wa-mi'ata:n wa-'arba`atun wa-thala:thu:n, wörtlich "Tausend und-zweihundert und-vier und-dreißig". Anscheinend ist es wenig intuitiv, sehr große Zahlen (ab 100, das ist im wirklichen Leben schon recht groß) erst von ihren vernachlässigbaren Kleinkram her zu nennen. Insofern haben wir Deutschen es leichter: Wir lesen die Zahl in unserer Leserichtung bis auf die letzten zwei Stellen, die Araber lesen ihre Zahlen nur für diese zwei Stellen in der gewohnten Richtung.--Mzapf 20:21, 4. Sep 2006 (CEST)

schaut euch mal die quelle von jürgen gärtner an: http://www.jgae.de/endian.htm, die ich für die aktuelle ergänzung benutzt habe! der beschreibt vom "normalen"- nicht computerverstand her...; ich verzichte zunächst darauf, den artikel hier weiter dahingehend auszubauen, weil es wohl ein spezifisches thema ist, aber der wp-artikel ist schon ziemlich fachchinesisch..., viele grüße! --Hungchaka 22:22, 15. Nov. 2009 (CET)ps: wie wärs mit einem abschnitt geschichtliches?

IMHO ist Arabisch eine Schrift mit zwei Leserichtungen! Text von rechts nach links, Zahlen von links nach rechts. Auch Unicode-basierte Textprozessoren verfahren so: Ein fortlaufender Strom aus Zeichenkodes in Schreib-Reihenfolge wird, für den Kode-Bereich arabischer Buchstaben (und aller anderen RTL-Zeichen), von rechts nach links auf dem Bildschirm ausgespuckt, Zahlen hingegen von links nach rechts. Ein Araber, der beim handschriftlichen Diktat eine Telefonnummer aufschreibt, muss im Fließtext entsprechend Platz lassen auf dem Papier und hoffen, dass diese sich nicht als überlang entpuppt. (Bei Zeilenumbrüchen wird's noch komplizierter.)

Daher würde ich den Abschnitt im Wikipedia-Artikel zusammenkürzen und festlegen, dass alle menschengeschriebenen Zahlen big-endian sind. (nicht signierter Beitrag von 134.109.9.176 (Diskussion) 09:37, 28. Okt. 2011 (CEST))

Genau genommen hat eine links-rechts-Orientierung mit dem Thema hier rein gar nichts zu tun. (In diese Falle tappt letztlich auch schon Danny Cohen.) Die Leserichtung links-rechts ist eine neue Dimension, die völlig unabhängig ist von den relevanten (was sich auch in den kulturell unterschiedlichen Orientierungen manifestiert). Die 2 Dimensionen, um die es hier geht, sind

1. die Adressierungsreihenfolge, aufsteigend von den niedrigen (im Grunde der Adresse 0) zu den höheren Adressen. [Gekoppelt hiermit ist praktisch immer die Reihenfolge der Hardware-Transporte im Speicher, also eine Art RAM-Leserichtung. Ob wir aber die niedrigen Adressen uns auf der linken Seite vorstellen oder auf der rechten, ist reine Konvention – wie das Schreiben einer Schrift: europäisch, arabisch oder chinesisch.]
2. die Rangigkeit der Ziffern im verwendeten Stellenwertsystem. [Es gibt eine verbreitete Gepflogenheit, die Ziffern mit dem größeren Gewicht zuerst zu nennen.]

Diese 2 Richtungen können [unter sich] korrelieren oder antikorrelieren. [Und jeweils dann auch noch mit (3.) links-rechts und (4.) der Lese- und Sprechreihenfolge, die leicht mit (1.) korreliert.] Es geht also um 4 letztlich unabhängige Richtungen. Aber die Diskussion zeigt, wie gründlich diese Konventionen in unbewusste Automatismen übergegangen sind. --Nomen4Omen (Diskussion) 12:11, 3. Mär. 2016 (CET)

Testprogramm

Der NUXI-Test in dem Testprogramm geht von einer Vertauschung der Nibbles in einem Byte aus (0x1234 -> 0x2143). „NUXI“ als Zeichen sind aber Bytes, also eine Vertauschung von je zwei benachbarten Bytes (0x11223344 -> 0x22114433). Vertauschung von 16-Bit-Wörtern wird nicht überprüft (0x11223344 -> 0x33441122).

Ist dieses Testprogramm überaupt relevant für Wikipedia? --Fomafix 17:24, 5. Sep 2006 (CEST)

Stimmt, du hast recht. NUXI-Endianess oder "middle endian" tritt nur bei 32-Bit-Werten auf. Ich werde das Programm entsprechend anpassen. Die Frage nach der Relevanz des Testprogramms bleibt davon natürlich unberührt. --RokerHRO 18:07, 5. Sep 2006 (CEST)

Bezeichnungen irreführend?

Habe folgendes aus Etymoligie gelöscht: "Die Bezeichnungen sind für Europäer auch irreführend. Man stellt sich die Speicheradressen von der kleineren zur größeren hin als von links nach rechts angeordnet vor. Den Anfang würde man links, das Ende rechts vermuten. Bei Little-Endian kommt aber das niedrigstwertige Byte am Anfang beziehungsweise links zu liegen, das höchstwertige am Ende beziehungsweise rechts."

Bei Little-Endian bezieht sich 'Little' auf die Byte-Enden und nicht auf den Speicher. Es gibt auch die längere Bezeichnung Little-Endian-first, und 'first' bezieht sich auf die Anordnung der Speicheradressen. Das wird im Artikel gut erklärt. In Diskussionen bitte die eigenen Beiträge immer mit --~~~~ (Strich-Strich-Tilde-Tilde-Tilde-Tilde) signieren.

Allerdings hilft die direkte Übersetzung niemandem zum Verständnis und der Einschub bringt dem Satz keine Lesbarkeit "Es gibt mehrere Möglichkeiten, die einzelnen Byte eines solchen Zahlenwerts im Speicher anzuordnen. Die beiden wichtigsten davon werden Big Endian, Big Endian First (wörtlich: „Groß-Endender zuerst“) oder auch Motorola-Format und Little Endian, Little Endian First (wörtlich: „Klein-Endender zuerst“) oder auch Intel-Format genannt." - noch dazu scheint der Artikel nicht wissensfest zu sein, es gibt sehr wohl Prozessoren mit 4-Bit und 32-Bit als kleinster adressierbarer Einheit (Fachbegriff!), für die man die Speicher-Reihenfolge festlegt - daher heisst es auch "Big-Endian", dass keine Nennung von "Byte" als kleinster adressierbarer Einheit enthält. Ich passe mal die Einleitung an, die dem unbedarften Leser etwas Verständlichkeit bringen sollte - wirklich gut wird der Artikel aber erst, wenn er auch theoriefest wird, aber davon fehlt noch ne Menge. GuidoD 10:23, 1. Jul. 2007 (CEST)

Warum benutzt man nicht einfach die Bezeichnung MSByte-first und LSByte-first. Das ist eindeutig und unabhängig von der Vorstellung, ob der Speicher nun von rechts nach links oder anders herum dargestellt wird. Ich würde es gut finden dies als Empfehlung im Text zu erwähnen, damit wir langfristig von diesen Begriffen wegkommen, die nach meiner Erfahrung nach immer wieder falsch verstanden wird. [3. Jul. 2014] (nicht signierter Beitrag von 82.144.57.155 (Diskussion) 14:06, 3. Jul 2014 (CEST))

@82.144.57.155:

1. Links oder rechts kommt sowieso nicht vor.
2. Ob deine Vorschläge "MSByte-first" und "LSByte-first" das Rennen machen werden?
3. Mein Vorschlag "Big-Startian" und "Little-Startian" (s. Einleitung im Artikel) meint genau dasselbe und ist näher am Althergebrachten, nämlich, dass das Feld big resp. little startet an seiner Startadresse.

Zugegeben, es hat schon Termini technici gegeben, die zu weniger Missverständnissen geführt haben. Aber auch den deutschen Titel "Byte-Reihenfolge" finde ich irgendwie zu beliebig und blass – da bringt "Endianness" die Problematik schon eher auf den Punkt. Mein Vorschlag hierzu wäre konsequenterweise "Startianness". --Nomen4Omen (Diskussion) 15:53, 3. Jul. 2014 (CEST)

Unverständlich-Baustein

Ich finde diesen Artikel Mist - wie es dazu gekommen sein mag interessiert mich kaum, vermutlich zuviele Köche. Das absolut schlimmste: Es wird nirgends zentral erklärt, was es nun eigentlich mit Big/Little Endian auf sich hat. Es gibt da dieses Beispiel, da fängt's ja schon an! Solche Sachverhalte sollten erstmal eine Art Definition/Erklärung besitzen, in der glasklar drinne steht, was es ist. Danach kann mna Beispiele nennen.

1. Im ersten Abschnitt steht etwas ähnliches wie ne Erklärung. Ich vermute ja, dass die jemand versucht hat, aus der englischen Wikipedia zu übersetzen. "Wenn wir die 4 Byte in der Reihenfolge D1 C2 B3 A4, also das niedrigstwertige Byte an der niedrigsten Speicheradresse ablegen, spricht man von Little Endian." Was ist denn der Wert eines Bytes? 42? Jemand der nicht weiß worum es geht wird vergeblich versuchen, in dem Artikel irgendwo ne Erklärung des Wertigkeit eines Bytes zu finden. Und wenn man mit Wertigkeit nix anzufangen weiß, ist man absolut aufgeschmissen. Schlimmer noch: man könnte denken es handle sich um dne Zahlenwert des Bytes. Das habe ich damals gedacht, als cih den Artikel zum ersten mal gelesen habe. Da die Erklärung die Wertiggkeit recht oft erwähnt, es aber natürlich keinen Sinn macht, Bytes nach ihrer Größe zu ordnen, bin ich an dem Absatz hängen geblieben und hab mich gewundert warum die Bytes so geordnet werden.

2. Das selbe mit Hex - wer mit Hex nix am Hut hat ist am Ar.... Oben wurde bereits erwähnt, dass sich die Darstellung als Binärzahl anbieten würde, das kann ich nur gut heißen - Zahlen werden intern schließlich nich mit Buchstaben codiert, sondern mit 0 und 1.

Ähemm ... intern gibt es keine Nullen und Einsen, das sind wieder nur Interpretationen auf der menschlichen Ebene. Mit "intern sind es nur a und b" würde es genauso klappen (auch wenn die Umrechnung in Dezimalzahlen dann etwas abstrakter wird). Intern sind es elektrische Zustände (hohe/niedrige Spannung) bzw. je nach Hardware auch noch andere Gegensätze (unterschiedliche Magnetisierung, Polarisation und was weiß ich).

Und deshalb ist es nur eine Frage der Konvention, ob jedes Bit einzeln dargestellt oder Bits gruppiert werden. Sobald von 0 und 1 die Rede ist, wird die interne Darstellung schon interpretiert, und dann ist "von 0 bis F" nur eine andere Interpretation, die dann praktischer ist, wenn es nicht sinnvoll ist, die einzelnen Bits zu trennen.

Allerdings: hätte man statt D1 C2 B3 A3 so was wie 15 74 52 90 gewählt, dann würde (1) kein Laie an Hexzahlen scheitern und (2) wäre klar, dass es nicht um "Wertigkeit" im Sinn von "Inhalt des Bytes" geht.

--Helmut w.k. (Diskussion) 14:50, 27. Jun. 2018 (CEST)

3. Wenn man jemandem etwas mit Beispielen erklärt, dann nimmt man zuunächst einfache Beispiele und nicht gleich 4-Byte-Datentypen in Hex-Darstellung Oo

Insgesamt ist der Abschnitt gelinde gesagt ungeschickt gemacht - dabei könnte es so einfach sein:

Es gibt zwei Arten der Byte-Reihenfolge:

1. Die "normale" Reihenfolge Big Endian in der man eine abgespeicherte Zahl auch aufschreiben würde

2. Die umgekehrte Veriante. Beispiel: Die Zahl 2 als Binärzahl mit 16 Stellen (zB unsigned short) (0000000000000010)b = 2

 BigEndian:    Normale Reihenfolge    1.Byte:00000000 2. Byte: 00000010
 LittleEndian: umgekehrte Reihenfolge 1.Byte:00000010 2. Byte: 00000000

Und schon ist ohne Umwege alles geklärt. Jetzt kann man gern das hex-beispiel hinterherschieben.

Im Grunde ist der Artikel vielleicht ok, aber wer es nicht ohnehin schon weiß, wird es mit diesem Artikel auch kaum lernen. Daher fänd ich es toll, wenn da mal jemand aufräumt. Wenn sich hier keiner meldet oder es macht, werd ich ihn mir selbst vorknöpfen. Aber ich dachte ich frag lieber erstmal. :)

Hallo,

zu 1) zu der Wertigkeit eines Bytes gibt es bereits Artikel nämlich http://de.wikipedia.org/wiki/Bitwertigkeit und http://de.wikipedia.org/wiki/Stellenwertsystem . Da die Wertigkeit eigentlich ja auch im Dezimalsystem vorkommt (und zumindest ich das auch in der Schule gelernt habe...) würde ich eigentlich nur auf die entsprechenden Artikel verlinken.

zu 2) Auch hier gibt es einen Artikel, der einem das toll erklären sollte: http://de.wikipedia.org/wiki/Hexadezimal Auch wenn der Computer intern natürlich 1 und 0 abspeichert, ist es meiner Meinung nach übersichtlicher hexadezimale Zeichen zu verwenden.

zu 3) Sehe ich etwas anders: Ein Beispiel mit 4 Byte finde ich aussagekräftiger, da man hier z.B. eher sehen kann, dass es eben nicht nach dem Wert des Bytes sortiert wird sondern nach der Wertigkeit.

--137.226.196.27 09:51, 16. Apr. 2007 (CEST)

Da wo der Artikel das Problem anhand der Umgangssprache erklärt, ist mir zum ersten Mal klar geworden, dass es kein "normal" (=Norm) und "unnormal" oder "richtig" und "falsch" gibt. Schließlich schreiben wir "vier-zwei" (42) und sprechen "zwei-(und)-vier-(zig)". Wenn man im obigen Beispiel die Bytes untereinander schreibt, ist es auch sofort vorbei mit normal und umgekehrt, weil man sich von der Vorstellung einer langen Binärzahl löst und mehr den technischen Speicher vor sich sieht:

            Big-Endian   Little-Endian    
    Byte 0: 00000000     00000010 
    Byte 1: 00000010     00000000

Ansonsten gefällt mir das neue Beispiel sehr gut. Das mit dem "A4..D1" habe ich noch nie verstanden. Was auch immer für Hex-Zahlen spricht, hier würde ich sie rauslassen, weil sie eine zusätzliche Abstraktionsebene ins Spiel bringen, die nur verwirrt. --Gerd-HH 15:21, 31. Jul. 2007 (CEST)

Sehe das nicht ganz so, ich würde auch weiterhin ein aus 4 Bytes bestehendes Beispiel und auch eine Hex-Darstellung sinnvoll finden, da man bei dieser übereinstimmende Bytes schneller erkennt. Mein Vorschlag wäre, hex und Binärdarstellung darzustellen. Zudem könnte man auch die dezimale Entsprechung der Integer-Zahl angeben.--Cactus26 15:29, 31. Jul. 2007 (CEST)

Gute Idee! :-) --RokerHRO 15:39, 31. Jul. 2007 (CEST)

Schön, dann ist der Baustein wohl geklärt und kann raus? __Bücherwürmlein ^Disk-+/- 22:44, 2. Aug. 2007 (CEST)

Na ja, noch nicht ganz. Habe zumindest mal versucht, die Sache in die Tat umzusetzen. Wenn's Euch nicht passt, macht es rückgängig.--Cactus26 13:33, 3. Aug. 2007 (CEST)

Der Unverständlich-Baustein hat in dem Abschnitt jetzt auf jeden Fall nichts mehr zu suchen. -- Klara 23:02, 8. Aug. 2007 (CEST)

Vor- und Nachteile

Es geht im gesamten Artikel um etwas sehr einfaches, was man mit zwei Sätzen erklären kann. Dann kann man noch ein Beispiel mit einem Satz hinzufügen. Was nicht klar erkärt wird, sind die Vor- und Nachteile, bzw. wie es zu den Unterschiedlichen Darstellungen kommt. --W8 04:36, 28. Jul. 2007 (CEST)

So eindeutige Vor- oder Nachteile hat weder das eine noch das andere Format. Sonst hätte es ja das andere Format schon längst verdrängt. ;-) Was genau hältst du am Artikel denn für überflüssig? Mach doch bitte konkretere Vorschläge. --RokerHRO 20:48, 28. Jul. 2007 (CEST)

Es gibt diese Formate nicht ohne Grund. Es hängt mit der Strategie zusammen, die man verfolgt (Type-Casting/MISC/Kompatibilität). Das sind auch die Vor- und Nachteile. Daraus begründen sich die beiden Formate.

Ich schlage vor, den jetzigen Stand komplett zu überarbeiten. --W8 13:59, 30. Jul. 2007 (CEST)

Das wäre mir neu. Kannst du dafür Quellen angeben? Meines Wissens sind die beiden Formate schlicht historisch in verschiedenen Prozessorfamilien so entstanden, und dabei ist es bis heute geblieben.

Du hast im Übrigen noch immer nicht genannt, was du konkret am Artikel auszusetzen hast bzw. was genau du überarbeiten willst. --RokerHRO 14:30, 30. Jul. 2007 (CEST)

Worüber handelt denn dieser Artikel? Es gibt zwei Reihenfolgen: 1) Vorwärts 1-2-3-4 und 2) Rückwärts 4-3-2-1. Rückwärts gibt es einen Vorteil: Man kann eine Type-Casting vornehmen, ohne den Zeiger zu verändern. Dafür kann man z.B. einen Datenstrom nicht mehr intuitiv vergleichen. Bei RISC-Architekturen ist kein Type-Casting vorgesehen, alle Register haben die gleiche Breite. Deswegen ist die Reihenfolge hier vorwärts und ein Datenstrom ist wohl geordnet.

Die Intel-Prozessoren sind abwärtskompatibel, deswegen gibt es hier gleichzeitig 8, 16, 32 und eventuell 2x32 oder 64-Bit Register. --W8 01:28, 31. Jul. 2007 (CEST)

Jetzt musst du, damit es für einen Enzyklopädie-Artikel reicht, nur noch genau definieren, was du mit 1-2-3-4 bzw. 4-3-2-1 meinst, was du mit "intuitiv vergleichen" meinst und was Typecasting bedeutet, ist mir verständlich, ob es für WP:OMA reicht, weiß ich nicht.

Auf RISC-CPUs, die eh nur datenwortweise auf den Hauptspeicher zugreifen, ist es ziemlich wurst, wie die Bytes in diesem Datenwort im Hauptspeicher angeordnet sind. Was meinst du nun mit "vorwärts" und wohl geordnet? --RokerHRO 06:50, 31. Jul. 2007 (CEST)

Sicher kommt man mit logischem Denken auf der Bitebene zu bestimmten Vor- und Nachteilen. In der Praxis ist es einfach schlecht, wenn man mit reiner Zeigerarithmetik die Zahlen (im Zweierkomplement) konvertiert - in echt sollte man schon Wertprüfungen vornehmen, den Wert also komplett laden, und sowieso - Ein-Byte-Laden/-Ändern findet in Zeiten von CPU-Caches egal keinerlei Vorteile. Da es Hauptspeicher-lokal keine drängenden praktisch relevanten Nachteile gibt, wird auch keines der Formate alsbald fallengelassen. -

Wollte man allerdings frei dahertheoritisieren, wo es denn Vorteile gibt, so könnte man so pi mal Daumen sagen, dass Embedded-Prozessoren (gerade 8/16-Bit) eher zu Little-Endian neigen (kaum Caches vorhanden, Speicherplatzsparen und Subwert-Adressierung/Unions mit Bitfummeln bei Programmierern beliebt), während größere Systeme mit der traditierten Network Byteorder eher zu Big-Endian neigen um häufige Byteswaps zu vermeiden (daher auch Bi-Endian eingeführt, die das beim Laden "nebenbei" mitmachen). Das könnte auf Entscheider-Ebene eher zu dieser oder jener Designrichtung führen als "ich kann das Vorzeichen-Bit schneller erreichen". Pff. -

Im übrigen ... ich selbst hänge eh der Meinung an, dass Little-Endian eher "natürlich" strukturiert ist (Bit 0 bis Bit 31 aufsteigend auf Byte 0 bis Byte 3 aufsteigend verteilt), dass die Network Byteorder jedoch aufgrund der üblichen Hexdump Lesrichtung aufkam, also links-nach-rechts, jedes Byte mit Hi-Nibble zuerst, was mit der traditionellen Buchschreibung von Zahlen ausserhalb des Computers übereinstimmt. So wird Big-Endian 0xDEADAFFE = hexdump DE.AD.AF.FE, Litte-Endian 0xDEADAFFE = hexdump FE.AF.AD.DE. Und man sollte nie die Notwendigkeit von Debugging und Hexdumplesen unterschätzen, da ist praktisch sehr relevant. Hexdumplesen fehlt mir übrigens im Artikel derzeit. GuidoD 08:39, 31. Jul. 2007 (CEST)

Das Grundübel in dem Unterschied zwischen der "natürlichen" (wie du sie nennst) Reihenfolge (Little-Endian), und der Leserichtung von Hexdumps kam daher, als die Europäer die Arabisch-indischen Zahlen von den Arabern, deren Schrift ja bekanntlich von rechts nach links läuft, in ihre von links nach rechts laufende Schrift übernahmen, dabei aber "Endianess" der Dezimalziffern beibehielten. :-( Leider lässt sich der Fehler von damals heute nicht mehr ausmerzen. --RokerHRO 13:02, 31. Jul. 2007 (CEST)

WIMRE, ist da eine klassische Falschvermtung - arabisch spricht man die Zahlen (bis auf die Hunderter) auch "Big-Endian" von links nach rechts. Da es auch in der Wikipedia nicht deutlich wird, hab ich es in der Diskussion:Arabische Ziffern nochmal vermerkt. GuidoD 19:42, 31. Jul. 2007 (CEST)

Ich schrob ja auch nur etwas von "Schreibweise", nicht "Sprechweise", da mir letztere für Arabisch nicht bekannt ist und ich sie für das Problem des Lesens & Schreibens auch für irrelevant halte. --RokerHRO 08:06, 1. Aug. 2007 (CEST)

Die, die hier mitdiskutieren, werden wissen, was ich mit 1-2-3-4 und 4-3-2-1 meine. (Hier ist nur der Diskussionsfaden und nicht der Artikel.) Natürlich ist: 2 hoch 0 = 1. Es passt einfach besser in die Potenzgesetze und weicht von der Definition aus der Grundschule ab. Und wenn etwas kurz ist und dann auch noch besser passt, dann ist irgendwie natürlicher.

Man kann auch nicht in ein Byte hineinschauen. Ob die Bits in einem Byte 5-2-3-7-6-1-0-4 angeordnet sind lässt sich von außen nicht erkennen. Hauptsache ist, dass wenn man nach links schiebt, das höchste Bit im Carry-Flag landet.

Richtig ist auch, dass beim Type-Casting Ergebnisse verfälscht werden können, zumindest, wenn man die Anzahl der Bytes reduziert.

Ob Bytes im Arbeitsspeicher LINKS oder RECHTS stehen, hängt außschließlich von der eignenen subjektiven VORSTELLUNG ab. Für einen Araber ist das erste Zeichen rechts, für einen Europäer links. Für einen Computer gibt es weder LINKS noch RECHTS, es gibt für ihn nur das erste, zweite, ... Zeichen. Der Adressraum von einem Computer wird mit einer Zahl adressiert, nicht mit einer geographischen Position. (Zumindest noch nicht.)

Ich finde, dass der Artikel kürzer gestaltet werden kann. Hat jemand Einwände, wenn ich den Artikel verändere? --W8 23:32, 31. Jul. 2007 (CEST)

Ja, ich habe Einwände, wenn du nicht vorher konkret mal sagst, was dich am Artikel stört und was genau du löschen willst, worum ich dich bereits mehrfach gebeten habe. --RokerHRO 08:08, 1. Aug. 2007 (CEST)

"Um auf einer Little-Endian-Maschine eine Zwei-Byte-Zahl in eine Vier-Byte-Zahl zu verwandeln, müssen lediglich zwei mit Null gefüllte Bytes am Ende angefügt werden, ohne dass sich die Speicheradresse ändert. Auf einer Big-Endian-Maschine muss der Wert zuvor im Speicher um zwei Bytes verschoben werden." Ich halte diese Aussage für nicht sinnvoll. I.d.R. wird es nämlich Probleme geben Variablengrößen einfach mal so zu ändern. Eine Variable liegt häufig in einem der folgenden Segmente:
"data"/"bss": um dort eine Variable zu verlängern reicht ein Überschreiben (im Sinne: über die Länge hinaus), funktioniert aber lediglich wenn die nachfolgende Variable ausgerichtet wurde (in diesem konkreten Fall an 4Byte unter der Annahme, dass die zu änderende Variable auch an 4Byte ausgerichtet wurde)
"stack": in einem Stack eine Variablenlänge zu überschreiben ist..."mutig", es sei denn es wurde viel Speicher angefordert, dann verhält es sich wie in "heap" Fall i) beschrieben
"heap": hier gibt es grundsätzlich 2 Fälle zu unterscheiden: i) es wird auf einen Schlag Speicher für viele Variablen angefordert und man kümmert sich selbst um die tatsächliche Speicherverwaltung, dann mag es möglich sein allgemein die Variablenlänge zu ändern, oder ii) es wird Speicher für eine Variable angefordert, dann könnte es (abhängig vom Betriebssystem) schwierig werden weiteren Speicher direkt vor/hinter der ursprünglichen Variable zu bekommen. In beiden Fällen gilt allerdings, das die Variable über einen Zeiger angesprochen wird (u.U. sogar als Zeiger+Offset) daher ist es egal ob ich die Speicheradresse beibehalte (und ein paar Byte weiterlese) oder den Zeiger de- resp. inkrementiere
Sorry für die wall of text, hoffe ich konnte mein Anliegen verständlich machen. --77.64.254.162 23:39, 18. Jul. 2013 (CEST)

64 Bit, Zeichenketten, Fließkommazahlen

Am Anfang des Artilel steht, dass die Byte-Order "in erster Linie" für Integer-Zahlen gilt. Was passiert denn mit Fließkommazahlen und Zeichenketten? Sind die von der Byte-Order betroffen? Und geht es bei 64 Bit um Blöcke von 8 Byte Länge statt 4 Byte bei 32 Bit? OnkelSchuppig 20:14, 7. Sep. 2007 (CEST)

Für Fließkommazahlen spielt "Endian" wohl auch eine Rolle (siehe IEEE 754, wusste ich allerdings auch nicht und habe es durch diesen Artikel gelernt). Ob das für alle Fließkommaformate gilt, weiß ich nicht. Bei 64-bit Integerwerten ist das Prinzip analog 32-bit. Interessant ist ja auch, dass Speicheradressen selbst (in C Pointer) ja auch dieser Reihenfolge unterliegen. Bei Zeichenketten allerdings spielt "Endian" keine Rolle. Könnte man vielleicht noch im Artikel ergänzen.--Cactus26 07:45, 10. Sep. 2007 (CEST)

Für Gleitkommazahlen (sic!) gilt das gleiche wie für Integerzahlen. Bei 64-Bit-Werten, egal ob IEEE-double oder 64-bit-Integer sind es eben acht Byte, die entweder in der Reihenfolge 12345678 oder 87654321 gespeichert werden. --RokerHRO 12:17, 10. Sep. 2007 (CEST)

Bit-Order vs. Byte-Order

Gibt es nicht zwei unterschiedliche Phänomene. Ich lese immer wieder verschiedene Erklärungen von Little-Endian und Big-Endian und diese Erklärungen widersprechen sich meistens.

• Bit-Reihenfolge:

11100011 10110101 -> 10101101 11000111
   E3       B5          AD       C7

• Byte-Reihenfolge:

11100011 10110101 -> 10110101 11100011
   E3       B5          B5       E3

Weiß jemand was ich meine?

(2007-10-06T00:30:12) Croorg

Nein, denn der Bezug für die Byte-Reihenfolge ist die kleinste adressierbare Einheit (durch Edits der letzten Zeit steht es als Eigenbegriff im Artikel nicht mehr besonders heraus). Die physische Ablage der Bits innerhalb der kleinsten adressierbaren Einheit sind irrelevant. Woran du vielleicht denkst ist die Serialisierung in einen digitalen Leitungscode, bei dem tatsächlich die Bits gesehen werden. Allerdings ist die Bitcodierung einer Leitung bei weitem nicht mit einer bloßen Reihenfolge zu beschreiben, noch dazu erfolgt die Kodierung nahezu aller Leitungsprotokolle zu mehreren Bit je Symbolschritt, im Regelfall gar zu 7 oder 8 Bit, sodass jedes übertragene Byte aus Kodierung-Dekodierung gesichert den gleichen Byte-Wert ergibt - und zwar egal wie die Bits in die Leitung gegeben wurden. .... Aber vielleicht meinst du ja doch was anderes? GuidoD 00:59, 6. Okt. 2007 (CEST)

nein, ich meine schon Endianess. Im Prinzip dürfte die Erklärung im Artikel sogar stimmen, aber mir ist dabei unklar, da es meiner Ansicht nach einen Widerspruch darin gibt sowohl die Byte-Reihenfolge umzudrehen alsauch das Least Significant Bit von der eine Seite auf die andere zu wechseln, was einer Umdrehung der Bit-Reihenfolge entspricht. Um das Beispiel des Artikels (Wert 0x1A2B3C4D) aufzugreifen:

* Wenn das LSB statt rechts links ist:

00011010 00101011 00111100 01001101 -> 10110010 00111100 11010100 01011000
   1A       2B       3C       4D          B2       3C       D4       68

* Wenn das erste Byte statt links rechts ist:

00011010 00101011 00111100 01001101 -> 01001101 00111100 00101011 00011010
   1A       2B       3C       4D          4D       3C       2B       1A

Es ist auch denkbar das ganze nur jeweils wortweise (ursprünglich: 1 Word = 16-Bit) durchzuführen.

Mal angenommen der Artikel stimmt so wie er im Moment ist, sollte er dann aber nicht solche Unklarheiten klären?

Aber ok ich sehe schon, Endianness hat eigentlich nichts mit Bit-Reihenfolge zu tun. Das wirkt nur so da man immer die Bytes anhand der Signifikanz der Bits durchnummeriert.

2007-10-06T14:45:31 Croorg

Ich hab den Eindruck, dass hier eine Irritation auftritt, da zur Darstellung im Artikel ja die Zahlenwerte der Bytes aufgeschrieben werden müssen - und dabei wird sowohl für hexadezimale wie für die duale Darstellung die übliche Schriftform wie bei dezimalen Zahlen verwendet, also immer MSB zuerst, egal welche Byteordnung gerade besprochen wird. Im Grunde eine Kodierungsform je Symbolschritt. Im Artikel ist der angezeigte Symbolschritt je Byte, dass die Schrittweite auch anders sein kann, wird nur beiläufig erwähnt (gezeigt im "NUXI" Beispiel). GuidoD 15:14, 6. Okt. 2007 (CEST)

Ich bin der Meinung, dass die Aussage "Dagegen speichert Little Endian sowohl die Bytes (wie die Bits, siehe unten) in der umgekehrten Reihenfolge..." nicht nur Verwirrung stiftet, sondern falsch ist. Der Ausdruck in Klammern über die Bits sollte entfernt werden. (nicht signierter Beitrag von 193.24.32.44 (Diskussion) 10:40, 7. Mai 2015 (CEST))

OK, es ist zwar nicht falsch, aber hier unnötig. --Nomen4Omen (Diskussion) 11:31, 7. Mai 2015 (CEST)

"Mittle Endian" bei x86/x64?

Einige ältere Systeme oder moderne CPUs der x86/x64 Architektur (wenn sie sich im Realmode befinden) speichern die Daten auch in der Reihenfolge 3C 4D 1A 2B oder auch 2B 1A 4D 3C (letzteres gilt für x86/x64 CPUs im Realmode), beides wird heute als Middle Endian bezeichnet.

Stimmt das wirklich für x86- und x64-CPUs? --212.114.205.149 12:25, 14. Jan. 2008 (CET)

Nö. Wo hast du das denn her? --RokerHRO 14:43, 14. Jan. 2008 (CET)

steht so im Artikel! --89.60.26.178 21:10, 14. Jan. 2008 (CET)

korrigiere: stand so im Artikel! Danke für die Klarstelliung. --89.60.26.178 21:12, 14. Jan. 2008 (CET)

Ich habs ja eben rausgenommen. :-) --RokerHRO 13:55, 15. Jan. 2008 (CET)

Fehler bei Dezimalzahl

"Im folgenden Beispiel wird die Ganzzahl 439.041.101 als 32-Bit-Integer-Wert gespeichert (Binär: 00011010 00101011 00111100 01001101, hexadezimal: 1A 2B 3C 4D)." Also entweder das ist ein Fehler oder ich habe gerade das berühmte Brett vor'm Kopf. Die Binär und hexadezimale Zahl stimmt doch mit der ganzzahl, die sicherlich in Dezimal gegeben ist, gar nicht überein. So ist doch z.B. 1A in dezimal 26, wie ja auch in der Tabelle rechts daneben steht und nicht 439. Davon abgesehen, dass man ja in 8 Bitt auch nur bis max. 255 speichern kann. Ist das jetzt ein Fehler oder übersehe ich was? Mit bitte um aufklärung bzw. änderung --84.161.203.249 20:27, 26. Nov. 2008 (CET)

Die Dezimalzahl 439041101 wird nach WP:SVZ mit Punkten zur Zifferngruppierung geschrieben: 439.041.101. --Fomafix 20:35, 26. Nov. 2008 (CET)

Argh, jetzt hab ich es kapiert. Finde das aber total verwirrend, hier die Tausendertrennzeichen zu benutzen, macht es doch den Eindruck, es handelt sich um in der IT übliche Trennzeichen zur Trennung von Blöcken. Die von dir verlinkte Wiki-Richtlinie würde ich in diesem Fall nicht anwenden, da es sich ja um ein IT-spezifisches Problem handelt. Ich persönlich fände es zumindest deutlich verständlicher, wenn die Tausendertrennzeichen nciht da wären (obwohl ich das auch vom ästhetischen Gesichtspunkt nicht die optimale Lösung finde) --84.161.203.76 09:53, 27. Nov. 2008 (CET)

Genauso ging es mir gerade jetzt beim ersten Betrachten. Ich habe deshalb mal den Beginn des Zahlwortes in Klammern dahinter gesetzt. Zwar sind IP-Adressen viergliedrig wobei jedes Glied nicht größer als 255 sein kann, aber die optische Wahrnehmung rastet eben doch falsch ein. Grüße --213.23.174.67 12:05, 25. Okt. 2011 (CEST)

Bit-Reversing

Wenn bei der Gegenüberstellung von Little und Big Endian schon die Binärdaten mit aufgeführt werden, so sollte man im Artikel vielleicht auch irgendwo das Stichwort "Bit-Reverse" auftauchen. Der MicroBlaze von Xilinx zum Beipsiel kennt auch ein Little Endian bit-reversed und Big Endian bit-reversed. Und das bezieht sich nicht auf die Art der seriellen Übertragung, sondern hat Auswirkungen bei paralleler Übertragung auf Datenbussen.

Zur Veranschaulichung: 0x01 in der Software wird bei Speicherung in einem 8 Bit Hardware-Register zu 0x80. LSB bleibt LSB, aber hier verweist dann Register-Index 7 auf das LSB! (nicht signierter Beitrag von 93.223.254.169 (Diskussion) 19:37, 17. Dez. 2011 (CET))

Register?

Zum Abschnitt Byte-Reihenfolge#Diagramm zur Abbildung von Registerwerten auf Speicheradressen habe ich ein paar Fragen:

1. Meines Wissens kann man Registerwerte zum Adressieren von Speicher verwenden. Ist das mit Abbilden von Registerwerten auf Speicheradressen gemeint ?
2. Meines Wissens wird ein zusammenhängender Speicherbereich standardmäßig durch seine Anfangsadresse und seine Länge spezifiziert. (Letztere kann auch implizit gegeben sein.) Das durch die Anfangsadresse bezeichnete Ende wird auch linkes Ende des Speicherbereichs genannt. Register haben Längen von 1,2,4 oder 8 Bytes. Laden und Speichern von Registern gehören zu den wichtigsten Instruktionen. Liegt es nicht nahe, dass die Abbildung von Registerinhalten auf Speicherinhalte 1:1 ist ? Genauer: die linke Seite des Registers geht auf die linke Seite des Speicherbereichs und so fort.
3. Wenn diese Abbildung 1:1 ist, wie kann sie dann bei der Erklärung der Endianness helfen ?

--Nomen4Omen (Diskussion) 20:41, 17. Mai 2014 (CEST)

Ehrlich gesagt würde ich diesen Abschnitt (samt Bild) einfach löschen. ME. bietet er keinen konkreten Mehrwert (vor allem nach deinem Einfügen mit dem Hexdump-Beispiel). Und es suggeriert mir irgendwie, dass eine "Abbildung von Registerwerten nach/in Speicheradressenwerte" irgendwas Spezielles sei.--Plankton314 (Diskussion) 21:01, 18. Mai 2014 (CEST)

@Nomen4Ohmen zu 2. Nein es liegt nicht nahe. Es ist sogar irrelevant für die Darstellung im Speicher, denn man kann jederzeit mit interner Verdrahtung die Endianness verändern und es gibt schon gar keine vorschrift, wie die Interne Verdrahtung sein muss. --85.16.71.3 20:07, 10. Jan. 2015 (CET)

@85.16.71.3: OK, wir dürfen doch sicher annehmen, dass da irgendwas verdrahtet ist. Dann definieren wir das im Register, was mit der niedrigen Speicheradresse verdrahtet ist, als niedrige Adresse auch im Register. Und entsprechend in den Adressen aufsteigend. Gibt's eine andere Möglichkeit? --Nomen4Omen (Diskussion) 20:30, 10. Jan. 2015 (CET)

Hexdump + Bitorder

Irgendwie wiederspricht sich der Hexdump zum vorherigen. Erst wird gesagt Big Endian, also MSB(yte) an kleinste Adresse und im Hexdump entspricht die kleinere Adresse dann dem LSB!

Ganz abgesehen davon ist diese Tabelle hundsmiserabel! Wahrscheinlich versteht auch keiner außer der Autor diese Tabelle! => Bin der Meinung sollte dringend überarbeitet oder gelöscht werden!

Zudem ganz nebenbei: Seit wann hat Endianess was mit der Bit-Order zu tun?!:

Dagegen speichert Little Endian sowohl die Bytes (wie die Bits, siehe unten) in der umgekehrten Reihenfolge

Beispiel:
Big Endian: MSB(yte)+MSB(it) -> 01 02 <- LSB = 01 02 (0000 0001 | 0000 0010)
Little Endian: MSB(yte)+MSB(it) -> 01 02 = MSB(it) + LSB(yte) -> 02 01 (0000 0010 | 0000 00001)

Im Artikel wird daraus aber gemacht:
Big Endian: MSB(it) -> 01 02 = 01 02 (0000 0001 | 0000 0010)
Little Endian: MSB(it) -> 01 02 = LSB(yte) + LSB(it) -> 40 80 (0100 0000 | 1000 0000)

Verbesserungsvorschläge: Ein Schaubild für Big-Endian und Little-Endian mit Repräsentation im Speicher und im Register jeweils. Dabei Kennzeichnung von MSB + LSB (Bit) im Speicher und Bit-Nummerierung im Speicher und Register (eventuell Verbindungslinien von jedem Bit im Speicher zu den Bits im Register). Das alles im Dualsystem. (Hexadezimal verwirrt mehr bei Bitpositionen, was jetzt ja schon von mehreren angemerkt wurde). Zudem konsequent MSB Links und LSB rechts => Gewohnte Darstellung => Big-Endian!

Damit kann mehreres klar gestellt werden:

1. Unterschied zwischen Byte-Reihenfolge und Bitfolge
2. Unterschiede zwischen Little-Endian und Big-Endian und
3. Auswirkungen auf die Darstellung im Speicher/Dateien und Verarbeitung/Darstellung im Register => Unterschied zwischen Rechts-Links-Shift

Zudem schlage ich eine genauere (auf den Punkt gebrachte) Differenzierung des Zusammenhangs Bit-Endianness und Byte-Endianness vor. Ich finde der englische Artikel zur en:Endianness ist ein gutes Beispiel. Allein die Schaubilder am Anfang des Artikels sagen schon mehr aus, als die ersten 50 Zeilen Text in diesem Artikel, wobei auch diese nicht klar machen ob jetzt ein Umkehrung der Bit-Reihenfolge/Nummerierung im Speicher/Register stattfindet, oder ob sie gleich bleibt (laut Bild bleibt sie gleich).

--85.16.71.3 21:21, 10. Jan. 2015 (CET)

@85.16.71.3: Auf jeden Fall wurde weiter oben im Abschnitt #Register? von zwei(!) Leuten schon mal festgestellt, dass der Weg übers Register zur Klärung rein gar nichts nichts beiträgt. --Nomen4Omen (Diskussion) 21:55, 10. Jan. 2015 (CET)

Die Missverständnisse im Kontext der Endianness sind zahllos (siehe diese Disku und die Diskus in den anderen Sprachen). Woher das kommt ? Es sei hier wieder einmal ein Versuch unternommen, etwas Ordnung zu schaffen.

1. (Kleinigkeit) Im Beispiel oben von 85.16.71.3: Das LSBit von 1 ist 1 und von 2 ist 0. (Es geht jeweils um die Binärdarstellung.) In einem Byte von 8 Bits ist das MSBit von 128 eine 1.
   Deshalb muss es im Beispiel heißen: 'MSB 0' und 'LSB 0' und nicht MSB und LSB, da es doch sicherlich um eine Darstellung oder Anordnung und nicht um ein einzelnes Bit gehen soll. (siehe auch die Artikel Bitwertigkeit und englisch en:Bit numbering)
2. Weiterhin das Beispiel von 85.16.71.3:
   Big Endian wird die Zahl 258 = 0x0102 im Speicher als (0x01, 0x02) = bitweise als 0000 0001 0000 0010 dargestellt.
   Little Endian wird die Zahl 258 = 0x0102 im Speicher (übereinstimmend mit 85.16.71.3) als (0x02, 0x01) dargestellt, wobei das Klammerpaar die aufsteigende Aufeinanderfolge der Bytes im Speicher ausdrücken soll. Im Artikel und noch deutlicher im Artikel Bitwertigkeit#Adressierung von Bits wird dargelegt, dass und wie die Shift-Befehle (Links-Bit-Shift wie Rechts-Bit-Shift) von der Adressierung der Bytes eine Adressierung auf die Bits übertragen, sie also in eine Reihenfolge bringen, die mit 8fach-Links-Bit-Shift wie 8fach-Rechts-Bit-Shift, also der Byte-Reihenfolge verträglich ist. Folgt man dieser Überlegung, dann ist die bitweise Darstellung von Little Endian 258 die Bitkette 0100 0000 1000 0000. Es wäre ein essentieller Irrtum, dies für die Zahl 0x4080 zu halten. Dieser Irrtum wird im Artikel auch nirgendwo begangen.
   (Ob allerdings die Verfahren der Serielle Datenübertragung sich an diese von den Shifts induzierte Ordnung halten oder zu halten hätten, ist damit überhaupt nicht gesagt – die können das dann doch wieder ganz anders machen, so dass ausdrücklich gesagt werden muss, wie sie's machen.)
3. Die Verbesserungsvorschläge von 85.16.71.3: Die Bezugnahme auf ein Register in den nebenstehenden Schaubildern, die sich leider im Artikel en:Endianness und in vielen wikis in anderen Sprachen findet, hilft in keiner Weise.
   Da nämlich eine Orientierung des Registers in (links,rechts) oder (unten,oben) oder (vorne,hinten) nicht existiert, gibt es nur den Speicher, der eine Orientierung hineinbringt. Und zwar in 2 Versionen: (1) die Abfolge der aufsteigenden Adressen und (2) die Wertigkeit der darin enthaltenen Bytes und Bits, also der Wert der durch Bytes/Bits dargestellten Zahl. Diese beiden Orientierungen sind aber genau das Thema der Endianness. (Etwas besser einzusetzen wären die beiden Grafiken, wenn sie mit „Zahlwert“ oder „32-bit-Integer(-Wert)“ überschrieben wären anstatt mit „Register“ und beim Zahlwert ein kleines h angehängt wäre.)

--Nomen4Omen (Diskussion) 18:43, 12. Jan. 2015 (CET)

Nachdem 85.16.71.3 sich an der Diskussion nicht beteiligt, wird der von ihm gesetzte Überarbeiten-Baustein wieder entfernt. --Nomen4Omen (Diskussion) 19:30, 18. Jan. 2015 (CET)

Noch ein Wort zur Historie

Den einen oder anderen mag es wundern, warum Hersteller von Schaltkreisen (hier Prozessoren) den einen oder den anderen Weg gingen. Beide Wege haben entscheidende Vorzüge.

Denken wir daran, dass jeder Übertrag bei allen arithmetischen Operationen von der niederwertigsten zur höchstwertigen Stelle geht, dann spart es im Pipelining Zeit, Daten genau in dieser Reihenfolge zu lesen und zu schreiben. Wir übertragen vorteilhaft das niederwertigste Bit zuerst. Zu einer Zeit, als CPUs noch mit 2,5 MHz liefen, konnte das Vorteile bringen. Daraus mag Little Endian entstanden sein.

Auf der anderen Seite sind wir es beim Rechnen gewohnt, die niederwertigste Position ganz rechts zu schreiben. Unsere Fehlerquote steigt immens, wenn wir jede Zahl in Gedanken umkehren müssen. So begnügen wir uns damit, alles schriftliche in Big Endian (als Bit- und Byte-Ordnung) zu notieren.

Heinzelmann (Diskussion) 08:42, 3. Mär. 2016 (CET)----

Deutsches Äquivalent

Zitat: Big-Endian (wörtlich „Groß-Ender“, ...)

Wörtlich ist das doch eher "großendig": big end ist das "große Ende" und -ian macht daraus ein Adjektiv (das könnte natürlich wieder substantiviert sein). Könnte es sein, dass "Groß-Ender" aus "Groß-Endender" entstanden ist? Wobei ich bei "endender" eher an "ending denken würde. Also besser "großendig". Und entsprechend "kleinendig".

--Helmut w.k. (Diskussion) 15:09, 27. Jun. 2018 (CEST)

Ist das BOM-Beispiel etwas überladen?

Hi,

Ich starre jetzt schon eine Weile auf die sehr kompakten zwei Zeilen Text für das BOM-Beispiel und sehe da Passagen die mir nicht verständlich sind oder gar überflüssig.

Das steht:

In einem Hex-Editor sieht ein Text folgendermaßen aus:

00 44 00 69 00 65 | D i e| BOM 00 44 = FE FF am Dateianfang $\Rightarrow$ UTF-16 Big Endian / UCS-2BE
44 00 69 00 65 00 |D i e | BOM 44 00 = FF FE am Dateianfang $\Rightarrow$ UTF-16 Little Endian / UCS-2LE

Ich sehe hier folgendes:

• Zwei Zeilen die Zwei unterschiedliche Datei-Anfänge beschreiben
• Nach "$\Rightarrow$" wird eine Interpretion eines 6-Byte-Abschnitts geliefert
• Vor "$\Rightarrow$" wird der 6-Byte-Abschnitt unterschiedlich dargestellt und die Darstellungsvarianten sind durch "|" voneinander getrennt
  • Hexadezimal (ohne BOM)
  • Zeichen (ohne BOM, NUL-Byte wird als Space dargestellt)
  • ??? symbolische Darstellung, dass der BOM jetzt hinzugefügt wird ??? und "0x0044"/"D" als partielle Wiederholung ??? "=" gefolgt von der Hexadezimal-Darstellung des BOM in UTF-16 die an den Dateianfang gestellt wird.

Übersehe ich hier irgendwas Relevantes?

Ich würde Vorschlagen:

• Wirklich die Darstellung aus dem Hex-Editor zu übernehmen. Der wird es nicht ohne BOM zeigen, wie hier.
• Die Hex-Editor-Darstellung und die Erklärungen klarer voneinander trennen

D.h. konkret:

Der Text "Die" (drei Zeichen, 6 Byte) mit BOM (ein Zeichen, 2 Byte) als UTF-16-Kodierung, in der Byte-Darstellung von Hex-Editoren (8 Byte) für die beiden unterschiedliche Byte-Reihenfolgen:

• Big Endian:

FE FF 00 44 00 69 00 65 | þÿ␣D␣i␣e 

• Little Endian:

FF FE 44 00 69 00 65 00 | ÿþD␣i␣e␣ 

Oder geht hier jetzt was verloren? --Aeroid (Diskussion) 08:13, 28. Okt. 2023 (CEST)

erledigtErledigt --Aeroid (Diskussion) 19:09, 1. Nov. 2023 (CET)