Diese drei Namen beschreiben verwandte Binär-zu-Text-Schemata, erfüllen jedoch unterschiedliche Einschränkungen. Base64 und Base64URL verwenden Sechs-Bit-Gruppen. Der Standard Base32 verwendet Fünf-Bit-Gruppen und ein kleineres Alphabet. Die richtige Wahl ist diejenige, die Ihre Transport-, Lager- und Empfangsanwendung genau erfüllen kann.
Vergleichen Sie Alphabete vor Längen
Der Standard Base64 verwendet Groß- und Kleinbuchstaben, Ziffern sowie Plus- und Schrägstriche. Base64URL ersetzt die letzten beiden Zeichen durch Bindestriche und Unterstriche. Bei beiden wird die Groß-/Kleinschreibung beachtet. Der Standard-RFC Base32 verwendet die Großbuchstaben A–Z und die Ziffern 2–7. Ein Decoder kann der Einfachheit halber Kleinbuchstaben akzeptieren, aber ein Protokoll sollte angeben, ob dies zulässig ist, und seine kanonische Ausgabe definieren.
Ein Kanal, bei dem die Groß-/Kleinschreibung nicht beachtet wird, kann einen Base64-Wert zerstören und gleichzeitig einen ordnungsgemäß angegebenen Base32-Wert beibehalten. Für einen URL-Token gelten andere Einschränkungen als für einen über ein Telefon vorgelesenen Code. Wählen Sie nicht nur danach, wie kurz eine Probe aussieht.
Verstehen Sie den Größenkompromiss
Wenn man die letzte Teilgruppe ignoriert, benötigt Base64 etwa 1,33 Zeichen pro Byte und Base32 1,6. Der standardmäßig aufgefüllte Base32 gibt Gruppen mit acht Zeichen für fünf Bytes aus. Für ein Byte, das den Buchstaben f enthält, sind die gemeinsamen Vektoren Zg== in Base64 und MY====== in Base32. Kleine Eingaben erhöhen den Padding-Aufwand. Vergleichen Sie daher realistische Nutzlastlängen.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Mischen Sie nicht die Varianten Base32
Crockford Base32 basiert auf für Menschen lesbaren Bezeichnern und verwendet ein anderes Alphabet und andere Mehrdeutigkeitsregeln als RFC Base32. Base32hex unterscheidet sich ebenfalls. Ein von einer Variante erzeugter Wert kann nicht blind an einen anderen Decoder weitergegeben werden. Benennen Sie die Variante, das Alphabet, die Auffüllrichtlinie und etwaiges Prüfsummenverhalten in Ihrer Dokumentation.
Die Verschlüsselung stellt auch keine Authentifizierung bereit. Ein falsch eingegebener Wert ist möglicherweise immer noch syntaktisch gültig und wird in andere Bytes dekodiert. Wenn Benutzer einen Code transkribieren, sollten Sie eine protokolldefinierte Prüfsumme oder einen Verifizierungsschritt in Betracht ziehen, anstatt davon auszugehen, dass das Alphabet jeden Fehler erkennt.
Schreiben Sie den vollständigen Vertrag auf
Geben Sie gegebenenfalls die Reihenfolge der Eingabebytes, das Verhalten bei leeren Eingaben, die Beibehaltung führender Nullen, die maximale Länge, die Akzeptanz von Leerzeichen und die Behandlung ungültiger Zeichen an. Schließen Sie Testvektoren mit hochwertigen Bytes und Teilgruppen ein. Verwenden Sie den von Ihnen gewählten Encoder und Decoder unabhängig voneinander für diese Vektoren und nicht nur gegeneinander. Andernfalls kann es so aussehen, als würden übereinstimmende Fehler einen Roundtrip durchlaufen. Die Standardformen und Referenzvektoren finden Sie in RFC 4648.