Einige Bits im letzten Zeichen enthalten keine Daten
RFC 4648 §3.5 verlangt, dass konforme Encoder Pad-Bits auf null setzen. Bei einem Eingabebyte enthalten nur die oberen zwei Bits des zweiten Base64-Zeichens Daten; die anderen vier sind Pad-Bits. g hat Index 32, 100000; h hat Index 33, 100001. Das Byte für f ist 01100110, und die Datenbits stimmen überein. Zg== ist die kanonische Ausgabe; Zh== enthält Pad-Bits ungleich null. Die abschließenden =-Zeichen sind nicht die verworfenen Bits.
Decodieren und erneutes Codieren prüfen
Die tolerante Base64-Decodierung von WHATWG Infra verwirft die letzten vier Bits einer verbleibenden 12-Bit-Gruppe oder zwei einer 18-Bit-Gruppe. HTML atob verwendet dieses Verfahren. Moyoutil gewinnt Bytes mit atob zurück und interpretiert sie als UTF-8-Text. Unsere ausgeführten Beispiele lieferten für Zg== und Zh== jeweils f und für Zm8= und Zm9= jeweils fo. Erneutes Codieren ergab Zg== und Zm8=. Der folgende Code codiert Bytes direkt erneut, ohne beliebige Binärdaten in UTF-8-Text umzuwandeln.
for (const input of ['Zg==', 'Zh==', 'Zm8=', 'Zm9=']) {
const bytes = atob(input);
const canonical = btoa(bytes);
console.log(input, bytes, canonical, input === canonical);
}
// Zg== f Zg== true
// Zh== f Zg== false
// Zm8= fo Zm8= true
// Zm9= fo Zm8= falseGleiche Bytes und gleiche ursprüngliche Zeichenfolgen sind unterschiedliche Bedingungen. Lege fest, welche Gleichheit Cache-Schlüssel oder Vergleiche brauchen. Verlangt das empfangende Protokoll kanonische Eingaben, prüfe dessen Regeln. Signierte Zeichenfolgen sollten vor der Prüfung nicht beliebig verändert werden. Dieser Vergleich gilt nur für Standard-Base64 mit Padding und ersetzt keinen allgemeinen Protokollvalidator.
Häufig gestellte Fragen
Akzeptiert jeder Decoder Zh==?
Nein. RFC 4648 erlaubt die Ablehnung von Pad-Bits ungleich null; eine darauf verweisende Spezifikation kann das Verhalten festlegen. Die Ergebnisse gelten für HTML atob und die aktuelle Moyoutil-Implementierung.
