Entwicklertools · Base64-Encoder und -Decoder
Base64 vs. Hex vs. Base32: Vergleich von drei Möglichkeiten, Bytes als Text zu schreiben
· Hintergrund
base64 Kodierung
Hex, base32 und Base64 lösen das gleiche Problem mit unterschiedlichen Kompromissen in Bezug auf Größe, Lesbarkeit und Sicherheit. In diesem Beitrag werden sie hinsichtlich Dichte, Groß-/Kleinschreibung, URL-Sicherheit und menschlichem Versagen verglichen.
Der API-Schlüssel, der aufgrund von l, 1, I und O falsch eingegeben wurde – ein konkreter Lesbarkeitsfehler, den hex nicht gehabt hätte
Drei gängige Möglichkeiten, Bytes als Text darzustellen, sind Hex, Base32 und Base64. Sie lösen alle das gleiche Problem (Darstellung beliebiger Bytes in druckbarem ASCII), jedoch mit unterschiedlichen Kompromissen in Bezug auf Größe, Lesbarkeit und Fehlerresistenz. Hex besteht aus 2 Zeichen pro Byte (F3 A2 B1 ...), sodass 16 Bytes zu 32 Zeichen werden. Base32 umfasst 1.6 Zeichen pro Byte (ungefähr 5 Zeichen pro 3 Bytes), sodass aus 16 Bytes 26 Zeichen werden.
Base64 besteht aus 1.33 Zeichen pro Byte (genau 4 Zeichen pro 3 Bytes), sodass 16 Bytes zu 24 Zeichen oder weniger werden. Wenn es auf die Dateigröße ankommt, ist Base64 am kompaktesten. Wenn die menschliche Transkription wichtig ist, sind Hex und Base32 sicherer. Der Unterschied in der Lesbarkeit ist entscheidend, wenn ein Wert eingegeben, kopiert oder gesprochen wird. Hex verwendet 0-9 und a-f (Groß- und Kleinschreibung wird in den meisten Kontexten nicht beachtet). Ein Transkriptionskanal ändert die Entscheidung, da eine für Maschinen optimierte Darstellung für Menschen umständlich sein kann. Base64 unterscheidet zwischen Groß- und Kleinschreibung und verwendet zwei Satzzeichen. Hex verwendet ein kleineres visuelles Vokabular. Die Implementierung testet hier exakte Zeichenfolgen und keine menschliche Fehlerquote, sodass keine erfundene Wahrscheinlichkeit angehängt ist.
Dichte: 2×, 1.6× und 1.33× – wie viele Zeichen jede Kodierung pro Byte benötigt und warum
Base32 verwendet A-Z und 2-7 und vermeidet so 0, 1, O und I, die auf dem Papier leicht verwechselt werden können. Base64 verwendet A-Z, a-z, 0-9, + und /,, einschließlich Groß- und Kleinbuchstaben, wodurch die Groß- und Kleinschreibung beachtet wird und Ziffern gemischt werden, die ähnlich aussehen (0 gegenüber O, 1 gegenüber I gegenüber dem Kleinbuchstaben l). Ein hexadezimaler API-Schlüssel könnte f3a2b1e4 sein; Die gleichen Bytes in Base64 könnten 86KrvE== (mit Auffüllung) oder in Base32 6VEV7FI= (mit Auffüllung) sein.
Wenn ein Benutzer den Wert manuell eingeben muss, ist Hex oder Base32 sicherer als Base64. Reservierte Zeichen in URLs sind wichtig. Hex und Base32 sind für URLs sicher; beide verwenden nur alphanumerische Zeichen (Hex verwendet auch 0-9, Base32 verwendet auch 2-7). Base64 verwendet Plus und Schrägstrich, die URL-reserviert sind (Plus stellt ein Leerzeichen in formcodierten Daten dar, Schrägstrich ist ein Pfadtrenner). Die Base64-Dichte ergibt sich direkt aus sechs Nutzbits pro Ausgabesymbol und dem Auffüllen in Blöcke mit vier Zeichen. Hex trägt vier Bits pro Symbol, also zwei Zeichen pro Byte. Base32 wird nur als Vergleichskontext diskutiert, da dieses Repository weder sein Alphabet noch einen Encoder zur Überprüfung der Ausgaben bereitstellt.
Dichte aus Bitbreite – exakte Base64- und Hex-Arithmetik, wobei Base32 als Vergleichskontext behandelt wird
Eine Base64-Zeichenfolge in einem URL-Parameter muss prozentcodiert sein (Plus wird zu %2B, Schrägstrich wird zu %2F), wobei für jedes Vorkommen 4 zusätzliche Zeichen hinzugefügt werden. Base64url (RFC 4648 Abschnitt 5) ersetzt Plus durch Bindestrich und Schrägstrich durch Unterstrich, wodurch es ohne Prozentkodierung URL-sicher wird. Die meisten APIs, die base64 in URLs verwenden, verwenden tatsächlich base64url, aber die Unterscheidung wird in der Dokumentation oft nicht explizit erwähnt.
TOTP-Geheimnisse (die von Authentifizierungs-Apps verwendeten Codes) werden normalerweise als Base32 verteilt. Auf einem TOTP-Registrierungsbildschirm wird ein Base32-Geheimnis angezeigt, da es einfacher einzugeben und zu transkribieren ist als dieselben Bytes in Base64 oder Hex. SHA-Hash-Digests werden häufig im Hexadezimalformat angezeigt, da es sich um das traditionelle Format handelt und die Groß-/Kleinschreibung beim Hexadezimalformat nicht beachtet wird, was Tippfehler weniger wahrscheinlich macht. Die Beachtung der Groß- und Kleinschreibung ist wichtig, wenn jemand einen Wert vorliest oder erneut eingibt, da sich durch die Änderung der Groß-/Kleinschreibung eines Buchstabens dessen Index ändert. ToolAcre behält die Groß-/Kleinschreibung exakt bei und dekodiert die resultierenden unterschiedlichen Bytes, ohne zu wissen, dass ein Mensch einen Transkriptionsfehler begangen hat. Die Darstellung selbst hat keine Prüfsumme.
Reservierte Zeichen und URL-Sicherheit – wo + und / beißen und wie Base32 und Hex das Problem vermeiden
JWTs verwenden base64url. Dateiprüfsummen können hexadezimal oder base64 sein; beides ist üblich. Die Wahl ist eine historische Konvention, keine technische Notwendigkeit. Fehlerresilienz ist ein subtiler, aber wichtiger Unterschied. Base32 vermeidet die Ziffern 0, 1, 8 und 9 (die wie Buchstaben aussehen), wodurch Transkriptionsfehler reduziert werden. Base64 umfasst alle Ziffern, wodurch 1 mehrdeutig ist (ist es ein Buchstabe I, ein kleines l oder die Ziffer 1?).
Hex ist noch fehleranfälliger: 0 sieht aus wie O, l sieht aus wie 1. Eine Prüfsumme, die eingegeben oder aus einem Ausdruck gelesen werden muss, ist in Base32 sicherer. Ein API-Schlüssel, der direkt von einem Computer eingefügt wird, ist in jedem Format sicher; Lesbarkeit ist nur wichtig, wenn das menschliche Auge beteiligt ist. Gleiche Bytes, aber unterschiedliche Codierung: Die 16-Byte-Sequenz [0xf3, 0xa2, 0xb1, ...] wird zu f3a2b1 ... Standard-Base64-Plus und Schrägstrich erfordern eine kanalbewusste Behandlung; Im URL-sicheren Modus werden sie durch Bindestrich und Unterstrich ersetzt. Hex vermeidet diese Trennzeichen, indem es nur Ziffern und Buchstaben verwendet. Die Base32-Konventionen variieren, daher vermeidet dieser Artikel vielversprechende Sicherheitseigenschaften, die das Repository nicht implementiert oder testet.
Arbeitsbeispiel: die gleichen 16 Bytes in allen drei Kodierungen – Längenvergleich und Sichtprüfung
in Hex, 6VEV7FI=... in Base32 und 86KrvE== in Base64. Keine dieser Saiten ist austauschbar. Eine Anwendung, die f3a2b1... empfängt, erwartet Hex und versucht, es als Hex zu analysieren. Der Empfang von 86KrvE== schlägt fehl, wenn die Anwendung Hex erwartet. Das Verschlüsselungsformat ist Teil des Datenvertrags: Sender und Empfänger müssen sich darauf einigen, welche Verschlüsselung verwendet wird. Ein weiterer Unterschied besteht in der Polsterung.
Hex verwendet keine Auffüllung (4 Bytes sind immer 8 Hexadezimalzeichen, keine Ausnahmen). Sowohl Base32 als auch Base64 verwenden die gleiche Auffüllung, um die Ausgabe auf ein Vielfaches von Zeichen auszurichten (8 für Base32, 4 für Base64). Die Auffüllung ist mathematisch notwendig; Es stellt sicher, dass jede N-Byte-Eingabe eine deterministische Zeichenanzahl erzeugt. Die Auffüllregeln variieren: Bei einigen Anwendungen ist ein Auffüllen erforderlich, bei anderen kann darauf verzichtet werden. Der ausgearbeitete Vergleich verwendet eine feste Bytesequenz und berechnet Base64 und Hex mechanisch. Seine Base32-Länge kann anhand der Fünf-Bit-Gruppierung diskutiert werden, ein genauer Base32-Textwert wird jedoch weggelassen, da er von keiner überprüften Implementierung generiert wurde. Längenarithmetik und Ausgabeüberprüfung werden getrennt gehalten.
Wobei jedes konventionell ist – Hashes in Hex, TOTP-Geheimnisse in Base32, JWTs und Daten: URIs in Base64
Beim Einfügen eines Base32- oder Base64-Werts ohne Auffüllung können Decoder ihn je nach Implementierung akzeptieren oder ablehnen. Kryptografische Schlüssel und Token zeigen den Codierungsunterschied.
Ein HMAC-Schlüssel besteht aus 32 Bytes, die zu 64 Hexadezimalzeichen, 52 Base32-Zeichen (mit Auffüllung) oder 44 Base64-Zeichen (mit Auffüllung) werden. Bei der Weitergabe eines Schlüssels sollte die Verschlüsselung dokumentiert werden. Wenn in der Dokumentation steht, dass der Schlüssel aus 44 base64-Zeichen besteht, Sie aber 52 Zeichen erhalten, stimmt etwas nicht. Konventionen können den Lesern Orientierung geben, beweisen aber nicht die Eignung. Hash-Digests werden üblicherweise als Hex angezeigt, während JWT-Segmente Base64url verwenden. Die richtige Wahl hängt immer noch von den Kanalregeln ab, davon, ob die Leute den Wert kopieren und ob ein anderes Protokoll die Darstellung bereits festgelegt hat.
Was hiervon nicht abgedeckt wird: Base58-, Base85- und Prüfsummenkodierungen
Die kürzere Base64-Kodierung erleichtert das Einpassen von Token in Systeme mit Zeichenbeschränkungen (wie QR-Codes oder URLs) etwas. Die Wahl der Kodierung für einen Wert wird durch das Ökosystem bestimmt, aus dem er stammt. Web-APIs verwenden häufig base64url. In der kryptografischen Dokumentation wird häufig Hex verwendet. Authentifizierungs-Apps verwenden Base32. Wählen Sie beim Aufbau eines Systems eine Kodierung aus, dokumentieren Sie sie klar und bleiben Sie dabei.
Das Mischen von Codierungen (z. B. Base64 oder Base32) führt zu Verwirrung. Beim Debuggen besteht der erste Schritt darin, zu ermitteln, welche Codierung der Wert verwendet. Das Base64-Encoder- und Decoder-Tool kann dabei helfen, indem es versucht, es auf mehrere Arten zu dekodieren und zu sehen, welche sinnvolle Ausgabe erzeugt. Keine Kodierung ist allgemein besser. Base64 ist für die Rohspeicherung am kompaktesten. Hex ist den Kryptografen am vertrautesten und für kleine Sequenzen am besten für den Menschen lesbar. Base58-, Base85- und Prüfsummenkodierungen gehen unterschiedliche Kompromisse ein und fehlen im Base64-Panel von ToolAcre. Ihre Alphabete, Mehrdeutigkeitsregeln und Prüfsummen sollten mit dedizierten Quellen und Implementierungen ausgewertet werden, anstatt aus dem getesteten Verhalten dieses Tools zu extrapolieren.
Takeaway: Wählen Sie die Codierung für den Kanal und den Reader aus – wie der Base64-Encoder und -Decoder den Base64-Fall im Browser zusammen mit dem SHA-Hash-Rechner im selben Produkt abdeckt
Base32 ist am widerstandsfähigsten gegenüber Transkriptionsfehlern. Die Wahl hängt vom Kontext ab: wo der Wert lebt, wie er geteilt wird und welche Systeme ihn konsumieren.
Wenn Sie die Kompromisse verstehen, können Sie beim Entwerfen einer API oder eines Systems eine kluge Entscheidung treffen. Das Base64-Encoder- und Decoder-Tool demonstriert die Base64-Codierung. Wenn Sie es zusammen mit einem Hex- oder Base32-Tool verwenden, können Sie die gleichen Bytes in allen drei Formaten sehen und deren Größen- und Lesbarkeitsunterschiede verstehen. Codieren Sie für den Base64-Fall ein Beispiel, notieren Sie sich die genauen UTF-8-Byte- und Ausgabezeichenzahlen und testen Sie die Standard- und URL-sichere Zeichensetzung. Verwenden Sie für Digest-Arbeiten das separate SHA-Panel. Durch die Unterscheidung dieser Vorgänge wird verhindert, dass eine Kodierungsauswahl mit Hashing oder Integritätsschutz verwechselt wird.