[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: subject decoding

From: Sam Roberts
Subject: Re: subject decoding
Date: Tue, 12 Nov 2002 16:37:15 -0500
User-agent: Mutt/1.5.0i

Wrote Frederic Gobry <address@hidden>, on Tue, Nov 12, 2002 at 10:54:08AM +0100:
> > If you want to propose something, go right ahead.
> I think providing a simple string encode/decode api is the first step,
> as it won't involve digging too deeply in the existing code, like
> int rfc2047_decode_word (char ** result, const char * text);

This would be a good way, as long as it takes more than a word, I
think it needs to take an entire header field value.

So, you can call header_aget_field_value(), then, if you need to
display it, you could call:

rfc2047_decode_field () on the value.

As far as I can see, it is not possible for header_aget_field_value() to
do it internally, because it involves converting from the MIME character
set that the field value is encoded in to the character set used by
whatever display device the application is using, and how is it supposed
to know that? If it was sieve, for example, it shouldn't be converted
to the terminal's character set, but to utf-8, because all sieve
field comparisons are supposed to be made against headers that have
been canonicalized to utf-8.

Also, only some headers are allowed to have MIME encoded multi-lingual
tokens, but people can add headers and define them as being in that 
set. The header_() API would have to know not only the character
encoding you want, but also whether each specific header field is
allowed to be 2047 encoded.

> int rfc2047_encode_word (char ** result, 
>                          const char * text, 
>                          const char * encoding);
> In a second phase, these operations could be automatically performed
> where necessary, but this will require more work...

Probably Sergey and others writing applications could use a set of
header_aget_2047_field_value() functions that took an extra arg, the
character set they want the output in, and that would be a simple
wrapper that called the old function, then your conversion function.
Applications that are unconcerned with displaying the header can just
call the old header_aget_field_value() and get the actual field value.

Same for encoding.

Anyhow, those were my thoughts.


> > If you want to give code, it will have to be under LGPL for the
> > library and GPL for any other parts.
> Yep. As it is a GNU projet, are there some additional requirements
> (like giving the rights back to the FSF) ?
> Do you prefer patches, or direct cvs use (I'm registered at savannah)?
> Frédéric
> -- 
> Frédéric Gobry    SMARTDATA             
>       ---         http://www.smartdata.ch
> Software Engineer Lausanne - Switzerland
>                   +41 21 693 84 98

Sam Roberts <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]