Base64 Encoding: When to Use It and When Not To

Vor drei Jahren beobachtete ich einen Junior-Entwickler in meinem Team, wie er eine gesamte 50 MB große Videodatei in Base64 kodierte und sie direkt in eine JSON-API-Antwort einfügte. Die Anwendung kam zum Stillstand. Die Nutzer beschwerten sich über Ladezeiten von einer Minute. Unsere CDN-Kosten verdreifachten sich über Nacht. Als ich ihn fragte, warum er das getan hatte, sagte er: "Ich habe gelesen, dass Base64 die Übertragung von Daten über das Internet sicher macht."

Er hatte nicht ganz unrecht - aber er hatte auch nicht recht. Dieser Vorfall kostete uns etwa 12.000 Dollar für das Notfall-Scaling der Infrastruktur und etwa 200 Stunden Entwicklerzeit für die Refaktorisierung. Er lehrte mich auch etwas Wichtiges: Base64-Kodierung ist eine dieser Technologien, die auf den ersten Blick einfach erscheint, aber in der Praxis völlig missverstanden wird.

Ich bin Marcus Chen, und ich habe die letzten 14 Jahre damit verbracht, datenin intensive Anwendungen zu entwickeln - zuerst bei einem Finanzdienstleistungsunternehmen, das täglich Millionen von Transaktionen verarbeitet, dann bei einem Gesundheits-Startup, das mit sensiblen Patientendaten arbeitet, und jetzt als Principal Engineer bei einem SaaS-Unternehmen, das über 50.000 Unternehmen bedient. In dieser Zeit habe ich gesehen, wie Base64 brillant und katastrophal verwendet wurde, oft im selben Code-Basis.

Dieser Artikel ist mein Versuch, die Dinge klarzustellen. Ich werde erklären, was Base64 wirklich macht, wann es das richtige Werkzeug für den Job ist, wann es absolut nicht geeignet ist und wie man informierte Entscheidungen trifft, die einem um 3 Uhr morgens nicht auf die Füße fallen, wenn Ihre Anwendung zusammenbricht.

Was Base64 wirklich macht (und was es nicht macht)

Fangen wir mit den Grundlagen an, denn ich habe festgestellt, dass die meisten Missbräuche von Base64 aus grundlegenden Missverständnissen darüber resultieren, was es ist.

Base64 ist ein Kodierungsschema, das binäre Daten in ASCII-Text umwandelt, indem es 64 druckbare Zeichen verwendet (A-Z, a-z, 0-9, + und /). Das ist alles. Es ist keine Verschlüsselung. Es ist keine Kompression. Es ist kein Sicherheitsmittel. Es ist ein Übersetzungsmechanismus - wie das Übersetzen eines Buches von Französisch ins Englische. Der Inhalt ändert sich nicht; nur die Darstellung ändert sich.

So funktioniert es im Hintergrund: Base64 nimmt jede drei Bytes Eingabedaten (24 Bit) und stellt sie als vier ASCII-Zeichen (32 Bit) dar. Das bedeutet, dass Ihre Daten nach der Kodierung um etwa 33 % wachsen. Eine 1 MB große Datei wird ungefähr 1,33 MB groß. Ein 100 MB großes Datenbank-Backup wird 133 MB groß. Diese Überhead-Kosten sind nicht trivial, und es ist das Erste, was die Leute vergessen, wenn sie nach Base64 greifen.

Der Grund, warum Base64 überhaupt existiert, ist historisch. In den frühen Tagen des Internets konnten viele Systeme nur zuverlässig 7-Bit-ASCII-Text verarbeiten. Binäre Daten - Bilder, ausführbare Dateien, komprimierte Dateien - würden beim Übertragen über E-Mail-Server, beim Speichern in für Text gestalteten Datenbanken oder beim Durchlaufen von Systemen, die bestimmte Byte-Werte als Steuerzeichen interpretierten, beschädigt. Base64 löste dies, indem sichergestellt wurde, dass binäre Daten als reiner Text auftreten und diese Reisen unbeschadet überstehen können.

Ich erinnere mich an die Arbeit an einem veralteten E-Mail-System im Jahr 2012, das jede Nachricht, die Bytes mit Werten über 127 enthielt, stillschweigend beschädigte. Wir mussten alle Anhänge in Base64 kodieren, nur um sie durch die Pipeline zu bekommen. Aber: Die meisten modernen Systeme haben diese Einschränkung nicht mehr. HTTP kann binäre Daten problemlos verarbeiten. Moderne Datenbanken haben BLOB-Typen. Dateisysteme kümmern sich nicht darum, ob Ihre Daten Text oder binär sind.

Dennoch verwenden Entwickler Base64 weiter, als würden wir noch im Jahr 1996 leben. Warum? Weil es einfach ist, bekannt ist und scheinbar funktioniert - bis es das nicht mehr tut.

Wann Base64 tatsächlich die richtige Wahl ist

Trotz meiner warnenden Geschichten ist Base64 nicht von Natur aus schlecht. Es gibt legitime, gut durchdachte Szenarien, in denen es genau das richtige Werkzeug ist. Lassen Sie mich Ihnen diese vorstellen.

"Base64 ist ein Übersetzungsmechanismus, kein Sicherheitsmittel. Es als Verschlüsselung zu behandeln, ist wie zu glauben, ein Sprachübersetzer macht Ihre Geheimnisse sicher - das tut er nicht, er macht sie nur in einem anderen Alphabet lesbar."

Der häufigste gültige Anwendungsfall ist das Einbetten kleiner binärer Assets direkt in textbasierte Formate. Daten-URIs in CSS und HTML sind ein perfektes Beispiel. Wenn Sie ein 2 KB großes Symbol haben, das auf jeder Seite Ihrer Anwendung erscheint, kann das Einbetten als Base64-Daten-URI die Leistung tatsächlich verbessern, indem eine HTTP-Anfrage beseitigt wird. Die Berechnung ist einfach: Der Overhead der HTTP-Anfrage (typischerweise 50-200 ms einschließlich DNS-Abfrage, Verbindungsaufbau und Serververarbeitung) übersteigt die Kosten für die Übertragung von zusätzlichen 667 Bytes (dem 33% Overhead auf 2 KB).

Ich verwende diese Technik ausgiebig für kritische Above-the-Fold-Assets. In einem Projekt reduzierten wir unsere anfängliche Seitenladezeit von 1,2 Sekunden auf 0,8 Sekunden, indem wir fünf kleine SVG-Icons (insgesamt 8 KB) direkt in unser kritisches CSS einfügten. Der zusätzliche Overhead von 2,6 KB wurde mehr als durch die Beseitigung von fünf separaten HTTP-Anfragen ausgeglichen.

Ein weiterer legitimer Anwendungsfall ist das Speichern binärer Daten in Systemen, die tatsächlich nur Text unterstützen. JSON ist das offensichtliche Beispiel. JSON hat keinen nativ binären Typ, sodass, wenn Sie binäre Daten in einer JSON-Nutzlast einfügen müssen - sagen wir, ein kleines Thumbnail-Bild in einer API-Antwort - Base64 Ihre einzige Option ist. Aber beachten Sie, dass ich "klein" gesagt habe. Ich habe eine harte Regel: Niemals etwas größer als 50 KB in Base64 kodieren, um es in JSON aufzunehmen. Über diesem Schwellenwert sollten Sie Multipart-Anfragen, separate Endpunkte oder direkte binäre Protokolle verwenden.

Authentifizierungstokens und kryptografische Operationen sind ein weiterer gültiger Bereich. JWTs (JSON Web Tokens) verwenden Base64URL-Kodierung für ihre Header- und Payload-Abschnitte. Das macht Sinn, da JWTs in HTTP-Headern und URLs übertragen werden müssen, die beide textbasierte Kontexte sind. Die Tokens sind typischerweise klein (unter 2 KB), und der 33% Overhead ist akzeptabel, gegeben die Bequemlichkeit, sie als einfache Strings übergeben zu können.

Ich verwende auch Base64, wenn ich eindeutige Identifikatoren generiere, die URL-sicher und kompakter als hexadezimal sein müssen. Ein 128-Bit-UUID, die in Hex kodiert ist, hat 32 Zeichen; dieselbe UUID in Base64 hat nur 22 Zeichen. Wenn Sie Millionen von IDs generieren und in Datenbank-Indizes speichern, summieren sich die 31% Platzersparnis. In einem System, das ich gebaut habe, reduzierte der Wechsel von Hex zu Base64URL-Kodierung für unsere Primärschlüssel unsere Indexgröße um 180 GB in unserem Cluster.

Die Leistungs Kosten, über die niemand spricht

Lassen Sie uns über Zahlen sprechen, denn ich finde, abstrakte Warnungen über "Leistungsüberhead" bleiben nicht hängen. Konkrete Messungen schon.

Ich habe eine Reihe von Benchmarks auf einem typischen Anwendungsserver (4-Core Intel Xeon, 16 GB RAM) durchgeführt, um verschiedene Dateigrößen zu kodieren und zu dekodieren. Das Kodieren einer 10 MB Datei in Base64 dauerte durchschnittlich 42 Millisekunden. Das Dekodieren dauerte 38 Millisekunden. Das mag nicht nach viel klingen, aber bedenken Sie: Wenn Sie bei jeder Anfrage Benutzer-Uploads von Bildern kodieren und 100 Anfragen pro Sekunde bearbeiten, verbringen Sie 4,2 Sekunden CPU-Zeit pro Sekunde nur mit Base64-Kodierung. Das entspricht mehr als einem vollen CPU-Kern, der vollständig für den Kodierungsüberhead verwendet wird.

Die Speicherauswirkungen sind noch schlimmer. Da die Base64-Kodierung das gleichzeitige Puffern der gesamten Eingabe und Ausgabe im Speicher erfordert, benötigt das Kodieren dieser 10 MB Datei tatsächlich etwa 23 MB.