nicht angemeldet
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.