yet another mailparse extension

Hi all About a year ago, I've written a parser too. I'v planed to first do further work on it before I share it with you. Unfortunately, I've never had time to 'complete' the extension. As far as I remember it compiled fine and worked quite fine apart from the kown bugs (see ext/msg/KNOWN_BUGS in the tarball). I now desided to give it away anyway because I haven't any clue when (if ever) I will be able to further work on the extension. May the php developer community make the best of it! -Jade. extension facts: ---------------- required libs: none based on: - / written from scratch interdepends: none interrecommends: ext/recode http://nns.ch/ext_msg_a20000629.tar.gz (~ 13kB) relateted mails: ---------------- Date: Mon, 3 Jul 2000 07:29:43 +0200 From: Jade Nicoletti <nicoletti@nns.ch> To: Chuck Hagenbuch <chagenbu@wso.williams.edu> Subject: MIME header parser Hi chunk, I just wanted you to know, that I'm implementing a MIME header parser as a php extension in C/Yacc/Lex. You once mentioned in the PEAR mailing list that you want to do that as a PEAR module, but i think that the performence would be quite poor compared to my extension. So, before you start working on it, drop me a mail and ask me for the state. It currently only parses address lists, conforming to rfc822 and rfc2047. There's also a loose address list parser which lets you handle user input (from form data) on witch you can have a callback function or object for auto- completing (address book lookups, default host appendments, ...). I plan to make it rfc2303 and rfc2231 compatible und to parse entire MIME headers. -Jade. PS: my rfc2047 adrlist parser (including decoding+recoding) is faster than the simple c-client rfc822 paser :)) plus, it follows the RFCs more strictly :) From: Jade Nicoletti <nicoletti@nns.ch> To: Chuck Hagenbuch <chagenbu@wso.williams.edu> Subject: Re: MIME header parser On Wed, Jul 05, 2000 at 04:28:46PM -0400, Chuck Hagenbuch wrote: [snipped] > Are you handling i18n stuff, too (charsets, etc)? If so, how? In the current state, i'm handling i18n stuff only, when you configure php --with-recode. I then recode everything that is not limited anyway to us-ascii to a `super charset', that the user (php developer) may choose (preferably a unicode charset, by default it is UTF-8 now). This meens, if you want your webmail application to handle i18n stuff, you should generate the pages witch display mails, mail indices, etc in unicode and not in ISO-8859-1 or even worse in us-ascii. This is a good thing anyway; UTF-8 will become the default web charset. I'll probably have to enable i18n handling even if --with-recode is not specified at compile time, so that one can dynamicly load librecode and have it's benefits. -Jade. -- =============================================================================== Jade Nicoletti Nicoletti Net Services Tel. 01 240 4774 Geschäftsleitung Postfach 2519 Fax 01 240 4775 System-Administration 8021 Zürich ============================================[ Weitere Infos: http://nns.ch/ ]==