Blob to base64

[hotti]

hi,

es muss binarysafe sein, schwer zu finden, ich suche seit gestern ;)

Gibts bestimmt irgendwo, nur wo, Idee?

PS:
window.btoa('string') ist ungeeignet. Es muss ein Blob encoded werden, da sind Oktetten beliebiger Wertigkeiten drin.
Was ich suche, arbeitet asynchron und sollte einen ArrayBuffer erzeugen.

[1UnitedPower]

Meine Herren!

Gibts bestimmt irgendwo, nur wo, Idee?

Man muss schon enormes Pech haben, um in der freien Welt einem Anwendungsfall zu begegnen, der das erfordert. Für das freie Training schau mal hier nach: https://developer.mozilla.org/en-US/Add-ons/Code_snippets/StringView#StringView.prototype.toBase64()

Beachte der Artikel ist mit „This article is in need of a technical review“ geflaggt und ich hab mir die Implementierung auch nicht genauer angesehen.

[hotti]

hi,

Man muss schon enormes Pech haben, um in der freien Welt einem Anwendungsfall zu begegnen, der das erfordert.

Deiner Fantasy sind keine Grenzen gesetzt ;)

Für das freie Training schau mal hier nach: https://developer.mozilla.org/en-US/Add-ons/Code_snippets/StringView#StringView.prototype.toBase64()

Beachte der Artikel ist mit „This article is in need of a technical review“ geflaggt und ich hab mir die Implementierung auch nicht genauer angesehen.

Kannste knicken. StringView u.a. Stringfunktionen sind hier total fehl am Platz.

Wie auch immer, mein handler steht soweit, das wird morgen fertig ;)

Schönes Wochenende,
Horst

PS: Die Umkehrung, base64str => ArrayBuffer, kein Thema.

[ChrisB]

Hi,

window.btoa('string') ist ungeeignet. Es muss ein Blob encoded werden, da sind Oktetten beliebiger Wertigkeiten drin.

Dann kombiniere es mit escape und decodeURIComponent, wie wie in der MDN beschrieben.

MfG ChrisB

[hotti]

hi,

danke auch Dir fürs Nachschauen.

Dann kombiniere es mit escape und decodeURIComponent, wie wie in der MDN beschrieben.

Die Seiten kenne ich gut ;)
Was mich verwundert, ist, dass escape()/unescape() überhaupt noch erwähnt werden, diese Funktionen sind seit Jahren als deprecated eingestuft. Möglicherweise haben damit geführte Workarounds irgendwo (noch) eine Daseinsberechtigung.

Grundsätzlich halte ich es für eine schlechte Idee, base64 mit Character-Semantics zu vermischen oder gar davon abhängig zu machen. D.h., wenn ich mit Strings arbeiten kann, brauche ich base64 nicht. Ein Base64-Encoding muss mit jeder Byte-Folge zurechtkommen und wenn die Oktetten E2, 82, AC ankommen, dann ist das im Low Level nicht das €-Zeichen sondern das sind eben nur Bytes mit diesen Wertigkeiten. Ganz abgesehen davon, dass Browser das €-Zeichen u.a. in mehreren Kodierungstabellen vorhalten, z.B. auch in cp1252 und ein escape dafür %u20AC liefert, was der Codepoint ist der wiederum mit base64 überhaupt nichts zu tun hat, wie Zeichenkodierungen i.A. mit base64 nichts zu tun haben.

Kurzum: window.btoa(), window.atob() u. o.g. Workaround decken irgendwelche Sonderfälle ab, die an dieser Stelle nicht weiter interessieren.

Und endlich: Eine Javascript-base64-Lösung, wäre vor ein paar Jahren nicht möglich gewesen, was MDN hier leistet, ist einfach großartig. Die Lösung führt über typed Arrays, den ArrayBuffer und ein Uint8Array, hierin liegen die Rohdaten. Der ArrayBuffer wird erzeugt mit dem FileReader-EventHandler onload(end), im FileReader.readyState == 2 ist das erledigt. Überhaupt ist der FileReader die einzige Möglichkeit, einen Blob (oder File) zu lesen, darüber sollte sich jeder im Klaren sein und das geht nur asynchron.

Schönen Sonntag ;)
PS: Problem ist gelöst, in Anlehnung an Daniel Guerrero's Base64Binary.decodeArrayBuffer() habe ich meine Funktion Base64String(encode) genannt.

[hotti]

hi,

Was ich suche, arbeitet asynchron und sollte einen ArrayBuffer erzeugen.

Fertig ;)

Hab nun encode/decode in einer eigenen Lib vereint. Von ungezählten Decoder-Scripten, die im Internet und auf Github so rumschwirren hatte ich mich bis gestern für einen entschieden, der angeblich (hab ich auf stackoverflow gelesen) von google genutzt wird. Leider musste ich feststellen, dass auch dieser Code fehlerhaft arbeitet, somit wiederhergestellte Binaries hatten nicht die exakte Länge des Originals.

Mit meiner eigenen Lib funktioniert nun encode/decode in beiden Richtungen mit native Binaries, also Rohdaten, o.g. Link zeigt dies anschaulich.

PS: Mit dem Autor der fehlerhaften Lib habe ich bereits Kontakt aufgenommen.