2009-02-20 5 views
3

La spécification IMAP (RFC 2060, 5.1.3 Convention internationale de désignation de boîte aux lettres) décrit comment gérer les caractères non ASCII dans les noms de dossier. Il définit un modifié encodage UTF-7:Codage de chemin de dossier IMAP (IMAP UTF-7) pour .NET?

Par convention, les noms de boîte aux lettres internationale sont spécifiées en utilisant une version modifiée de l'encodage UTF-7 décrit dans [UTF-7]. Le but de ces modifications est de corriger les problèmes suivants avec UTF-7:

  1. UTF-7 utilise le caractère "+" pour le déplacement; ceci est en conflit avec l'utilisation courante de "+" dans les noms de boîtes aux lettres, en particulier USENET noms de groupes de discussion.

  2. Le codage de UTF-7 est BASE64 qui utilise le caractère "/"; ce est en conflit avec l'utilisation de "/" en tant que délimiteur de hiérarchie populaire. UTF-7 interdit l'utilisation non codée de "\"; ceci est en conflit avec l'utilisation de "\" comme un délimiteur de hiérarchie populaire. UTF-7 interdit l'utilisation non codée de "~"; ceci est en conflit avec l'utilisation de "~" dans certains serveurs comme indicateur de répertoire personnel. UTF-7 permet à plusieurs formes alternatives de représenter la même chaîne ; en particulier, les caractères de caractères US-ASCII imprimables peuvent être représentés sous forme codée.

En UTF-7 modifiés, imprimables caractères US-ASCII, sauf pour "&" représentent eux-mêmes; , c'est-à-dire des caractères avec des valeurs d'octet 0x20-0x25 et 0x27-0x7e. Le caractère "&" (0x26) est représenté par la séquence de deux octets "& -".

que "" Tous les autres caractères (octet valeurs 0x00-0x1F, 0x7f-0xff, et tous les octets Unicode 16 bits) sont représentés en base64 modifié, avec une autre modification de [UTF-7] est utilisé à la place de "/".
BASE64 modifié NE DOIT PAS être utilisé pour représenter tout caractère d'impression US-ASCII qui peut se représenter lui-même.

"&" est utilisé pour passer à BASE64 modifié et "-" pour revenir à US-ASCII. Tous les noms commencent en US-ASCII, et DOIVENT se terminer en US-ASCII (c'est-à-dire un nom qui se termine par un octet Unicode DOIT se terminer par un "-").

Avant que je vais commencer à l'appliquer, ma question: est-il un code .NET/bibliothèque là-bas (ou même dans le cadre) qui fait le travail? Je ne pouvais pas trouver les ressources .NET (seulement implementations for other languages/frameworks).

Merci!

+0

J'ai eu le même problème. Détaillé ici .... [http://www.google.com/support/forum/p/gmail/thread?tid=79f75c2d2df9e825&hl=en](http://www.google.com/support/forum/p/ gmail/thread? tid = 79f75c2d2df9e825 & hl = fr) –

Répondre

2

C'est trop spécialisé pour être présent dans un cadre. Il y a peut-être quelque chose sur le codeplex, bien que de nombreuses "implémentations" incomplètes que j'ai vues ne dérangent pas du tout la conversion et transmettent avec bonheur tous les caractères non-us-ascii au serveur IMAP.

Cependant, j'ai mis en œuvre dans le passé et il est vraiment seulement 30 lignes de code. Vous parcourez tous les caractères d'une chaîne et les publiez s'ils se situent entre 0x20 et 0x7e (n'oubliez pas d'ajouter "-" après le "&") sinon collectez tous les non-us-ascii et convertissez-les en UTF7 (ou UTF8 + base64, je ne suis pas tout à fait sûr ici) en remplaçant "/" par ",". De plus, vous devez maintenir "l'état décalé", par ex. si vous êtes en train de coder non-us-ascii ou de nous envoyer des ascii et d'ajouter des jetons de transition "&" et "-" lors du changement d'état.

Questions connexes