J'ai cherché le web pendant des jours maintenant, mais je n'arrive pas à trouver une bonne solution à mon problème:
Pour un de mes projets, je cherche un bons analyseurs (léger) MIME. Mon client fournit des fichiers MIME formatés (linéaires, sans hiérarchie) contenant 3-4 "parties". L'application doit être capable de diviser ces parties et de les traiter de manière indépendante.
Fondamentalement, ces fichiers MIME sont comme des messages électroniques bruts, mais sans les en-têtes SMTP. Au lieu de cela, ils commencent par l'en-tête MIME "MIME-VERSION: 1.0" et après que les pièces suivent.
J'utilise C ++ pour l'application, une bibliothèque C ++ est la bienvenue. Une bibliothèque C standard C est également la bienvenue; Mais il devrait correspondre aux critères suivants:
Après des jours de recherche, j'ai trouvé les libs et des raisons suivantes pour lesquelles pas les utiliser:
Je ne veux pas vraiment écrire mon propre analyseur MIME. MIME est tellement répandu que doit être une bibliothèque ouverte pour gérer ce format de fichier de manière saine.
Alors, faites-vous des idées, des suggestions ou des liens?
Merci d'avance!
5 Réponses :
Cela fait longtemps. Donc, je vais juste répondre à ma propre question.
Après avoir passé plus de temps à ce sujet, j'ai fini par écrire ma propre mise en œuvre. MIME est tout à fait simple, et si vous lisez la documentation, vous avez quelque chose de haut et couru en peu de temps.
Cependant, je pense qu'il devrait y avoir quelque chose comme VMIMe, mais open source. Je ne peux pas croire que si peu de gens doivent faire face aux structures MIME car c'est un véritable standard.
@uckelman oui, mais sous la gpl. Cela ne fonctionnera pas pour toutes les situations.
J'ai utilisé avec succès mimetic avec mon MSVC2010. Cela fonctionne également sur Windows. Et a une licence MIT.
GMIMe est un analyseur MIME LGPL écrit en C. Cela dépend de la glib, mais la glib est disponible sous Windows: et 64 bit (et toutes les plates-formes basées sur UNIX, y compris Mac OS X). Il construit également à l'intérieur de Visual Studio Afaict, alors je ne parviens donc pas à voir quel est le problème. Je sais qu'il y a au moins 1 fournisseur de fenêtres commercial livraison libgmime.dll et libglib.dll dans leur produit (Kerio Connect, IIRC). Nokia le transforme même sur certains de leurs téléphones.
Il n'y a vraiment pas d'autre chose qu'un analyseur MIME "léger" si vous vous attendez à ce qu'il fasse quelque chose de plus que des en-têtes fractionnés sur ':' et et font une analyse aléatoire de l'en-tête de type de contenu pour rechercher une chaîne de limites puis continuez à gérer des multiparts non imbriqués (un peu inutile en dehors de l'analyse des réponses HTTP et des messages MIME pré-conserve que vous contrôlez la composition de).
La raison pour laquelle les analyseurs comme GMIME sont si "grands", en ce qui concerne les lignes de code, c'est parce qu'ils sont destinés à des développeurs qui veulent réellement une partie de mime correcte et robuste et une analyse d'en-tête / décodage. Voir ma déclaration sur Décodage des jetons de mots codés RFC2047 pour un Idée sur la manière dont cela peut être complexe (BTW, autre que GMIME et MIMIMIT, je n'ai pas encore trouvé d'analyseurs à mime open source capables de gérer tous les cas de bord discutés dans ma déclaration).
Même avec tout ce traitement supplémentaire robuste, il est toujours aussi rapide ou plus rapide que la plupart des analyseurs de mime "légers" sont susceptibles d'être, notamment en considérant la plupart d'entre eux utilisent une approche de lecture en lecture. J'ai vu des analyseurs MIME "légers" pour analyser 25 Mo de fichiers de messagerie en 2-3 secondes et considérons que être "rapide". My Unité teste pour GMIMe Paysez 2 fichiers MBOX pleins de messages supérieurs à 1,2 Go (oui, gigaoctets) en moins de temps que cela.
Mon point est que "léger" est un critère de connerie par des personnes qui ne savent pas de quoi ils parlent.
Que diriez-vous de juger en fonction de quelque chose de significatif tel que la conformité RFC? Ou par une combinaison de conformité et de performance RFC? De toute façon, GMIMe sortira un gagnant dans une comparaison significative que vous faites.
C'est un rant amusant. Mais je ne peux pas accepter que "léger" est une exigence "de connerie". Libgmime est un poids léger - 142kb selon mon système - et efficace en fonction de vos tests. Certains analyseurs pour d'autres normes atteignent 100 Mo plus. L'ajout d'un analyseur de 100 Mo à un programme de 500 Ko peut ne pas être approprié et utiliser un analyseur qui implémente un sous-ensemble de la norme peut être le bon choix en fonction du contexte .
Ce type d'analyseurs ajoute 100 Mo car ils écrivent en Java, .NET ou une autre langue qui possède sa propre plate-forme et expédiez cette plate-forme complète. Juste pour être ajouté à un programme C. :-) C'est pourquoi toutes les normes doivent avoir une implémentation en C ou à une langue non roulante liée au C.
J'ai également créé une bibliothèque MIME (Windows uniquement) avec support S / MIME. Mais si vous ne voulez pas que les trucs S / MIME, vous pouvez supprimer des fonctions spécifiques à Windows.
http: // www. codeproject.com/articles/1114232/cplusplus-mime-a-simple-single-header-Parser-an
Je suggérerais MIMECPP , une implémentation C ++ de MIME.
Il est très petit, bien encapsulé et facile à utiliser. En fait, le code source contient uniquement 7 fichiers.
La structure MIME est assez simple que quiconque puisse rédiger un analyseur. Typiquement où vous rencontrez des problèmes est avec les détails du message; Langue, codage, etc. En fonction de vos besoins de traitement, vous pouvez écrire votre propre analyseur. Toutefois, si vous devez faire quelque chose de complexe, vous devriez certainement essayer de trouver une bibliothèque qui fait tout le lourd qui vous soulevait.
Mimétique n'est pas basée sur la glib. Est-ce que vous confondez mimétique avec GMIMe?