utf-8 error on attendee's addressbook search

I wonder if somebody could help me... I have a contact na

Mon, 17 Mar 2008 10:15:43 -0400

I wonder if somebody could help me... I have a contact named "�rv�ztűrő T�k�rf�r�g�p". Everywhere looks ok but if I make a new event and I assign attendees to it. The addressbook autoexpand looks bad. My contact info: contact.png If I make a new e-mail it's OK: new_mail_ok.png Attendee expand wrong: attendee_wrong.png Attendee wrong: attendee2_wrong.png

> If I make a new e-mail it's OK: new_mail_ok.png

Mon, 17 Mar 2008 10:16:48 -0400

> If I make a new e-mail it's OK: new_mail_ok.png

> Attendee expand wrong: attendee_wrong.png

Mon, 17 Mar 2008 10:17:24 -0400

> Attendee expand wrong: attendee_wrong.png

> Attendee wrong: attendee2_wrong.png

Mon, 17 Mar 2008 10:18:11 -0400

> Attendee wrong: attendee2_wrong.png

Works fine here

Mon, 17 Mar 2008 10:47:39 -0400

Works fine here

> Works fine here I don't know if it matters, I have pgsql

Mon, 17 Mar 2008 11:13:52 -0400

> Works fine here I don't know if it matters, I have pgsql database backend. How can I trace the problem back?

If you know your way around charsets, you should start in kr

Mon, 17 Mar 2008 13:18:54 -0400

If you know your way around charsets, you should start in kronolith/imple.php where the conversion happens from the turba api to json (javascript) code.

Sorry I have not much time these days... :( I found some

Thu, 20 Mar 2008 06:03:03 -0400

Sorry I have not much time these days... :( I found some interesting line but it seems to have no effect to my problem. In kronolith's imle.php I found the line: echo KRONOLITH_Serialize_JSON::encode(String::convertCharset($result, NLS::getCharset(), 'utf-8')); (String::convertCharset($result, NLS::getCharset(), 'utf-8' -->)<-- ); And in IMP's compose.php: $js_code[] = 'var identities = ' . IMP_Serialize_JSON::encode(String::convertCharset($js_ident, NLS::getCharset()), 'utf-8'); (String::convertCharset($js_ident, NLS::getCharset() -->)<-- , 'utf-8'); In kronolith's code, the 'utf-8' is the argument of String::convertCharset but not in IMP's code... Anyway change it in kronolith doesn't do the trick :(

My SQL settings are: $conf['sql']['persistent'] = true;

Thu, 20 Mar 2008 06:06:37 -0400

My SQL settings are: $conf['sql']['persistent'] = true; $conf['sql']['username'] = 'xxxxxxx'; $conf['sql']['password'] = '**********'; $conf['sql']['hostspec'] = 'localhost'; $conf['sql']['port'] = 0; $conf['sql']['protocol'] = 'tcp'; $conf['sql']['database'] = 'hordewebmail2'; $conf['sql']['charset'] = 'utf-8'; $conf['sql']['phptype'] = 'pgsql';

> And in IMP's compose.php: > > $js_code[] = 'var identiti

Thu, 20 Mar 2008 08:11:21 -0400

> And in IMP's compose.php: > > $js_code[] = 'var identities = ' . > IMP_Serialize_JSON::encode(String::convertCharset($js_ident, > NLS::getCharset()), 'utf-8'); Nice catch. It was actually the line in IMP that was wrong.

Do you have the json PHP extension installed by chance? We s

Thu, 20 Mar 2008 08:12:40 -0400

Do you have the json PHP extension installed by chance? We seem to use it in IMP if it's available, but not in Kronolith. This could make the difference.

> Do you have the json PHP extension installed by chance? We

Thu, 20 Mar 2008 10:49:26 -0400

> Do you have the json PHP extension installed by chance? We seem to > use it in IMP if it's available, but not in Kronolith. This could > make the difference. I use this extension: dpkg -s php5-json Package: php5-json Status: install ok installed Installed-Size: 60 Maintainer: Pierre Habouzit Architecture: i386 Source: php-json-ext Version: 1.2.1-3.2 extension=json.so

Which PHP version do you use? See also bug 6457 which might

Fri, 04 Apr 2008 08:29:53 -0400

Which PHP version do you use? See also bug 6457 which might be another symptom of the same root problem.

> Which PHP version do you use? See also bug 6457 which migh

Mon, 07 Apr 2008 02:58:32 -0400

> Which PHP version do you use? See also bug 6457 which might be > another symptom of the same root problem. Package: php5 Status: install ok installed Priority: optional Section: web Installed-Size: 20 Maintainer: Debian PHP Maintainers Architecture: all Version: 5.2.0-8+etch10

> See also bug 6457 which might be > another symptom of th

Mon, 07 Apr 2008 03:02:00 -0400

> See also bug 6457 which might be > another symptom of the same root problem. This is the bug #6457... :)

> This is the bug #6457... :) Eh, bug 5955. :)

Mon, 07 Apr 2008 06:16:58 -0400

> This is the bug #6457... :) Eh, bug 5955. :)

> Eh, bug 5955. :) I have no problem with Subject's in DIMP

Tue, 08 Apr 2008 12:44:02 -0400

> Eh, bug 5955. :) I have no problem with Subject's in DIMP :-o Everything is fine.

It's a symptom of the same PHP problem, not the same Horde p

Wed, 23 Apr 2008 18:01:17 -0400

It's a symptom of the same PHP problem, not the same Horde problem. Address search uses JSON; you probably need a newer PHP json module.

> It's a symptom of the same PHP problem, not the same Horde

Thu, 24 Apr 2008 07:18:50 -0400

> It's a symptom of the same PHP problem, not the same Horde problem. > Address search uses JSON; you probably need a newer PHP json module. But why is it working elsewhere on my system? Look at new_mail_ok.png Or only kronolith use json for address expansion/search and IMP not?

The other way around.

Thu, 24 Apr 2008 23:39:19 -0400

The other way around.

This will fix it: http://lists.horde.org/archives/cvs/Week-

Thu, 24 Apr 2008 23:52:37 -0400

This will fix it: http://lists.horde.org/archives/cvs/Week-of-Mon-20080421/077735.html

> This will fix it: > http://lists.horde.org/archives/cvs/W

Fri, 25 Apr 2008 02:54:36 -0400

> This will fix it: > http://lists.horde.org/archives/cvs/Week-of-Mon-20080421/077735.html It doesn't work for me :( I downloaded the "http://cvs.horde.org/co.php?r=1.1.2.2&p=1&f=kronolith%2Flib%2FJSON.php" and replaced the JSON.php in /kronolith/lib but the result is the same as previous. I deleted my browser's cache restarted the apache deleted the horde cache files... :(

Well, that makes it exactly the same as the IMP code, so, we

Fri, 25 Apr 2008 03:00:21 -0400

Well, that makes it exactly the same as the IMP code, so, we need more information from you on why it doesn't work on your system.

> Well, that makes it exactly the same as the IMP code, so,

Fri, 25 Apr 2008 03:11:57 -0400

> Well, that makes it exactly the same as the IMP code, so, we need > more information from you on why it doesn't work on your system. Who can I help? Who could I make the problem more verbose? Could you send me a code with more logging? What shall I do?