On 9/3/07, Yoshikazu Tsuji yskzt@church.ne.jp wrote:
Hi.
The following code causes Ticket #1484429 (http://trac.roundcube.net/trac.cgi/ticket/1484429). ============================================================= = "program/include/main.inc" function rep_specialchars_output
// convert nbsps back to normal spaces if not html if ($enctype!='html') $str = str_replace(chr(160), ' ', $str); =============================================================
This problem is happened in multibyte enviroment (japanese too). In message list, function rep_specialchars_output garbled UTF-8 message subjects.
Is converting chr(160) to space really necessary ?
This is patch using multi byte functions.
=============================================================== --- main.inc_ 2007-09-03 16:10:32.000000000 +0900 +++ main.inc 2007-09-03 16:22:59.000000000 +0900 @@ -1122,8 +1122,17 @@ $enctype = $GLOBALS['OUTPUT_TYPE'];
// convert nbsps back to normal spaces if not html
- if ($enctype!='html')
- $str = str_replace(chr(160), ' ', $str);
if ($enctype!='html') {
$current_pos = 0;
while(true) {
$found_pos = mb_strpos($str, chr(160), $current_pos);if($found_pos == false)break;$str = mb_substr($str, 0, $found_pos)." ".mb_substr($str, $found_pos1, mb_strlen($str));
$currentpos += 1;}
}
// encode for plaintext if ($enctype=='text')
===============================================================
multibyte looks like the better alternative, especially since we are dealing with people from different countries. And since we are using mb already, I have no issues with this.
Just one thing, can you add this to the trac? Please? :)
Thanks, Till _______________________________________________ List info: http://lists.roundcube.net/dev/