Hi,
which sense does it make if a function like iconv_mime_encoding() requires an
field_name as first argument?
If you use imap_mail() to send the message, you are required to supply a
subject argument. If you supply the return value of iconv_mime_encoding()
your will get a subject like that (after decoding by receiver):
Subject: Subject: Hello
Additionally I'd like to say that this iconv_mime_encoding does convert the
header without any testing if it is required to encode the string. It will
also encode an US-ASCII string.
Best Regards,
Oliver
which sense does it make if a function like iconv_mime_encoding() requires an
field_name as first argument?
It doesn't, but changing it now breaks BC.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
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