Diskussion:Base64

Diverses aus 2005

*Abschnittstitel nachträglich gesetzt. Inhalt stand "herrenlos" hier oben herum.* --Apraphul ^Disk 08:27, 19. Apr. 2016 (CEST)

...die nur aus wenigen Codepage-unabhängigen ASCII-Zeichen besteht...

Muss es nicht "abhängigen" heißen, sonst macht die ganze Sache doch keinen Sinn...? Ziel ist es doch, dass man mit jeder Codepage Base64 enkodierte Strings lesen kann.

Eben. Darum verwendet man ja nur Zeichen, die in jeder Codepage vorkommen, und so auf jedem Computer identisch sind, die also Codepage-unabhängig sind, weil ihre Darstellung nicht von der gewählten Codepage abhängt. --RokerHRO 16:41, 7. Feb 2005 (CET)

Da fehlt also eher ein Komma: "aus wenigen, Codepage-unabhaengigen ASCII-Zeichen". Ansonsten impliziert das, dass dort viele Codepage-abhaengige ASCII-Zeichen (oder damit eher nicht-ASCII-Zeichen) verwendet werden. (nicht signierter Beitrag von 64.208.111.34 (Diskussion) 09:01, 26. Jun. 2012 (CEST))

Der Text scheint inklusive Bild genau der gleiche zu sein wie dieser hier: http://www.at-mix.de/base_64.htm Ich habe gerade leider keine Zeit zu schauen, ob hier eine Uhrheberrechtsverletzung vorliegt. -- JGottschling

Das ist eindeutig keine Urheberrechtlichsverletzung. www.at-mix.de nutzt lokal eine Kopie der Wikipedia (Siehe Quellenangabe am Schluß der Seite) --Frubi 16:24, 23. Aug 2005 (CEST)

Umsetzungstabelle

Wie ist das zu verstehen, dass in der angegebenen Umsetzungstabelle kein = vorkommt? An anderer Stelle wird erwähnt, dass die leeren 6-Bit-Blöcke mit = gefüllt werden (Ascii-Code 61)? Laut der Umsetzungstabelle müsste der Decoder dann 9 anstelle von = ausgeben?

= ist in der Kodierungstabelle nicht enthalten, weil es nicht zur Kodierung von Datenbits verwendet wird. Es zeigt nur an, dass der letzte 3-Byte-Block unvollständig war, und wie viele (originale Daten-)Bytes in ihm fehlen. --RokerHRO 23:31, 19. Jun. 2007 (CEST)

unvollständig

Seit wann gibt es Base64?

Definiert wird es im RFC 1521, vom September 1993. Dort wird geschrieben, dass (fast) die gleiche Kodierung, nur noch nicht mit dem Namen "Base64" und auch für einen etwas anderen Zweck bereits im RFC 1421 vom Februar 1993 beschrieben wird. --RokerHRO 00:02, 5. Okt. 2008 (CEST)

In RFC 1341 vom Juni 1992 aber auch schon (Kapitel 5.2). --212.185.199.2 13:14, 4. Sep. 2015 (CEST)

Bereits in dem Kodierungsrezept in Kapitel 4.3 von RFC 989 (Februar 1987) wird unter Punkt 4 das Verfahren beschrieben. --2003:65:6018:668:0:0:0:C53D 18:16, 28. Sep. 2018 (CEST)

Beispiel ist kompliziert zu verstehen

Ich finde das Beispiel ist schwer zu verstehen bzw. nach zu vollziehen, da sich in dem Beispielstring Zeilenumbrüche befinden. Der Beispielsatz müsste nämlich so durch einen base64-Konverter gejagt werden, um den hier angegebenen Code zu erhalten:

 $ echo -en "Hätten Hüte ein ß im Namen, wären sie möglicherweise keine Hüte mehr,\r\nsondern Hüße.\r\n"|base64
 SMOkdHRlbiBIw7x0ZSBlaW4gw58gaW0gTmFtZW4sIHfDpHJlbiBzaWUgbcO2Z2xpY2hlcndlaXNl
 IGtlaW5lIEjDvHRlIG1laHIsDQpzb25kZXJuIEjDvMOfZS4NCg==

Man beachte die \r und \n. Ich plädiere dafür, einen Beispielsatz ohne Zeilenumbrüche zu verwenden (so wie in der englischen Version der Seite). --Black Monk Theme 12:43, 4. Jan. 2009 (CET)

Erledigt. So besser? --RokerHRO 23:45, 4. Jan. 2009 (CET)

Meiner Meinung nach ja. Danke. --Black Monk Theme 13:40, 5. Jan. 2009 (CET)

Wozu die Füllbytes

Interessant wäre es zu wissen, warum man eigentlich die Füllbytes anhängt. Es macht doch nichts, wenn sich die Anzahl der Quellbytes nicht durch drei teilen lässt. Man braucht die Bit-Länge des Quelltextes lediglich auf das nächste Vielfache von 6 Bits verlängern (bspw. mit Nullen auffüllen) und hat damit ein paar Bits Überhang. Die schneidet man beim Dekodieren wieder ab (was sich mittels einer einfachen Modulo 8 Division der Länge bewerkstelligen lässt). Man muss also keine Ganzen Bytes auffüllen und erspart sich auch die Schlusscodierung mit dem =-Zeichen. Ich weiß natürlich, dass das halt so im Standard definiert ist, aber interessant wäre es zu wissen: Warum hat man das im Standard so definiert? --ZerNot 18:59, 11. Mai 2011 (CEST)

Es ist beim Dekodieren einfacher, wenn man davon ausgehen kann, stets 4 Zeichen einlesen zu können, dann kann man einfach ein uint32_t am Stück einlesen und hat mit einem Rutsch 3 Oktette dekodiert. Die Länge des Datenstroms ist ja im Voraus nicht immer bekannt bzw. einfach ermittelbar, etwa wenn man aus einer Pipe oder Socket liest, was bei einer Kodierung, die für Netzwerkübertragungen gedacht war, nicht sooo unwahrscheinlich ist. --00:20, 12. Mai 2011 (CEST)

Abrunden vs Aufrunden

Ist es nicht viel einfacher "4 floor((x+2)/3)" durch "4 ceil(x/3)" zu ersetzen? -- 64.208.111.34 09:01, 26. Jun. 2012 (CEST)

Ansichtssache. Die Ganzzahldivision der meisten Programmiersprachen rundet (bei nichtnegativen Zahlen) ab, daher ist das floor() quasi implizit. --RokerHRO (Diskussion) 16:59, 26. Jun. 2012 (CEST)

Diskussion um Padding

1. Das RFC, das Base64 definiert, verlangt ein Padding. Es erlaubt aber, auf das Padding zu verzichten, wenn

• a) die Länge der zu kodierenden Daten auch auf andere Weise ermittelbar ist, oder
• b) wenn es in einer bestimmten Anwendung explizit ohne Padding definiert wird:

 3.2.  Padding of Encoded Data
 
 In some circumstances, the use of padding ("=") in base-encoded data
 is not required or used.

2. Das von Benutzer:Overmann als angebliches Gegenbeispiel angeführt Draft geht sogar explizit auf diesen Abschnitt im RFC ein und definiert eben für den Anwendungsfall, den das Draft definiert, eine entsprechende Ausnahme:

 Base64url Encoding
    Base64 encoding using the URL- and filename-safe character set
    defined in Section 5 of RFC 4648 [RFC4648], with all trailing '='
    characters omitted (as permitted by Section 3.2) and without the
    inclusion of any line breaks, white space, or other additional
    characters.

Auch der von mir wiederhergestellte Artikelstand enthält diese Aussgen bereits, da auf den Verzicht von Padding-Bytes bereits hingewiesen wird:

„Da sich die Anzahl der ursprünglichen Bytes immer eindeutig aus der Anzahl der Base64-Eingabe-Zeichen ermitteln lässt, wird in manchen Kontexten und Protokollen kein Padding verwendet (abweichend von der ursprünglichen Base64 Definition).“

Von mir aus können wir an diesen Satz im Artikel Verweise auf Protokolle/Datenformate hinzufügen, die aufgrund dieser Ausnahmeregelung auf ein Padding verzichten.

@Overmann:, @Apraphul: Wärd ihr mit der Lösung beide einverstanden? --RokerHRO (Diskussion) 10:56, 17. Apr. 2016 (CEST)

Ich bin einverstanden, selbstverständlich. Ich möchte nämlich einfach nur, dass da, wo wir im Artikel Base64/Base64url grundsätzlich beschreiben, die offiziellen Inhalte aus der RFC4648 stehen; und die definieren hier die Ausnahme bei Base64url so, dass dafür die Länge bekannt sein muss. Es ist ja auch nicht so, dass die RFC4648 nur irgendeine Macht-mal-was-ihr-wollt-Empfehlung ist, sondern ihr Status ist als "Standard" definiert (siehe bei RFC, was das bedeutet). Und damit kann eben nicht das Padding „einfach so entfallen“! Wenn es abweichende Umsetzungen gibt, wie das von Overmann zuletzt (als Referenz) eingefügte Internetformat "JSON Web Token (JWT)", so können die - falls relevant (!) - gerne in einen Abschnitt "Abweichende Umsetzungen" (oder ähnlich) beschrieben werden. Das kann dem Artikel nur gut tun, wenn in ihm auch ein wenig über den Tellerand geschaut wird. Jedoch ist eine solche Umsetzung keinesfalls als Referenz für das eigentliche Base64 zu sehen, sondern es ist lediglich eine von vielen Umsetzungen/Tools/Programmen, die mit Base64url zu tun haben bzw. es verwenden. VG --Apraphul ^Disk 12:04, 17. Apr. 2016 (CEST)

Bin auch einverstanden. Machen wir es so (Abweichende Umsetzungen). Ich bin einfach mit der ursprünglichen Base64 Definition nicht einverstanden (so wie scheinbar viele Andere auch, siehe abweichende Implementationen). Die Länge des kodierten Inhalts lässt sich _immer_ (unabhängig vom Kontext) aus der Anzahl der Base64 Zeichen ermitteln. Insofern sind diese ganzen Einschränkungen "wenn die Länge bekannt ist" in den RFCs Schall und Rauch. RFCs und Standard: Naja, die RFCs sind meisstens gute Dokumente, enthalten aber auch (wie jedes Dokument) Fehler und unnötigen Kram. RFC4648 hat es nur bis zum "Proposed Standard" geschafft. VG --Overmann (Diskussion) 00:53, 19. Apr. 2016 (CEST)

Ist etwas länger geworden - sorry. Ich verstehe ja, was Du meinst; und wahrscheinlich würden wir sogar dasselbe meinen, wenn Du von Deinen pauschalierten "Schall und Rauch"- und "Kann einfach so weggelassen werden"-Äußerungen ablassen würdest. ;-) Ich versuche, es zu erklären: Das mit dem Status "Proposed Standard" stimmt (ich hatte mich in der RFC5000 verguckt, sorry). Aber einen höheren Status für Base64 gibt es nicht (oder?) und irgendwodran muss man sich ja entlang hangeln. Irgendeine Beschreibung, wie und wonach sich gerichtet wird, muss jeder seinem Protokoll oder seinem Produkt ja mitgeben. Und irgendwodran muss sich auch unser Artikel richten. Wenn nicht nach dem aktuell höchststatuierten RFC, wonach dann ...? :-)

• Beispiel: Dein Computer ist kaputt und Du musst aber unbedingt einen Base64-String decodiert bekommen. Diesen hast Du als Textdatei auf einem USB-Stick und gibst ihn einem Kumpel, der ein "Base64-Programm" auf seinem Rechner hat. Der Kumpel liest Deine Textdatei ein und das Programm wirft einen Fehler "Corrupt Data!". Kumpel: "Das sind keine Base64-Daten." - Du: "Klar, sind's das." - Kumpel: "Nach welcher Norm?" - Du: "Wieso Norm, das ist doch alles Schall und Rauch." - Kumpel: "Bei meinem Programm steht beschrieben, es arbeitet nach RFC4648." - Du: "Schall und Rauch!"

In dem Beispiel hast Du vielleicht Pech, dass Deinen Base64-Daten ein Padding-Zeichen fehlt und das Programm des Kumpels prüft, ob die Anzahl der Bytes ein glattes Vielfaches von 4 ist. Oder vielleicht sind Deine Base64-Daten jeweils nach dem 50. Zeichen per Zeilenumbruch umgebrochen, was das Programm ebenfalls nicht erwartet. Natürlich hätte der Programmierer von Kumpels Programm so programmieren können, dass das Programm Zeilenumbrüche toleriert (also ignoriert) und auf den Zeichenanzahl-Check verzicht. Das ist ja nicht verboten. Er hätte dazu anschließend nur seine Beschreibung anpassen müssen: "Programm arbeitet nach RFC4648, ignoriert aber Zeilenumbrüche und fordert keine Paddingzeichen." Das hat der Programmierer aber nun einmal nicht getan. Sein Programm arbeitet nach RFC4648, Deine Daten sind nach RFC4648 mit Anpassungen/Ausnahmen (oder vielleicht auch nach einer ganz anderen Beschreibung/Norm) erstellt. Ich setze noch einen drauf: Vielleicht sind die Zeilenumbrüche auch erst beim Abspeichern auf den USB-Stick durch den verwendeten Texteditor hineingerutscht. Programm und Daten haben eindeutig beide mit Base64 zu tun, sind aber inkompatibel zueinander. Es ist also eindeutig nicht egal, ob und welcher/m Beschreibung/Norm/RFC/Protokoll man folgt oder nicht folgt. Und das muss auch im Artikel deutlich werden. Dann können sämtliche andere Normen und Protokolle gerne erwähnt werden. So gibt es ja z.B. auch Protokolle, die Base64 verwenden, als es RFC4648 noch gar nicht gab. RFC4648 nimmt genau darauf ja auch Rücksicht und erwähnt solche Ausnahmen (z.B. MIME --> Zeilenumbruch nach 76 Zeichen). Ebenso "erlaubt" RFC4648 Ausnahmen - z.B. beim Padding und Zeilenumbruch -, solange nur die Ausnahmen auch deutlich in der betreffenden Umsetzung beschrieben stehen. Wenn wir das alles peu à peu in den Artikel einfließen lassen können, wäre es klasse, denke ich. VG --Apraphul ^Disk 08:09, 19. Apr. 2016 (CEST)

Ich möchte nur kurz zu bedenken geben, das Wikipedia ein Lexikon ist, ein Nachschlagewerk, das Begriffe in allen möglichen Bedeutungen erklärt. Insbesondere muss Wikipedia sich nicht auf formale (und evtl. fehlerhafte) Standards beschränken, sondern darf und sollte Begriffe in all ihren Facetten beleuchten. Schau dir mal die Seiten zu TCP oder zu C++ an. Da stehen viele Sachen drin, die im 'aktuellen' Standard gar nicht drin stehen. Das ist wie mit der deutschen Sprache: Die ist ja auch nicht darüber definiert, was im Duden steht, sonder darüber, wie im Moment in Deutschland meistens gesprochen wird. Im RFC von Base64 steht zum Beispiel an einer Stelle drin, dass das Padding benötigt wird, um die ursprüngliche Länge der Daten zu ermitteln. Das ist sachlich falsch, Standard oder nicht. Und das muss Wikipedia deshalb auch gar nicht genau so, wie im Standard wieder geben. Overmann (Diskussion) 23:31, 26. Apr. 2016 (CEST)

Prozentcodiert - URLEncoding

"Prozentcodierung" ist nicht Teil von Base64Url.
Diese Codierung entsteht durch URLEncoding das generell auf Url Query Parameter angewandt wird, egal ob es sich dabei um Base64Url oder normalen Text handelt.
Auf das UrlEncodig hinzuweisen ist nicht falsch, aber in der derzeitigen Formulierung entsteht der Eindruck die "Prozentcodierung" wäre Teil von Base64Url. (nicht signierter Beitrag von 194.96.160.88 (Diskussion) 15:25, 1. September 2017)

Sollte tatsächlich ein falscher Eindruck entstehen, so wäre das natürlich nicht gut. Ausdrücken sollte der kleine Absatz, auf den Du Dich beziehst, den Inhalt der dort auch angegebenen Referenz. Welche Formulierung schlägst Du vor, die die Quelle/Referenz korrekt abbildet und zu keinen falschen Eindrücken führt? VG --Apraphul ^Disk _WP:SNZ 16:02, 1. Sep. 2017 (CEST)

"Bildmengen"

@SweetWood, zu Deinen Änderungen bzgl. der Bildmengen-Erwähnungen: Bei Base64 wird aus dem Ursprungstext (bestehend aus Zeichen aus der Definitionsmenge namens ASCII-Zeichensatz) per Kodierung ein Base64-Text (bestehend aus Zeichen der Zielmenge). Diese Zielmenge (nicht Bildmenge) ist im Artikel mit dem folgenden Satz beschrieben: „Zur Kodierung werden die Zeichen A–Z, a–z, 0–9, + und / verwendet sowie = am Ende.“ Eine Bildmenge wäre ein Teil der Zielmenge, gewonnen aus einer Funktion (nettes Video dazu). Da aber (a) die Base64-Kodierung keine Funktion darstellt, wo jedes Element der Definitionsmenge (ASCII-Zeichen) auf genau ein Zeichen der Zielmenge trifft, und (b) auch nicht jedes Element der Definitionsmenge im Laufe der Kodierung eines aus ihr gebildeten Textes auf immer dieselben Elemente der Zielmenge trifft, kann man meines Erachtens die Begriffe "Bildmenge" und "Urbildmenge" überhaupt nicht im Artikel sinnvoll verwenden. Gruß --Apraphul ^Disk _WP:SNZ 11:24, 6. Dez. 2017 (CET)

base64-url

<Sven_vB> hi! mein Proxy darf nicht bearbeiten, daher: könnte jemand bei Base64 wahlweise in der Zeichentabelle noch die base64-url Varianten hinzufügen (+ -> -, / -> _) und/oder im Absatz darunter die Eselsbrücke notieren, dass +/- getauscht werden weil sie als mathematische Vorzeichen zusammengehören? ... <Sven_vB> bis ich wieder WP-konform bin wird meine Motivation weg sein :) <Sven_vB> ich hab eh ein Tool für Anmerkungen auf fremden Websites, mein eigener Bedarf den Artikel zu verbessern ist also gering. <Sven_vB> bin dann mal wieder weg, viel Spaß noch euch! --paddy • ふ 17:28, 17. Sep. 2019 (CEST)

Die Base64-Url-Variante ist im Artikel bereits erwähnt. Gruß --Apraphul ^Disk _WP:SNZ 20:50, 17. Sep. 2019 (CEST)

Binärcode vs. Strings

Wieso werden im Artikel Strings als Beispiel verwendet, wenn es um ein Verfahren zur Kodierung von Binärdaten geht? Das ist im Zusammenhang mit der Angabe "Durch die Kodierung steigt der Platzbedarf des Datenstroms um 33–36 %" nicht schlüssig. Wenn ich Unicode (2 Byte pro Umlaut, ß etc.) mit Base64 codiere, kann das Ergebnis durchaus 3x so lang sein wie der ursprüngliche String --2A02:908:677:6A80:EBCF:64B2:512D:D202 15:39, 25. Jul. 2021 (CEST)

Im Artikel wird ja nicht das Verhältnis von Text(zeichen)längen zueinander beschrieben und mit einem Zuwachs von 33% beziffert, sondern das des Datenstroms (gemeint ist eher der Strom der Bits). Dass nun für den Eingansdatenstrom im Beispiel ein String (also ein Text) gewählt wurde, dient lediglich der praktischen Veranschaulichung eines Eingangsdatenstroms und ändert nichts an der Vermehrung der darin enthaltenen Bits um ein Drittel, sobald sie am Ausgang Base64-kodiert (mit 8 Bit pro Zeichen) dargestellt werden. Das Beispiel ist eben nur ein Beispiel und auch die darin für den Eingangstext gewählte Codierung UTF-8 nicht zwingend. Wäre der Eingangstext per Defintion nicht in UTF-8, sondern in Codepage-850 codiert, wären es nicht 68 Bytes, sondern 64 Bytes, die dann Base64-kodiert als Ausgangszeichenkette 88 Zeichen lang wären. Das könnte im Artikel noch entsprechend, leicht umformuliert werden, was ich gleich tun werde.

Zugegeben: Vielleicht sollte man anstelle von Datenstrom lieber von Bitstrom sprechen, womit eine mögliche, hier aber nicht gewollte Interpretation des Datenstroms als Textzeichenstrom ausgeschlossen wäre.

Der umseitige Beispielabschnitt hat übrigens - wie ich gerade sehe - einen Gedankenfehler bzgl. des Datenstroms, den ich selbst vor über 5 Jahren eingebaut habe (*grummel*). Das korrigiere ich gleich sofort.

Gruß --Apraphul ^Disk _WP:SNZ 23:09, 26. Jul. 2021 (CEST)

Spätere Streichung oben: Nein, wäre auch nicht gut. Die 33% Zuwachs sind, wie bereits beschrieben, nicht der Unterschied zwischen ein- und ausgegebenen Zeichen, aber auch nicht zwingend der Unterschied zwischen ein- und ausgegebenen Bits, sondern die 33% Zuwachs sind immer der Unterschied zwischen eingegebenen Bytes und ausgegebenen Zeichen (3 Bytes werden Base64-kodiert zu 4 Zeichen). Ein Byte hat immer 8 Bit, aber die Bitzahl eines Zeichens hängt immer von der Kodierung ab (auch am Ausgang). Gruß --Apraphul ^Disk _WP:SNZ 23:45, 26. Jul. 2021 (CEST)

Padding falsch erklärt

Im Artikel steht z.Z., dass an den Eingabe-Bytestrom so viele Nullbytes angehängt werden, bis die Anzahl der Bytes durch 3 teilbar ist. Dem ist aber nicht so - es werden nur so viele Nullbits angefügt, bis die Zahl der zu codierenden Bits durch 6 teilbar ist. Den Unterschied erkennt man leicht an einem Beispiel:

Base64 wie (falsch) erklärt

zu codierende Bytes (Hex)	aufgefüllt auf durch 3 teilbare Bytezahl (Hex)	Base64 (ohne Ausgabe-Padding)	Base64 (mit Ausgabe-Padding)
00	00 00 00	AAAA	AAAA==
00 00	00 00 00	AAAA	AAAA=
00 00 00	00 00 00	AAAA	AAAA
FF	FF FF FF	////	////==
FF FF	FF FF FF	////	////=
FF FF FF	FF FF FF	////	////

Man sieht, dass das Ausgabe-Padding hier zwingend notwendig ist, um korrekt decodieren zu können.

In Wirklichkeit funktioniert das Padding aber folgendermaßen (wie schon erwähnt wird mit Null-Bits auf eine durch 6 teilbare Bit-Zahl aufgefüllt):

korrektes Base64

zu codierende Bytes (Hex)	Anzahl Bits	aufgefüllt auf durch 6 teilbare Bitzahl (Binärdarstellung, Schrägstrich trennt Padding-Bits)	Base64 (ohne Ausgabe-Padding)	Base64 (mit Ausgabe-Padding)
00	8	000000 00/0000	AA	AA==
00 00	16	000000 000000 0000/00	AAA	AAA=
00 00 00	24	000000 000000 000000 000000	AAAA	AAAA
FF	8	111111 11/0000	/w	/w==
FF FF	16	111111 111111 1111/00	//8	//8=
FF FF FF	24	111111 111111 111111 111111	////	////

--19:44, 19. Aug. 2022 (CEST) --80.151.251.9 19:44, 19. Aug. 2022 (CEST)

Gut beobachtet, danke. Ist nun korrigiert. --Matthäus Wander 22:04, 5. Mär. 2023 (CET)

umbrechen

Ich will nicht rechthaberisch klingen, aber es heißt "wird umbrochen" statt "wird umgebrochen".

Keine Ahnung, warum meine Änderung rückgängig gemacht wurde.

<https://de.wiktionary.org/wiki/umbrechen#Verb,_untrennbar>

Marcel Logen, 31.08.2024 --87.160.240.248 15:38, 31. Aug. 2024 (CEST)

Das ist mir gestern auch so passiert. Für @RokerHRO:

Das Verb „umbrechen“ hat zwei Bedeutungen mit unterschiedlichen Flexionen. Hier ist das untrennbare „umbrechen“ im Sinne von „Zeilen auf die richtige Länge bringen“ gemeint, das Partizip lautet hier „umbrochen“. Siehe https://de.wiktionary.org/wiki/umbrechen#Verb,_untrennbar , wo beide Bedeutungen stehen. --Daniel Moor (Diskussion) 09:46, 1. Dez. 2024 (CET)