Wrong character encoding on extension button labels

farfrostfarfrost
in Support
Hi,

I install FOP2 in FreePBX Distro FreePBX-1.1005.210.58-i386-Full
and have the problem opposite to the one described in View Post 235/.
I use labels in russian. I convert all the databases and tables in mysql to utf8_general_ci. In mysql tables and FreePBX web panels and in Other > FOP2 Buttons all displayed correctly. The character encoding on queues button label in FOP2 displayed correctly too, but the character encoding on extension button labels is incorrect. This looks like ??????????
I guess that somewhere in the script I need to specify the correct encoding utf-8 when reading data. But where?
I also read the FAQ "...but be sure to save the buttonfile as utf-8. If you fail to do so you might have troubles login in."
I don't have buttons.cfg in /usr/local/fop2. I guess autoconfig performed? What file I need to save as utf-8?

I need any help.
Thanks.

Comments

  • nicolasnicolas
    Hi,

    Try to modify autoconfig-buttons-freepbx.sh and add a "SET NAMES UTF8;" before the query to get the button configuration, something like:
    "SET NAMES utf8; SELECT device AS channel,type,if(type<>'trunk',exten,'') AS extension,\
  • farfrostfarfrost
    Hi,

    Try to modify autoconfig-buttons-freepbx.sh and add a "SET NAMES UTF8;" before the query to get the button configuration, something like:
    "SET NAMES utf8; SELECT device AS channel,type,if(type<>'trunk',exten,'') AS extension,\
    Thank you, Nicolás

    This solved the problem. :P It might be worth to add this to a FAQ "Can I use international characters as button labels?"

    Best regards
  • nicolasnicolas
    The next release will include the set names in all queries by default. The FAQ has an entry, but the autoconfig scripts do not output utf8 if mysql is no set to that encoding by default... so a fix was requied on the autoconf scripts.

    Best regards,
  • farfrostfarfrost
    Yes, it turned out that the problem is more extensive. When I make a FOP2 Phonebook as a CLID Lookup Source[/url:36st5zok] the dynamically display names on the queue and extensions buttons are in the wrong encoding and these data in the wrong encoding are recorded to the cdr table. I modify the query in the Query section of FreePBX web admin CallerID Lookup Source adding a "SET NAMES UTF8;", but with no effect. Can you tell me in which scripts I still fix queries :roll: until there was a new release.

    Best regards,
  • nicolasnicolas
    What is the default encoding for the visual_phonebook table in your mysql setup? FreePBX is FreePBX, not sure how it handles encoding, much less a sip phone.

    Try to enforce utf8 in your mysql:

    Add in /etc/my.cnf

    character-set-server=utf8
    init-connect='set charset utf8; SET NAMES utf8;'

    Then set DB to use UTF8:

    ALTER TABLE visual_phonebook DEFAULT CHARSET=utf8;
  • farfrostfarfrost
    Hi, Nicolás

    Thanks for pointing me in the right way.
    All the databases and tables in mysql are in utf8. But the output of these сommands shows the following:
    mysql> show variables like 'char%';
    +
    +
    +
    | Variable_name | Value |
    +
    +
    +
    | character_set_client | latin1 |
    | character_set_connection | latin1 |
    | character_set_database | utf8 |
    | character_set_filesystem | binary |
    | character_set_results | latin1 |
    | character_set_server | utf8 |
    | character_set_system | utf8 |
    | character_sets_dir | /usr/share/mysql/charsets/ |
    +
    +
    +
    8 rows in set (0.00 sec)

    mysql> show variables like '%collation%';
    +
    +
    +
    | Variable_name | Value |
    +
    +
    +
    | collation_connection | latin1_swedish_ci |
    | collation_database | utf8_general_ci |
    | collation_server | utf8_general_ci |
    +
    +
    +
    3 rows in set (0.00 sec)

    Next I add the following lines to the file /etc/my.cnf:
    [mysqld]
    init_connect='SET NAMES utf8; SET collation_connection = utf8_general_ci;'
    default-character-set=utf8
    character-set-server=utf8
    collation-server=utf8_general_ci
    skip-character-set-client-handshake
    [client]
    default-character-set=utf8

    After execution the сommand /etc/init.d/mysqld restart
    the output of the сommands shows the following:
    mysql> show variables like 'char%';
    +
    +
    +
    | Variable_name | Value |
    +
    +
    +
    | character_set_client | utf8 |
    | character_set_connection | utf8 |
    | character_set_database | utf8 |
    | character_set_filesystem | binary |
    | character_set_results | utf8 |
    | character_set_server | utf8 |
    | character_set_system | utf8 |
    | character_sets_dir | /usr/share/mysql/charsets/ |
    +
    +
    +
    8 rows in set (0.00 sec)

    mysql> show variables like '%collation%';
    +
    +
    +
    | Variable_name | Value |
    +
    +
    +
    | collation_connection | utf8_general_ci |
    | collation_database | utf8_general_ci |
    | collation_server | utf8_general_ci |
    +
    +
    +
    3 rows in set (0.00 sec)

    Thus the problems with wrong encoding were resolved. The problem is with MySQL FreePBX encoding but not in FOP2.
    P.S. I also add the line
    charset=utf8
    to the /etc/asterisk/cdr_mysql.conf file for correct names encoding in CDR table.

    Best regards
  • rampatterrampatter
    A character encoding tells the computer how to interpret raw zeroes and ones into real characters. It usually does this by pairing numbers with characters. Words and sentences in text are created from characters and these characters are grouped into a character set. There are many different types of character encoding floating around at present, but the ones we deal most frequently with are ASCII, 8-bit encoding, and Unicode-based encoding. A character encoding tells the computer how to interpret raw zeroes and ones into real characters. It usually does this by pairing numbers with characters. Words and sentences in text are created from characters and these characters are grouped into a character set. There are many different types of character encoding floating around at present, but the ones we deal most frequently with are ASCII, 8-bit encoding, and Unicode-based encoding.
Sign In or Register to comment.

© Asternic Corp 2024