Si vous avez des données binaires que vous devez coder, quel système d'encodage utilisez-vous?
Je sais à propos de:
Y a-t-il d'autres systèmes de codage en commun? Si oui, quels y a-t-il des avantages et des inconvénients?
EDIT : Ceci est utile, par exemple, lorsque vous essayez de stocker des données arbitraires dans un cookie. Les cookies ne peuvent stocker que le texte, pas des données arbitraires, vous devez donc la convertir d'une manière ou d'une autre, de préférence avec un moyen de le convertir. En outre, supposez que vous utilisiez un serveur apatride afin de ne pas pouvoir enregistrer l'état sur le serveur et simplement mettre un identifiant dans le cookie. Bien sûr, si vous le faites, vous auriez également besoin d'une manière de vérifier que l'utilisateur vous repasse est ce que vous avez passé à l'utilisateur, par exemple une signature.
En outre, étant donné que le consensus actuel est que vous devez utiliser BASE64, car il est répandu, je soulignerai également que ce est ce que j'utilise ... Je suis juste curieux si quelqu'un a utilisé autre chose , et si oui, pourquoi.
EDIT : Juste au cas où quelqu'un trébuche à travers cela, si vous souhaitez utiliser BASE64 pour stocker des données dans un cookie, vous devez utiliser une implémentation modifiée64 . Voir Cette réponse pour la raison pour laquelle.
4 Réponses :
Il était une fois une fois, il y avait UTF-7. Il est officiellement obsolète, mais cela fonctionne toujours comme une ACE (codage compatible ASCII). Maintenant, il y a IDN .
+1 pour indiquer IDN et UTF-7 comme des formes alternatives de rendre UNICODE dans les transports sécurisés ASCII.
base64 est la norme de facto. Utiliser toute autre chose demande des problèmes.
uuencoding me ramène à l'USenet de 1992 :) En fait, uuencoding a été largement supplanté dans Usenet Usage par yenc ( yenc.org ).
yenc. Blimey, qui vous ramène ... Ensuite, vous commencez à penser à Xmodem / Ymodem et à Zmodem pour l'obtenir à partir du serveur Shell à votre machine à domicile ;-)
Pour encoder des valeurs de cookie, vous devez faire attention. Voir cette en Java ).
EDIT: Comme @Paul a souligné utilement, il y a un Version modifiée de la base 64 qui est" URL Safe "(et, je suppose," coffre-casse-coffre "). L'utilisation d'une version modifiée d'un algorithme standard dilue plutôt son charme, pensez-vous.
= est uniquement utilisé pour désigner la fin de la chaîne de base64, de sorte que vous pourriez couper le = , réglez le cookie, puis razetachez le = à nouveau lorsque vous devez le décoder.
En base64, le '=' est utilisé uniquement pour le rembourrage des derniers octets. Vous pouvez soit vous assurer qu'ils ne sont pas émis ou simplement les changent à autre chose (puis de retour)
Vous voudrez peut-être envisager de mettre à jour votre réponse pour faire référence à en.wikipedia.org/wiki/base64 # URL% 5FAPPLICATIONS - une version de base4 spécifiquement destinée à être utilisée dans l'environnement HTTP.
@Paul, merci, édité. @Shoosh, c'est vrai, oui, alors il serait peut-être correct de couper manuellement le trailing = avant de définir le cookie et de le raattachez avant de décoder.
J'ai accepté cette réponse, car même si mon cookie n'était que "un exemple" et non ce que j'utilise réellement cela pour, il existe des informations d'avertissement utiles ici pour les autres. A ajouté à cela, le consensus est définitivement issu de base64, et c'est ce que la réponse recommande.
Merci pour cela, je remarque que lorsque la base64 codant pour un seul symbole de l'euro, je reçois deux = à la fin (GA ==), il serait donc une bonne idée de supprimer tous les fosses = et de le remplacer par le nombre de personnes à remettre - donc ga == se retrouverait dans le cookie comme GA2. Vous devriez utiliser zéro pour no =. Cela semble également être le cas avec un seul caractère de n'importe quoi.
Httpserverutilité.urltokendeCode () est un moyen facile de le faire. Voir: Stackoverflow.com/a/1789179/24315
(Si vous utilisez .NET)
Vous êtes le premier édition, c'est faux. Cette version modifiée de base64 qui utilise l'alphabet URL-Safe est en réalité normalisée.
base64 gagne parce qu'il est si courant que je n'ai pas à vous soucier de rouler mon propre codeur / décodeur. Je n'ai rencontré aucune application dans laquelle je suis inquiet de sauvegarder la bande passante ou des espaces de fil dans des données binaires codées.
Avancé, puisque vous étiez le premier à le dire, dans les commentaires sur la question.
En premier lieu, pourquoi avez-vous besoin de le coder? Êtes-vous lié à un canal ASCII?
BASE64 gagne parce qu'il est si courant que je n'ai pas à craindre de rouler mon propre codeur / décodeur. Je n'ai rencontré aucune application dans laquelle je suis inquiet de sauvegarder la bande passante ou des espaces de fil dans des données binaires codées.
@Paul, je vais aller comme @jball suggéré et à choisir la base64; Mais, étant donné que vous envoyez des données au client et que vous vous attendez à ce que pareil les données à revenir, vous devez être conscient que vous pouvez être altéré au client.
@Rubens - Absolument, si vous deviez implémenter une telle chose dont vous auriez besoin de signer également les données que vous envoyez également, en supposant que ce n'était pas simplement des données que l'utilisateur a entré ... Validez sur le client à coup sûr, mais Ne comptez jamais sur la validation du client!