[PHP-dev 636] Fwd: Re: mb_encode_mimeheader weirdness

[Moriyoshi Koizumi]

小泉です。

このようなメールが来ました。
ドキュメントに補足が必要そうです。
念のため転送しておきます。


Moriyoshi Koizumi <moriyoshi@at.wakwak.com> wrote:
> 
> Date: Fri, 29 Nov 2002 04:25:38 +0900
> From: Moriyoshi Koizumi <moriyoshi@at.wakwak.com>
> X-Mailer: EdMax Ver2.84.1F
> MIME-Version: 1.0
> To: "Adrian Gartland" <adrian.gartland@oregan.net>
> Subject: Re: mb_encode_mimeheader weirdness
> Message-Id: <20021129042538Qy9nft@at.wakwak.com>
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> In-Reply-To: <4.1038486095.17120000@mail.oregan.net>
> References: <4.1038486095.17120000@mail.oregan.net>
> 
> Hi,
> 
> First, thank you for the suggestion.
> 
> I've read through your script, and I wonder why you tried to 
> convert the string encoded in euc-jp into utf-8 encoded one before
> passing it to mb_internal_encoding().
> Because mb_encode_mimeheader() automatically converts the encoding of 
> given strings that are supposed to be the internal encoding to the one 
> specified in the second parameter before composing mime-style strings.
> 
> I mean, the following script
> 
> <?php
>   mb_internal_encoding("euc-jp");
> 
>   $str = "ANATAWA"; // please replace this roma-ji script to
>                        the appropriate hiragana characters,
>                        otherwise no mime encoding will be 
>                        performed.
> 
>   $sMimeEncoded = mb_encode_mimeheader ($str, "utf-8", "B");
> ?>
> 
> should make more sense.
> 
> But as you may think, this behaviour should be explained more explicitly 
> in the documentation. I'm going to add some descriptions.
> 
> Regards,
> Moriyoshi
> 
> 
> "Adrian Gartland" <adrian.gartland@oregan.net> wrote:
> 
> > Hi.
> > I had a revelation. It suddently occured to me that it might
> > be doing more than just encoding it to base64 so I added a
> > 
> > mb_internal_encoding ("utf-8");
> > 
> > before the mb_encode_mimeheader
> > and everything started working. It mentions it uses
> > mb_internal_encoding in the decode php help pages, but
> > not in the encode page. Perhaps someone can put that little
> > note in so other people don't make the same mistake I did.
> > 
> > Ta.
> > Ade.
> > --Forwarded message from "Adrian Gartland" <adrian.gartland@oregan.net>
> > 
> > Hi.
> > There appears to be something broken with the mb_encode_mimeheader.
> > I checked out the latest snap as of yesterday. Although the
> > base64 encoding 'looks' more correct than it did in php-4.2.3,
> > it still doesn't appear to be correct. It could just be
> > my interpretation of how to use the functions though.
> > 
> > I've attached a little test php file, which if you run it
> > from kterm using the cli php interpreter
> > should encode and then decode and print the encoded "anatawa" by using utf-8. Changing the encoding to iso-2022-jp appears
> > to work though. Attempting to use "Q" encoding has the
> > same effect.
> > 
> > Is anyone still working on the mb string issues? I noticed
> > there were people mentioning there were some broken
> > things when checked out the mailing list archive a few
> > weeks back.
> > 
> > Cheers.
> > Ade.
> > -- 
> > Adrian Gartland - Senior Systems Engineer - TV Portal Team
> > Oregan Networks UK Ltd                         Tel: +44  (0) 20 8846 0990
> > The White Building, 52-54 Glentham Road        Fax: +44  (0) 20 8646 0999
> > Barnes, London. SW13 9JJ, United Kingdom       WWW: http://www.oregan.net/
> > 
> > Attachment Removed: <Documents/test.php>
> > Attachment Removed: <Documents/test.php>
> > 
> > -- 
> > Adrian Gartland - Senior Systems Engineer - TV Portal Team
> > Oregan Networks UK Ltd                         Tel: +44  (0) 20 8846 0990
> > The White Building, 52-54 Glentham Road        Fax: +44  (0) 20 8646 0999
> > Barnes, London. SW13 9JJ, United Kingdom       WWW: http://www.oregan.net/