Pourquoi ne l'encodage base64 exiger remplissage si l'entrée de la longueur n'est pas divisible par 3?

Quel est le but de rembourrage dans le codage base64. Ce qui suit est l'extrait de wikipedia:

"Un pad supplémentaire personnage est alloué qui peut être utilisé pour forcer la sortie encodé en un entier multiple de 4 caractères (ou de manière équivalente la forme non codée binaire texte n'est pas un multiple de 3 octets) ; ces caractères de remplissage doit ensuite être jetés lors du décodage, mais encore de permettre le calcul de la longueur effective de la forme non codée texte, lors de son entrée binaire de longueur ne serait pas un multiple de 3 octets (le dernier non-caractère de remplissage est normalement codée de telle sorte que les 6 derniers bits du bloc qu'il représente est complété par des zéros sur ses bits de poids faible, pas plus de deux pavé de caractères peut se produire à la fin de l'encodage du flux)."

J'ai écrit un programme qui pourrait base64 encode une chaîne et de décoder n'importe quel chaîne encodée en base64. Ce problème ne rembourrage en résout?

InformationsquelleAutor Anand Patel | 2010-11-02
  1. 166

    Votre conclusion que le rembourrage est inutile est à droite. Il est toujours possible de déterminer la longueur de l'entrée sans ambiguïté de la longueur de la séquence encodée.

    Cependant, le rembourrage est utile dans les situations où les chaînes codées en base64 sont concaténées de telle sorte que les longueurs des séquences individuelles sont perdus, comme cela pourrait se produire, par exemple, dans un très simple de protocole de réseau.

    Si unpadded chaînes sont concaténées, il est impossible de récupérer les données d'origine parce que les informations sur le nombre impair d'octets à la fin de chaque séquence est perdu. Toutefois, si le collier de séquences sont utilisés, il n'y a pas d'ambiguïté, et la séquence dans son ensemble peut être décodé correctement.

    Edit: Une Illustration

    Supposons que nous avons un programme qui base64 encode les mots, les concatène et les envoie sur un réseau. Il encode "je", "AM" et "TJM", les sandwiches, les résultats d'ensemble sans rembourrage et les transmet.

    • I code SQ (SQ== avec un rembourrage)
    • AM code QU0 (QU0= avec un rembourrage)
    • TJM code VEpN (VEpN avec un rembourrage)

    Si les données transmises sont SQQU0VEpN. Le récepteur base64 décode ce que I\x04\x14\xd1Q) au lieu de la IAMTJM. Le résultat est un non-sens parce que l'expéditeur a détruit des informations sur l'endroit où chaque mot se termine dans la séquence encodée. Si l'expéditeur a envoyé SQ==QU0=VEpN au lieu de cela, le récepteur pourrait avoir décodé ce que trois base64 séquences qui serait concaténer pour donner IAMTJM.

    Pourquoi s'Embêter avec un Rembourrage?

    Pourquoi ne pas concevoir le protocole de préfixe de chaque mot avec un nombre entier de longueur? Ensuite, le récepteur peut décoder le flux de données correctement et il n'y aurait pas besoin de rembourrage.

    C'est une excellente idée, tant que nous savoir la longueur des données, nous sommes d'encodage avant de commencer l'encodage. Mais si, au lieu de mots, nous avons été encodage des morceaux de vidéo à partir d'un live de la caméra? Nous pourrions ne pas connaître la longueur de chaque bloc à l'avance.

    Si le protocole utilisé rembourrage, il n'y aurait pas besoin de transmettre une longueur à tous. Les données peuvent être codées comme il est venu de la caméra, chaque morceau est arrêté avec rembourrage, et le récepteur serait en mesure de décoder le flux de données correctement.

    Évidemment c'est un exemple artificiel, mais peut-être cela explique pourquoi rembourrage pourrait être utile dans certaines situations.

    • +1, La seule réponse qui fournit en fait une réponse raisonnable à part "parce que nous aimons la verbosité et la redondance pour des raisons inexplicables".
    • Ceci fonctionne bien pour les morceaux qui sont codés distinctement, mais devraient l'être de manière indivisible concaténées après décodage. Si vous envoyez U0FNSQ==QU0=, vous pouvez reconstruire la phrase, mais vous perdez les mots qui composent la phrase. Mieux que rien, je suppose. Notamment, la GNU base64 programme gère automatiquement concaténées encodages.
    • Que faire si la longueur des mots est un multiple de 3? Cette stupide façon de concaténation détruit de l'information (terminaisons de mots), et non pas la suppression de rembourrage.
    • Je suis déchiré entre upvoting et ne voulant pas gâcher cette belle "42" numéro..
    • Base64 la concaténation permet de codeurs processus de gros morceaux en parallèle, sans le fardeau de l'alignement des tailles de segment à un multiple de trois. De même, comme un détail d'implémentation, il y a peut être un codeur qui doit rincer l'intérieur de la mémoire de données d'une taille qui n'est pas un multiple de trois.
    • C'est vrai, l'utilisation de rembourrage n'autorise pas les mots pour être récupérées individuellement, il permet uniquement de s'assurer que l'ensemble de la séquence peut être décodé correctement.
    • Je ne suis pas ce qui implique au-dessus de que rembourrage préserve la longueur des mots - il ne l'est pas, puisque, comme vous l'avez souligné, si la longueur d'un mot est un multiple de 3, il a besoin d'aucun rembourrage. Plutôt, pour les mots dont les longueurs sont pas des multiples de 3, rembourrage empêche l'encodage de la 1 ou 2 balançant octets à la fin de la parole à partir de confondre avec l'encodage du mot suivant, l'ensemble de la séquence peut être décodé comme prévu.

    InformationsquelleAutor TJM
  2. 33

    Quels sont les Caractères de Remplissage?

    Les caractères de remplissage aider à satisfaire les exigences de longueur et de transporter aucun sens.

    Décimal Exemple de Rembourrage:
    Compte tenu de l'arbitraire exigence de toutes les chaînes de caractères 8 caractères, le nombre de 640 peut répondre à cette exigence précédant le 0 comme les caractères de remplissage comme ils ne portent aucun sens, "00000640".

    Codage Binaire

    L'Octet de Paradigme: L'octet est la norme de facto unité de mesure et de tout schéma de codage doit relier octets.

    Base256 s'inscrit exactement dans ce paradigme. Un octet est égal à un personnage dans base256.

    Base16, hexadécimal ou hex, utilise 4 bits pour chaque caractère. Un octet peut représenter deux base16 caractères.

    Base64 ne correspond pas de manière uniforme dans l'octet de paradigme, à la différence de base256 et base16. Tous les base64 caractères peuvent être représentés dans les 6 bits, 2 bits court plein d'un octet.

    Nous pouvons représenter l'encodage base64 rapport à l'octet paradigme comme une fraction: 6 bits par caractère sur 8 bits par octet. Réduit cette fraction est de 3 octets de plus de 4 caractères.

    Ce ratio, 3 octets pour chaque 4 base64 caractères, est la règle que nous voulons suivre lors de l'encodage en base64. De l'encodage Base64 ne peut promettre de même de se mesurer avec 3 octets faisceaux, à la différence de base16 et base256 où chaque octet peut se tenir debout sur ses propres.

    Donc pourquoi est rembourrage encouragé, même si l'encodage pourrait très bien fonctionner sans les caractères de remplissage? Les caractères de remplissage de communiquer de manière explicite que ces places supplémentaires devraient être vide, et exclut toute ambiguïté ou potentiellement méchants bugs. Rembourrage nous permet de décoder le codage base64 avec la promesse de ne perdu bits. Sans rembourrage, il n'est plus la reconnaissance explicite de la mesure en trois octets faisceaux et nous ne pouvons plus garantir la reproduction exacte de l'original de l'encodage sans informations supplémentaires.

    Exemples

    Voici le formulaire de l'exemple de la RFC 4648 (http://tools.ietf.org/html/rfc4648#section-8)

    Chaque caractère à l'intérieur de la "BASE64" fonction utilise un octet (base256). Nous avons ensuite le traduire en base64.

    BASE64("")       = ""           (No bytes used. 0%3=0.)
BASE64("f")      = "Zg=="       (One byte used. 1%3=1.)
BASE64("fo")     = "Zm8="       (Two bytes. 2%3=2.)
BASE64("foo")    = "Zm9v"       (Three bytes. 3%3=0.)
BASE64("foob")   = "Zm9vYg=="   (Four bytes. 4%3=1.)
BASE64("fooba")  = "Zm9vYmE="   (Five bytes. 5%3=2.)
BASE64("foobar") = "Zm9vYmFy"   (Six bytes. 6%3=0.)

    Voici un codeur qui vous permettent de jouer avec: http://www.motobit.com/util/base64-decoder-encoder.asp

    • -1 C'est une belle et approfondie post sur la façon dont nombre de systèmes de travail, mais ça n'explique pas pourquoi rembourrage est utilisé lors de l'encodage fonctionne parfaitement sans.
    • Avez-vous encore lu la question? Vous n'avez pas besoin rembourrage pour décoder correctement.
    • Je pense que cette réponse n'a en fait d'expliquer les raisons que voici: "nous ne pouvons plus garantir la reproduction exacte de codage d'origine, sans information supplémentaire". C'est très simple, le rembourrage laissez-nous savoir que nous avons reçu la complète codage. Chaque fois que vous avez 3 octets, vous pouvez supposer que c'est ok pour aller de l'avant et de le décoder, vous ne vous inquiétez pas que, hum... peut-être un octet de plus est la possibilité de changer l'encodage.
    • Comment savez-vous qu'il n'y a pas plus de 3 octets dans un fichier crypté en base64 sous-chaîne? Pour décoder un char*, vous avez besoin de la taille de la chaîne ou un terminateur null. Rembourrage est redondante. Par conséquent, OP question.
    • Si vous êtes flux de décodage base64 octets, vous ne connaissez pas la longueur, avec les 3 octets de padding, vous savez que chaque fois que vous avez obtenu 3 octets, vous pouvez traiter la de 4 caractères, jusqu'à ce que vous atteignez la fin du flux. Sans elle, vous pourriez avoir besoin de revenir en arrière, parce que le prochain octet peut causer le caractère précédent à changer, donc, que vous ne pouvez être sûr que vous décodé correctement une fois que vous avez atteint la fin du flux. Donc, il n'est pas très utile, mais il a quelques cas où vous le souhaitez sur.
    • Une chaîne de caractères avec les signes "égal" n'importe où, mais à la fin est non-conforme, bien que certaines implémentations de l'accepter. Il aurait été utile d'avoir ces chaînes classées comme "non-canonique" et de reconnaître les contextes où les applications ou ne devrait pas accepter de telles chaînes, car il y a des moments où être en mesure de concaténer des chaînes de caractères est utile, mais d'autres fois, il est plus important d'être en mesure de comparer deux chaînes de caractères pour l'égalité.
    • Si vous êtes le décodage en base64, alors vous auriez besoin de processus de 4 octets à la fois, ce qui représenterait entre 1 et 3 décodé octets (caractères dans vos mots).

    InformationsquelleAutor Zamicol
  3. 2

    Ce n'est qu'une théorie de la mienne, et je ne peut pas fournir des sources, mais je pense que le rembourrage personnage(s) qui ne servent qu'à faire certaines implémentations de l'algorithme de décodage d'un moindre peu plus simple. En particulier, si l'algorithme met la chaîne codée en quelque chose comme int[] alors la valeur finale sera parfois trop long.

    Si le rembourrage est déjà présent dans l'entrée puis rien d'autre qu'il faut faire, l'algorithme peut juste lire et décoder l'entrée.

    Si l'algorithme n'est pas permis de supposer que le rembourrage à l'heure actuelle, cependant, et il utilise int[]-comme discbased, puis il doit manuellement pad de la finale entier avant de décodage, ou une comptabilité d'entrée de la longueur d'origine.

    Personnellement, je ne pense pas que le rembourrage sert à quelque fin que ce soit, mais de retour quand le CPU et la RAM n'étaient pas aussi nombreux que maintenant cette légère optimisation peut avoir d'importance. Je doute qu'il importait que très bien... une bonne mise en œuvre aura toujours besoin de faire quelque chose de raisonnable, lorsque l'on nourri d'entrée qui a été tronqué au hasard, et que, de l'OMI, serait de donner la possibilité aux processus unpadded entrées à aucun coût supplémentaire.

    • En l'absence de rembourrage, une tentative pour concaténer deux chaînes lors de la première longueur de la chaîne n'est pas un multiple de trois donnent souvent une apparence-chaîne valide, mais le contenu de la deuxième chaîne de décoder de manière incorrecte. Ajouter le rembourrage assure que ne se produit pas.
    • Si c'était le but, ne serait-il pas plus facile à la fin de chaque chaîne base64 avec un seul "="? La durée moyenne serait plus courte, et il serait encore éviter toute erreur d'enchaînements.
    • La durée moyenne d'un b'Zm9vYmFyZm9vYg==' b'Zm9vYmFyZm9vYmE=' b'Zm9vYmFyZm9vYmFy' b'Zm9vYmFyZm9vYmFyZg==' b'Zm9vYmFyZm9vYmFyZm8=' b'Zm9vYmFyZm9vYmFyZm9v' est la même que celle de b'Zm9vYmFyZm9vYg=' b'Zm9vYmFyZm9vYmE=' b'Zm9vYmFyZm9vYmFy=' b'Zm9vYmFyZm9vYmFyZg=' b'Zm9vYmFyZm9vYmFyZm8=' b'Zm9vYmFyZm9vYmFyZm9v='
    InformationsquelleAutor Roman Starkov