Robert Marchand wrote:
> this will not work without changing current applications.
Now it is not working at all for non-ASCII characters.
Example:
For IMAP folder name "test&WSc-" ("test" + chinese character) current
imap_utf7_decode() returns "testY'"
For IMAP folder name "testY'", current imap_utf7_decode() also returns
"testY'"
So, what you will do in this case?
> The problem is that these function try to encode and decode without
> knowing the charset used.
1) imap_utf7_decode() does not need to know charset of input string,
because input string is encoded in modified UTF7
2) if you specify charset for imap_utf7_decode() output string, what
will you do when IMAP folder name has characters from different charsets
(example: "test&BCQA31kn-" - ASCII, Russian, German, Chinese)?
> As it is now, 8 bit is expected from imap_utf7_decode.
<...skiped...>
> It should really be:
> imap_utf7_utf8_decode
> imap_utf7_utf16_decode (patched version)
> imap_utf8_utf7_encode
> imap_utf16_utf7_encode (patched version)
I think you are confusing "8 bit" and UTF-8.
UTF-8 encoded character is "8 bit" only for ASCII characters. For
non-ASCII characters UTF-8 will be two and more bytes. So,
imap_utf7_decode() != imap_utf7_utf8_decode().
Gamid Isayev
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
