Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23614
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: lists@block-online.eu
To: internals@lists.php.net
Date: Mon, 22 May 2006 14:37:56 +0200
User-Agent: KMail/1.7.1
References: <200605201918.29524.lists@block-online.eu> <Pine.LNX.4.62.0605210146080.15309@localhost>
In-Reply-To: <Pine.LNX.4.62.0605210146080.15309@localhost>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200605221437.56905.lists@block-online.eu>
Subject: Re: [PHP-DEV] iconv_mime_encoding
From: lists@block-online.eu (Oliver Block)

Am Sonntag, 21. Mai 2006 01:46 schrieb Derick Rethans:
> It doesn't, but changing it now breaks BC.

Hi Derrick,

if you look into RFC4021 there are about 70 header fields, which could be 
created comfortably with the function iconv_mime_encode.

On the other hand there are fields that can be not created comfortably by it 
because of description in my initial mail.

An extension of that function might be a good solution:

I tested supplying a "" for value of field_name which results in

: field body content

If the function would be changed so that one could just supply "" as 
field_name and it would not prepend the field_name and the ": " to the 
field_value the problem would not occur anymore. On the other hand someone 
could have implemented a workaround that split(": ", ...) the return 
value ....

So an additional function like iconv_mime_encoding_value might be a better 
solution which would act like iconv_mime_encoding without requiring (and 
returning) the field_name.

Best Regards,

Oliver