I'm using PHP 5.2.0.
The following patch fixes the problem:
- Code: Select all
--- ocs-2.0.0-1/classes/form/Form.inc.php.unicode 2007-05-10 20:20:45.000000000 -0700
+++ ocs-2.0.0-1/classes/form/Form.inc.php 2007-10-10 02:05:04.675730000 -0700
@@ -97,15 +97,8 @@
// utf8_decode to work in latin-1 (information may be lost)
import('core.Transcoder');
$trans =& new Transcoder('CP1252', 'UTF-8');
$value = $trans->trans($value);
-
- } elseif ($value !== utf8_decode($value) && $value !== utf8_encode($value)) {
- // string is not within utf-8(?)
- // normalize to ASCII (lowest common encoding) - information will be lost
- import('core.Transcoder');
- $trans =& new Transcoder('UTF-8', 'ASCII');
- $value = $trans->trans($value);
}
}
$this->_data[$key] = $value;
}
I believe that any non-ASCII input would trigger the elseif clause, which mangles the data into ASCII. I don't understand how the CP1252 case is ever encountered, since the charset choices during installation are ISO-8859-1 and UTF-8. Perhaps the if-clause should be removed as well.
I have tested this patch -- it works whether config.inc.php contains
- Code: Select all
[i18n]
client_charset = iso-8859-1
connection_charset = Off
database_charset = Off
or
- Code: Select all
[i18n]
client_charset = utf-8
connection_charset = utf8
database_charset = utf8