ID: 10489
Updated by: vlad
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: IMAP related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Not really a bug. Intended behaviour.

Your $foo is not a valid quoted-printable encoded string (can you get it with 
imap_8bit()? If you can, reopen this bug).

RFC 2045 section 6.7 parts 1 & 2 say that equal sign by itself (ASCII 0x3D) can not be 
represented literally, but onle as encoded "=3D" (hence the '=' at the end of the 
lines is not an equal sign, but a soft break).

Reading below, in note (2):
>An "=" followed by a character that is neither a
>hexadecimal digit (including "abcdef") nor the CR
>character of a CRLF pair is illegal.  This case can be
>the result of US-ASCII text having been included in a
>quoted-printable part of a message without itself
>having been subjected to quoted-printable encoding.  A
>reasonable approach by a robust implementation might be
>to include the "=" character and the following
>character in the decoded data without any
>transformation and, if possible, indicate to the user
>that proper decoding was not possible at this point in
>the data.

Which means that not decoding them at all *might* be a good way to handle that, but 
then it would also be nice to let the user know of the error, which we can't (using 
imap_qprint() at least).


Finally, formal rule for acceptable characters (end of section 6.7 in that RFC) says:


>safe-char := <any octet with decimal value of 33 through
>             60 inclusive, and 62 through 126>
>             ; Characters not listed as "mail-safe" in
>             ; RFC 2049 are also not recommended.
>
>hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
>             ; Octet must be used for characters > 127, =,
>             ; SPACEs or TABs at the ends of lines, and is
>             ; recommended for any character not listed in
>             ; RFC 2049 as "mail-safe".


Notice, that octet *must* be used for '=' sign. In short, you can create a regular 
expression that can handle encoded data that is malformed (yours is not quite 
correct), but that is not the way PHP should behave. On top of that, imap_qprint 
invokes a function in c_client, so if you want to change that behaviour, you need to 
change c_client.

Vlad



Previous Comments:
---------------------------------------------------------------------------

[2001-04-29 06:40:39] [EMAIL PROTECTED]
reclassify

---------------------------------------------------------------------------

[2001-04-25 09:51:13] [EMAIL PROTECTED]
quoted_printable_decode() and imap_qprint() decodes control codes aswell. This, I 
assume, is not supposed to happen.

Also, these functions happily translate anything with two characters after the = sign 
(like =EV in =EVIL), which they shouldn't.

Example:

$foo="This is =00=01 =E4 "=20" =21 =ev =FE string.";
echo "Quoting string "".$foo.""n";
echo "quoted_printable_decode: "".quoted_printable_decode($foo).""n";
echo "preg_replace:            "".preg_replace("/=([2-9A-Fa-f])([0-9A-Fa-f])/e", 
"''.chr(hexdec('\1\2')).''", $foo).""n";

Would result in:
Quoting string "This is =00=01 =E4 =2B "=20" =21 =ev =FE string."
quoted_printable_decode: "This is  ä + " " ! ï þ string."
preg_replace:            "This is =00=01 ä + " " ! =ev þ string."


Am I wrong in assuming that quoted_printable_decode() and imap_qprint() should act as 
my preg_replace line above does?


---------------------------------------------------------------------------



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10489&edit=2


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to