ZF-9924: Long string to encodeBase64Header with ISO-2022-JP(Japanese JIS) is not correct.
Description
This issue is related to Zend_Mail::_encodeHeader, RFC 2047.
In encodeBase64, chunk_split splits text to expected sized strings. however, to split ISO-2022-JP text, you must add control codes(Escape Seq.) .
Example. A ISO-2022-JP string: [ESC]$B LONG-LONG-LONG-ISO-2022-JP-TEXT [ESC](B if you want to split this. you must add control codes. not correct: 1:[ESC]$B LONG-LONG-LONG-' 2:ISO-2022-JP-TEXT[ESC](B correct: 1:[ESC]$B LONG-LONG-LONG-[ESC](B 2:[ESC]$B ISO-2022-JP-TEXT[ESC](B
*[ESC] is 0x1B. *[ESC]$B is control codes for begin JIS X 0208-1983 *[ESC](B is control codes for begin ASCII
============================================================
RFC 2047: 3. Character sets
Some character sets use code-switching techniques to switch between "ASCII mode" and other modes. If unencoded text in an 'encoded-word' contains a sequence which causes the charset interpreter to switch out of ASCII mode, it MUST contain additional control codes such that ASCII mode is again selected at the end of the 'encoded-word'. (This rule applies separately to each 'encoded-word', including adjacent
'encoded-word's within a single header field.)
============================================================
Zend_Mime::encodeBase64
public static function encodeBase64($str,
$lineLength = self::LINELENGTH,
$lineEnd = self::LINEEND)
{
return rtrim(chunk_split(base64_encode($str), $lineLength, $lineEnd));
Comments
Posted by Pieter Kokx (kokx) on 2010-06-01T12:16:42.000+0000
Re-assigned to the correct person.
Posted by Satoru Yoshida (satoruyoshida) on 2010-06-12T06:53:02.000+0000
Sorry, I have been inactive since last April.