Diskussion:Base64

message: *Abschnittstitel nachträglich gesetzt. Inhalt stand "herrenlos" hier oben herum.* --Apraphul   Disk  08:27, 19. Apr. 2016 (CEST)
replies: text: 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)
replies: text:  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)

text: 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)
thread_title:  Diverses aus 2005 

message: 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)
thread_title:  Umsetzungstabelle 

message: 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)
replies: text: In RFC 1341 vom Juni 1992 aber auch schon (Kapitel 5.2). --212.185.199.2 13:14, 4. Sep. 2015 (CEST)
replies: text: 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)
thread_title:  unvollständig 

message: 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)
replies: text: Erledigt. So besser? --RokerHRO 23:45, 4. Jan. 2009 (CET)
replies: text: Meiner Meinung nach ja. Danke. --Black Monk Theme 13:40, 5. Jan. 2009 (CET)
thread_title:  Beispiel ist kompliziert zu verstehen 

message: 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)
replies: text: 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)
thread_title:  Wozu die Füllbytes 

message: 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)
replies: text: 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)
thread_title:  Abrunden vs Aufrunden 

message: "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. 
: 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)
thread_title:  Prozentcodiert - URLEncoding 

message: @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)
thread_title:  "Bildmengen" 

message: <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)
replies: text: Die Base64-Url-Variante ist im Artikel bereits erwähnt. Gruß --Apraphul   Disk   WP:SNZ 20:50, 17. Sep. 2019 (CEST)
thread_title:  base64-url 

message: 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)
replies: text: Gut beobachtet, danke. Ist nun korrigiert. --Matthäus Wander 22:04, 5. Mär. 2023 (CET)
thread_title:  Padding falsch erklärt