UTF8 Settings on dbconnect.php

[Op3r]

Hello

If I change this line

$non_latin = '0'; # set to 1 for UTF rules

from dbconnect.php

to

$non_latin = '1'; # set to 1 for UTF rules

will that affect everything to be UTF 8 compatible?

I was also about to try to do this

mysql_query(’SET CHARACTER SET utf8;’); after the mysql_connect

Any thoughts?

[mflorell]

Those are some first steps, also make sure you set it in the "systems settings" section of the administration pages.

If it's one thing I've learned about UTF-8, it's that it is a pain to get working across all programs and systems. Especially when they were written with the latin characterset in mind like Asterisk was.

[Op3r]

Yeah and I am almost going apecrap on this.

I set everything even when creating the dbase to UTF8 by doing this,

CREATE DATABASE asterisk
DEFAULT CHARACTER SET utf8;

Then I added this to the vicidial sql file

SET NAMES utf8;

Now

Guess what IT WORKED on the mysql side. All I need now is to display on VICIDIAL which I failed cos I am still seeing

# LEAD ID STATUS VENDOR ID LAST AGENT LIST ID PHONE NAME CITY SECURITY LAST CALL
1 1 NEW 617030 10 9890599999 Csaba-���� -Vlad 0000-00-00 00:00:00

Man this is a pain in the bottom.

[kupak]

Is there any way to make vicidial.php showing non latin chars correctly?

[mflorell]

What language encoding is your Apache/PHP install set to?

What language encoding is your MySQL set to?

[kupak]

Apache and php are set to utf8.

I change $non_latin = '1'; in dbconnect.php and i change the vicidial_list table as follows:

CREATE TABLE IF NOT EXISTS `vicidial_list` (
`lead_id` int(9) unsigned NOT NULL auto_increment,
`entry_date` datetime default NULL,
`modify_date` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`status` varchar(6) collate utf8_hungarian_ci default NULL,
`user` varchar(20) collate utf8_hungarian_ci default NULL,
`vendor_lead_code` varchar(20) collate utf8_hungarian_ci default NULL,
`source_id` varchar(6) collate utf8_hungarian_ci default NULL,
`list_id` bigint(14) unsigned default NULL,
`gmt_offset_now` decimal(4,2) default '0.00',
`called_since_last_reset` enum('Y','N','Y1','Y2','Y3','Y4','Y5','Y6','Y7','Y8','Y9','Y10') collate utf8_hungarian_ci default 'N',
`phone_code` varchar(10) collate utf8_hungarian_ci default NULL,
`phone_number` varchar(12) collate utf8_hungarian_ci default NULL,
`title` varchar(4) collate utf8_hungarian_ci default NULL,
`first_name` varchar(30) collate utf8_hungarian_ci default NULL,
`middle_initial` varchar(1) collate utf8_hungarian_ci default NULL,
`last_name` varchar(30) collate utf8_hungarian_ci default NULL,
`address1` varchar(100) collate utf8_hungarian_ci default NULL,
`address2` varchar(100) collate utf8_hungarian_ci default NULL,
`address3` varchar(100) collate utf8_hungarian_ci default NULL,
`city` varchar(50) collate utf8_hungarian_ci default NULL,
`state` varchar(2) collate utf8_hungarian_ci default NULL,
`province` varchar(50) collate utf8_hungarian_ci default NULL,
`postal_code` varchar(10) collate utf8_hungarian_ci default NULL,
`country_code` varchar(3) collate utf8_hungarian_ci default NULL,
`gender` enum('M','F') collate utf8_hungarian_ci default NULL,
`date_of_birth` date default NULL,
`alt_phone` varchar(12) collate utf8_hungarian_ci default NULL,
`email` varchar(70) collate utf8_hungarian_ci default NULL,
`security_phrase` varchar(100) collate utf8_hungarian_ci default NULL,
`comments` varchar(255) collate utf8_hungarian_ci default NULL,
`called_count` smallint(5) unsigned default '0',
PRIMARY KEY (`lead_id`),
KEY `phone_number` (`phone_number`),
KEY `list_id` (`list_id`),
KEY `called_since_last_reset` (`called_since_last_reset`),
KEY `status` (`status`),
KEY `gmt_offset_now` (`gmt_offset_now`),
KEY `postal_code` (`postal_code`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_hungarian_ci AUTO_INCREMENT=82942 ;

[mflorell]

I'm not really sure what the problem could be, but before the next release I will be taking a look at what the guys in Greece did to tailor VICIDIAL to their needs and fix some of the UTF8 issues. You might want to take a look at it too:

http://www.eflo.net/VICIDIALmantis/view.php?id=180

[kupak]

Thanks for yor help!

[pylinuxian]

even though mysql will let you choose any type of coding for your tables or individial columns, i would stick to latin as much as i can, because you don't know when you're going to change your database or worst your queries such as join which will fail if collation is not same for all columns ... also even preconfigured mysql systems like redhat or debian are latin ... besides if you keep latin you will most likely not have problems when publishing data on the web ... or exporting it ...
if your problem is the data you will import to mysql db, you can use /usr/bin/iconv tool on the file before import.

hope this helps

[Op3r]

I made it worked before now Im reinstalling it i dont exactly remember what I did

I really suck at documentation.

anyway here are the steps Im making

1) set the non latin rules at admin -> system settings -> non latin rules =1
2) changed the latin rules to 1 at ../vicidial/dbconnect.php also in ../agc/dbconnect.php
3) set the mysql dbase collation to utf8 and also the tables
4) test leads
if
success
tell client to test
else
see ??????? output check browser settings and set it to utf8
take ritalin

5) ?????
6) profit!!!!

ok i guess it didint work for me but Ill update this once I remember some steps. Im missing something here.

any clue out there?

[Op3r]

Matt

is it ok to put .htaccess file on the folder?

i plan to add this on .htaccess

# This folder does not require access over HTTP
# (the following directive denies access by default)
Order allow,deny
AddDefaultCharset UTF-8

[mflorell]

the 2.0.4.1rc2 release and SVN trunk have taken great steps in UTF-8 compliance. I have even done tests with several different non-latin languages to verify that everything works in the form fields. One other important change is to using the system_settings database table non-latin field as the setting place instead of the dbconnect.php file.

Just make sure that you set the mysql data type to be UTF8 before you create the tables and all should work well. I would also recommend using MySQL 5.0.45 or higher.