base_64 ist gleich

[JensW]

Hi,

Bei der Umwandlung von Strings mit base64() entstehen manchmal Gleichheitszeichen am Ende. Mal eines mal zwei, mal keines.

Bei der Decodierung benötige ich diese Gleichheitszeichen nicht, es funktioniert auch ohne.

Warum werden die dann erzeugt?

Und warum so anscheinend willkürlich?

selfhtml    = c2VmaHRtbA==
selfhtmlx   = c2VmaHRtbHg=
selfhtmlxy  = c2VmaHRtbHh5

Mir geht es darum b64-Strings zu erzeugen die wirklich nur aus [a-Z] [0-9] bestehen, dann müsste ich doch lediglich diese seltsamen istgleich rausschneiden, oder kann das dann zu einem Problem irgendwann werden?

Jens

[Cheatah]

Hi,

Warum werden die dann erzeugt?

http://de.wikipedia.org/wiki/Base64, fünfter Absatz.

Cheatah

[JensW]

Hi,

http://de.wikipedia.org/wiki/Base64, fünfter Absatz.

Falls die Gesamtanzahl der Eingabebytes nicht durch drei teilbar ist, wird der zu kodierende Text am Ende mit aus Nullbits bestehenden Füllbytes aufgefüllt, so dass sich eine durch drei teilbare Anzahl an Bytes ergibt. Um dem Dekodierer mitzuteilen, wie viele Füllbytes angefügt wurden, werden die 6-Bit-Blöcke, die vollständig aus Füllbytes entstanden sind, mit = kodiert. Somit können am Ende einer Base64-kodierten Datei null, ein oder zwei =-Zeichen auftreten. Anders gesagt (denn dies ist äquivalent), es werden so viele =-Zeichen angehängt, wie Füllbytes angefügt worden sind.

Ok, das hilft schon weiter aber einige Fragen bleiben.

Warum sind diese Füllzeichen notwenig, oder sind sie es überhaupt?

Kann ich sie bedenkenlos ausschneiden?

Die Tabelle bei Wikipedia, was bedeutet sie?
Denn mit base64 kann ich ja so ziemlich alles codieren, nicht nur die 64 Zeichen.

Wert Zeichen  Wert Zeichen  Wert Zeichen  Wert Zeichen
0 A 16 Q 32 g 48 w
1 B 17 R 33 h 49 x
2 C 18 S 34 i 50 y
3 D 19 T 35 j 51 z
4 E 20 U 36 k 52 0
5 F 21 V 37 l 53 1
6 G 22 W 38 m 54 2
7 H 23 X 39 n 55 3
8 I 24 Y 40 o 56 4
9 J 25 Z 41 p 57 5
10 K 26 a 42 q 58 6
11 L 27 b 43 r 59 7
12 M 28 c 44 s 60 8
13 N 29 d 45 t 61 9
14 O 30 e 46 u 62 +
15 P 31 f 47 v 63 /

Jens

[Der Martin]

Hallo,

Falls die Gesamtanzahl der Eingabebytes nicht durch drei teilbar ist, [...] es werden so viele =-Zeichen angehängt, wie Füllbytes angefügt worden sind.
Warum sind diese Füllzeichen notwenig, oder sind sie es überhaupt?

du hast den Abschnitt also nur zitiert, ohne ihn zu verstehen?

Der Basis-Algorithmus wandelt immer je 3 Bytes der Originaldaten in 4 Zeichen des base64-Strings (Folge: Die Länge des base64-Strings ist immer ein Vielfaches von 4). Ist die Byteanzahl nicht durch 3 teilbar, kann dieser Musteralgorithmus nicht funktionieren; deshalb wird die Länge auf einen durch 3 teilbaren Wert aufgefüllt. Damit der Decoder "weiß", wieviele Bytes er beim Rückgewinnen der Originaldaten wegwerfen darf, wertet er die Anzahl der '=' am Ende des base64-Strings aus.
Natürlich kann man den Decoder auch so implementieren, dass er diese Information direkt aus der Länge des base64-Strings ableitet.

Kann ich sie bedenkenlos ausschneiden?

Kommt drauf an. Wenn jeder base64-Decoder damit klarkommen soll, nein.

Die Tabelle bei Wikipedia, was bedeutet sie?

Du hast den Wiki-Artikel also nicht nur nicht verstanden, sondern auch nicht aufmerksam gelesen. Denn die Bedeutung dieser Tabelle wird direkt oberhalb davon ausführlich erklärt.

Ciao,
 Martin

[JensW]

Warum sind diese Füllzeichen notwenig, oder sind sie es überhaupt?

du hast den Abschnitt also nur zitiert, ohne ihn zu verstehen?

Sonst würde ich kaum fragen.
Aus dem Abschnitt geht nicht hervor ob es zwingend notwendig ist.

Kann ich sie bedenkenlos ausschneiden?

Kommt drauf an. Wenn jeder base64-Decoder damit klarkommen soll, nein.

Mir geht es dabei nur um JS und PHP. Kommen die damit "IMMER" klar, wenn ich die Füllzeichen weglasse?

Die Tabelle bei Wikipedia, was bedeutet sie?

Du hast den Wiki-Artikel also nicht nur nicht verstanden, sondern auch nicht aufmerksam gelesen. Denn die Bedeutung dieser Tabelle wird direkt oberhalb davon ausführlich erklärt.

Das hier so viele immer denken, nur weil sie es verstehen haben andere es auch zu verstehen. Nein, der Artikel bei Wikipedia ist auf fachchinesisch geschrieben. Also habe ich Ihn "aufmerksam" gelesen jedoch nicht verstanden.

Jens

[dedlfix]

echo $begrüßung;

Du hast den Wiki-Artikel also nicht nur nicht verstanden, sondern auch nicht aufmerksam gelesen. Denn die Bedeutung dieser Tabelle wird direkt oberhalb davon ausführlich erklärt.
Das hier so viele immer denken, nur weil sie es verstehen haben andere es auch zu verstehen.

Ob es "viele" denken oder nicht, sei mal dahingestellt. Es ist aber aus einer nicht vorhandenen Aussage nicht zu entnehmen, ob jemand etwas nicht verstanden oder nicht gelesen hast. Also mach bitte nicht deine Leser allein dafür verantwortlich, wenn sie diese Abwesenheit missdeuten.

Nein, der Artikel bei Wikipedia ist auf fachchinesisch geschrieben. Also habe ich Ihn "aufmerksam" gelesen jedoch nicht verstanden.

Damit kann man schon ein wenig mehr anfangen. Wenn du weitere Verständnislücken hast, wäre es gut, wenn du diese spezifizieren könntest, denn einen kompletten Aufsatz zur Funktionsweise von base64 wird dir hier vermutlich niemand liefern.

Mir geht es dabei nur um JS und PHP. Kommen die damit "IMMER" klar, wenn ich die Füllzeichen weglasse?

Das könntest du zum einen mit einer kleinen Testreihe probieren. Zum anderen kann man das zumindest im Falle PHP in dessen Quelltext zu ergründen versuchen. Für Javascript wird dir nur der erste Weg übrigbleiben, denn das ist je nach Browser anders implementiert und nicht in jedem Fall quelloffen.

Warum sind diese Füllzeichen notwenig, oder sind sie es überhaupt?
Aus dem Abschnitt geht nicht hervor ob es zwingend notwendig ist.

Welchen Nutzen hat die Beantwortung dieser Frage? Die Füllzeichen sind spezifiziert, jeder Empfänger wird damit korrekt umgehen müssen, manche werden bei Fehlern tolerant sein, manche nicht, und es ist nicht allzu schwer, sie in passender Menge hinzuzufügen. Was versprichst du dir von deren Weglassen?

echo "$verabschiedung $name";

[JensW]

Hi,

Ob es "viele" denken oder nicht, sei mal dahingestellt. Es ist aber aus einer nicht vorhandenen Aussage nicht zu entnehmen, ob jemand etwas nicht verstanden oder nicht gelesen hast. Also mach bitte nicht deine Leser allein dafür verantwortlich, wenn sie diese Abwesenheit missdeuten.

na ja der logische Aspekt wäre ja wohl, wenn ich es gelesen habe(wovan man ausgehen sollte) und dennoch nachfrage, das ich es wohl nicht verstehe. Zumindest ineterpretiere ich das so wenn ich hier auf postings antoworte.

Damit kann man schon ein wenig mehr anfangen. Wenn du weitere Verständnislücken hast, wäre es gut, wenn du diese spezifizieren könntest, denn einen kompletten Aufsatz zur Funktionsweise von base64 wird dir hier vermutlich niemand liefern.

Das will ich auch gar nicht, lediglich das Verständnisproblem der tabelle klären.

Das könntest du zum einen mit einer kleinen Testreihe probieren. Zum anderen kann man das zumindest im Falle PHP in dessen Quelltext zu ergründen versuchen. Für Javascript wird dir nur der erste Weg übrigbleiben, denn das ist je nach Browser anders implementiert und nicht in jedem Fall quelloffen.

Stimmt, Faktum Browser könnte einmal ein Problem werden.
Aber PHP-Sourcecode zu analysieren, dürfte wohl die meissten hier überfordern und wäre auch sinnlos, denn das es mit allen mir bekannten Versionen ohne Füllzeichen funktioniert sagte ich ja bereits. Wichtiger wäre zu wissen, ob darauf Verlass ist in zukünftigen Versionen.

Welchen Nutzen hat die Beantwortung dieser Frage? Die Füllzeichen sind spezifiziert, jeder Empfänger wird damit korrekt umgehen müssen, manche werden bei Fehlern tolerant sein, manche nicht, und es ist nicht allzu schwer, sie in passender Menge hinzuzufügen. Was versprichst du dir von deren Weglassen?

Im aktuellen Fall geht es mir um Dateinamen und ich sehe es ungern wenn in einem Dateinamen andere Zeichen als Buchstaben/Zahlen vorhanden sind. Da geht es mir in erster Linie um Kompatibilität mit anderen Systemen/Geräten.

Ich hatte aber auch schon Fälle wo ich b64 sowohl clientseitig als auch serverseitig habe produzieren lasse, und dabei gemerkt, dass das Setzen dieser Füllzeichen nicht unbedingt bei beiden gleich zutreffend ist.

So ist für mich der sinnvollere Weg gleichermassen bei beiden diese direkt zu entfernen.

Grus
Jens

[Cheatah]

Hi,

na ja der logische Aspekt wäre ja wohl, wenn ich es gelesen habe(wovan man ausgehen sollte) und dennoch nachfrage, das ich es wohl nicht verstehe.

diese Logik wurde schon oft genug von der Realität überrollt. Deine Postings enthielten jedenfalls äußerst wenige Indizien, die auf den entsprechenden Umstand hindeuteten.

Das will ich auch gar nicht, lediglich das Verständnisproblem der tabelle klären.

Welches denn? Wenn Du ein Problem hast, musst Du es beschreiben, sonst kann Dir keiner helfen.

Wichtiger wäre zu wissen, ob darauf Verlass ist in zukünftigen Versionen.

Undokumentiertes Verhalten ist unverlässlich, die Verlässlichkeit dokumentierten Verhaltens lässt sich aus der Dokumentation schließen. Ist das Verhalten also dokumentiert?

Im aktuellen Fall geht es mir um Dateinamen und ich sehe es ungern wenn in einem Dateinamen andere Zeichen als Buchstaben/Zahlen vorhanden sind. Da geht es mir in erster Linie um Kompatibilität mit anderen Systemen/Geräten.

Dann kodiere die Werte - das ist eh immer und grundsätzlich das mit riesengroßem Abstand eindeutig und unzweifelhaft beste Vorgehen. Dann bekommst Du auch keine Probleme mit "+" und "/", die wahrscheinlich sogar kritischer sind als die Gleichheitszeichen.

Ich hatte aber auch schon Fälle wo ich b64 sowohl clientseitig als auch serverseitig habe produzieren lasse, und dabei gemerkt, dass das Setzen dieser Füllzeichen nicht unbedingt bei beiden gleich zutreffend ist.

Beispiel?

So ist für mich der sinnvollere Weg gleichermassen bei beiden diese direkt zu entfernen.

Nope. Das wäre allenfalls ein Workaround.

Cheatah

[JensW]

Hi,

Das will ich auch gar nicht, lediglich das Verständnisproblem der tabelle klären.

Welches denn? Wenn Du ein Problem hast, musst Du es beschreiben, sonst kann Dir keiner helfen.

Das hatte ich bereits geschrieben. Was hat eine Tabelle mit 64 Zeichen damit zu tun, wenn base64 nahezu alle zeichen umwandeln kann?

Wichtiger wäre zu wissen, ob darauf Verlass ist in zukünftigen Versionen.

Undokumentiertes Verhalten ist unverlässlich, die Verlässlichkeit dokumentierten Verhaltens lässt sich aus der Dokumentation schließen. Ist das Verhalten also dokumentiert?

»»

Womit wir eigentlich zur Ausgangsfrage kommen, ist dieses Verhalten dokumentiert? Zumindest in der Weise, das irgendwo zu lesen wäre
"Es ist nicht zwingend erforderlich die Füllzeichen zu nutzen"

Dann kodiere die Werte - das ist eh immer und grundsätzlich das mit riesengroßem Abstand eindeutig und unzweifelhaft beste Vorgehen. Dann bekommst Du auch keine Probleme mit "+" und "/", die wahrscheinlich sogar kritischer sind als die Gleichheitszeichen.

Warum sollte ich Probleme mit + oder / bekommen? Beispiel?

Ich hatte aber auch schon Fälle wo ich b64 sowohl clientseitig als auch serverseitig habe produzieren lasse, und dabei gemerkt, dass das Setzen dieser Füllzeichen nicht unbedingt bei beiden gleich zutreffend ist.

Beispiel?

Etliche:

http://ostermiller.org/calc/encode.html

http://aktuell.de.selfhtml.org/artikel/javascript/utf8b64/end.htm#a2

http://www.patshaping.de/projekte/kleinkram/base64.php

Mit meinen Anfangs erwähnten Beispielstrings ergeben sich da schon Unterschiede.

So ist für mich der sinnvollere Weg gleichermassen bei beiden diese direkt zu entfernen.

Nope. Das wäre allenfalls ein Workaround.

Wenn rauszufinden wäre ob dieser Workaround mal daneben gehen könnte würde mir das schon reichen.

Jens

[Vinzenz Mai]

Hallo,

Welches denn? Wenn Du ein Problem hast, musst Du es beschreiben, sonst kann Dir keiner helfen.

Das hatte ich bereits geschrieben. Was hat eine Tabelle mit 64 Zeichen damit zu tun, wenn base64 nahezu alle zeichen umwandeln kann?

nicht nahezu alle. Alle.

Du nimmst drei aufeinanderfolgende Bytes, genauer 24 Bit, Deiner Ausgangsdaten. Diese 24 Bit teilst Du in 4 Einheiten à 6 Bit auf - genau wie in Wikipedia grafisch dargestellt.

Jede dieser Einheiten von 6 Bit wird mit *einem* 8-Bit-Zeichen kodiert. Mit 6 Bit kannst Du genau 2^6 = 64 verschiedene Werte darstellen, deswegen benötigt man nur 64 verschiedene Zeichen, um *alle beliebigen* Zeichen darstellen zu können. Dafür benötigt man halt ein Drittel mehr Platz.

An welchem Punkt kommst Du nicht mehr mit?

Freundliche Grüße

Vinzenz

[JensW]

Hi,

Das hatte ich bereits geschrieben. Was hat eine Tabelle mit 64 Zeichen damit zu tun, wenn base64 nahezu alle zeichen umwandeln kann?

nicht nahezu alle. Alle.

aha, gut zu wissen das zumindest darauf Verlass ist, hatte mich immer schon gefragt ob es mal ein Zeichen geben könnte, das Probleme bereitet.

Jede dieser Einheiten von 6 Bit wird mit *einem* 8-Bit-Zeichen kodiert. Mit 6 Bit kannst Du genau 2^6 = 64 verschiedene Werte darstellen, deswegen benötigt man nur 64 verschiedene Zeichen, um *alle beliebigen* Zeichen darstellen zu können. Dafür benötigt man halt ein Drittel mehr Platz.

An welchem Punkt kommst Du nicht mehr mit?

Jetzt komme ich wieder mit also ist es umgekehrt die Tabelle zeigt lediglich welche Zeichen bei der Kodierung genutzt werden dürfen.

Das erklärt dann auch Cheatahs Einwand in Bezug auf + und / , denn mir war noch nie eine codierter String mit diesen beiden Zeichen aufgefallen. Aber anscheinend kann das passieren und diese Tatsache macht mir jetzt echt Probleme. Denn nun muss ich wirklich eine eigene Codierung nutzen um dowas als Dateinamen zu gebrauchen. Ist zwar kein Ding aber hat den Riesennachteil, dass ich diese Codierungsfunktion immer mit implementieren muss.

Danke
Jens

[Der Martin]

n'Abend,

Wenn Du ein Problem hast, musst Du es beschreiben, sonst kann Dir keiner helfen.
Das hatte ich bereits geschrieben. Was hat eine Tabelle mit 64 Zeichen damit zu tun, wenn base64 nahezu alle zeichen umwandeln kann?

ich vermute, du stehst etwas auf dem Schlauch. Also:
Bei der base64-Codierung wird die Eingabe in 3-Byte-Blöcken gelesen. 3 Byte sind 24bit. Diese 24bit werden nun nicht in 3 Blöcke zu je 8bit gruppiert, sondern in 4 Blöcke à 6bit, wie es im Wiki-Artikel sogar graphisch dargestellt wird. Für jeden dieser 6bit-Blöcke (für sich genommen also ein Zahlenwert von 0..63) wird nun ein Zeichen aus der Codiertabelle geschrieben.
Diese Tabelle enthält also nicht die Zeichen, die in base64 codiert werden können, sondern die Zeichen, die in einem base64-codierten String auftreten können.

Ich finde nicht, dass die Beschreibung bei Wikipedia Fachchinesisch ist. Ich habe mir den Artikel nochmal durchgelesen und bin der Ansicht, dass wirklich nur ein rudimentäres Vorstellungsvermögen vorausgesetzt wird, wie gespeicherte Zahlen und Daten interpretiert werden können.

Undokumentiertes Verhalten ist unverlässlich, die Verlässlichkeit dokumentierten Verhaltens lässt sich aus der Dokumentation schließen. Ist das Verhalten also dokumentiert?
Womit wir eigentlich zur Ausgangsfrage kommen, ist dieses Verhalten dokumentiert? Zumindest in der Weise, das irgendwo zu lesen wäre
"Es ist nicht zwingend erforderlich die Füllzeichen zu nutzen"

Nein. Genau das ist *nicht* dokumentiert. Der Musteralgorithmus verwendet die Füllzeichen. Wenn eine konkrete Implementierung so tolerant ist, auch ohne die Füllzeichen korrekt zu arbeiten, ist das "zufällig" so. Darauf kannst du dich aber nicht verlassen - weder für andere Plattformen, noch für zukünftige Versionen bestehender Software.

Warum sollte ich Probleme mit + oder / bekommen? Beispiel?

Du hast geschrieben, dass du die base64-Strings in Dateinamen verwenden willst. Alle mir bekannten Dateisysteme verbieten aber den Schrägstrich '/' in Dateinamen, da er als Delimiter für Verzeichnisse reserviert ist. Und es gibnt Dateisysteme, in denen auch das '+' ein verbotenes Zeichen ist (frühe DOS-Versionen gehörten dazu).

Deswegen wäre in deinem Fall eher die im letzten Absatz verlinkte und in RFC 3548 beschriebene Variante passend, bei der anstatt '+' und '/' die Zeichen '-' und '_' verwendet werden.

Ciao,
 Martin

[JensW]

Hi,

Diese Tabelle enthält also nicht die Zeichen, die in base64 codiert werden können, sondern die Zeichen, die in einem base64-codierten String auftreten können.

ok danke, Vincent hat mich auch schon drauf gebracht.

Warum sollte ich Probleme mit + oder / bekommen? Beispiel?

Deswegen wäre in deinem Fall eher die im letzten Absatz verlinkte und in RFC 3548 beschriebene Variante passend, bei der anstatt '+' und '/' die Zeichen '-' und '_' verwendet werden.

Ja das hatte mich verwirrt, weil ich noch nie bewusst diese Zeichen in einem base64-String gesehen hatte.

Das mit RFC 3458 fällt dann wieder in meine Kategorie Fachchinesisch.
Ich habe zwar verstandenm das der Unterschied lediglich(und damit höchstwichtig) die Ersetzung durch _ und - sind, aber wie erreiche ich das mit PHP und auch mit JS ohne eine eigene Konvertierungfunktion?

Gruss
Jens

[ChrisB]

Hi,

Das mit RFC 3458 fällt dann wieder in meine Kategorie Fachchinesisch.
Ich habe zwar verstandenm das der Unterschied lediglich(und damit höchstwichtig) die Ersetzung durch _ und - sind, aber wie erreiche ich das mit PHP und auch mit JS ohne eine eigene Konvertierungfunktion?

In dem du die normale Base64-Kodierung durchfuehrst, und anschliessend + und / ersetzt.
Fuer PHP hat's im Manual in den Nutzerkommentaren schon Beispiele, und fuer JavaScript ist das auch schnell selbst gebastelt.

MfG ChrisB

[Vinzenz Mai]

Hallo,

Das mit RFC 3458 fällt dann wieder in meine Kategorie Fachchinesisch.

wieso? Es ist lediglich ein Hinweis darauf, wo etwas dokumentiert ist. Klar, RFCs sind meist recht trocken, aber nicht immer, siehe RFC 2324.

Ich habe zwar verstandenm das der Unterschied lediglich(und damit höchstwichtig) die Ersetzung durch _ und - sind, aber wie erreiche ich das mit PHP und auch mit JS ohne eine eigene Konvertierungfunktion?

in PHP: mit str_replace(). Diese Funktion nimmt netterweise auch Arrays entgegen. Ein einziger Aufruf genügt also. In Javascript kriegst Du das jetzt selbst hin ...

Freundliche Grüße

Vinzenz

[JensW]

Hi,

Das mit RFC 3458 fällt dann wieder in meine Kategorie Fachchinesisch.

wieso? Es ist lediglich ein Hinweis darauf, wo etwas dokumentiert ist. Klar, RFCs sind meist recht trocken, aber nicht immer, siehe RFC 2324.

»»
Nicht nur trocken. Dein Link setzt schon mal voraus, dass ich fachenglisch ausreichend verstehe.(Ok, mit dem Englisch käm ich noch klar mit dem Text nicht mal in Deutsch). Aber warum sollte mich das auch interessieren, es sei denn es gibt eine Funktion in php, wie "string base64_encode(STRING[,RFC2324])". Ansonsten könnte ich ja gleich base64 nehmen und dann Replace-Funktionen.

in PHP: mit str_replace(). Diese Funktion nimmt netterweise auch Arrays entgegen. Ein einziger Aufruf genügt also. In Javascript kriegst Du das jetzt selbst hin ...

Klar das ist einfach zu machen, aber es wäre keine hauseigene Funktion, sondern eine die ich jedem Script das es nutzt implementieren muss.

Also werde ich jetzt mal weiter suchen ob es nicht sowas gibt, was ich benötige. Im Moment bin ich auf convert_uuencode() gestossen, mal sehen was das kann?

Jens

[Cheatah]

Hi,

Klar das ist einfach zu machen, aber es wäre keine hauseigene Funktion, sondern eine die ich jedem Script das es nutzt implementieren muss.

PHP ist voll von Spezialfunktionen, die sinnvollerweise nicht das geringste im Core einer Programmiersprache zu suchen haben. In diesem Fall hast Du die Chance, das Richtige zu tun: Implementiere die Funktion - ein einziges Mal, Du kannst sie wiederverwenden. PHP ist nicht eifersüchtig (JavaScript übrigens auch nicht).

Cheatah

[Jens Holzkämper]

Tach,

Du hast geschrieben, dass du die base64-Strings in Dateinamen verwenden willst. Alle mir bekannten Dateisysteme verbieten aber den Schrägstrich '/' in Dateinamen, da er als Delimiter für Verzeichnisse reserviert ist.

HFS+ reserviert den Doppelpunkt anstelle des Slashes; der wird allerdings im normalen OS-X-Finder auf den Slash umgemappt, in der Classic-Umgebung ist der Slash ein erlaubtes Zeichen.

mfg
Woodfighter