nicht angemeldet
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
Der Martin