Debian 10
mariadb Ver 15.1 Distrib 10.3.17-MariaDB
Server version: Apache/2.4.38 (Debian)

ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

Hello Max,

I assume you did put "test ß abc" in a host 'Visiable name', right?

Can you take a look if some javascript blocking plugin has been installed for the web browser?

Kindly try on a different web browser as well. Let us know how it goes.

I cannot reproduce the issue while using 4.4.1

search:

Hi Aigars,

I've just tested it with Safari and incognito mode Chrome on OS X and Edge on current Windows 10. The result is the same. Did you copy the ß from my bug report or did you look it up? Actually it's not a Greek Beta, but a German Eszett. Sounds like something Unicode related, doesn't it? The ß is part of the word "Straße" which translates to street. I have some hosts named after their physical location. By the way I also just noticed that the Configuration->Templates and Configuration->Hosts can't search for ß either and search for only the letter ß yields three templates for me, but I have no clue why, as they don't match ß at all...

Even the street can be found:

Please take a look if you have CHARSET=utf8 COLLATE=utf8_bin installed in table level:

show create table hosts\G 

Hi Aigars,

I just tested it with a clean Docker-Zabbix-Appliance. It doesn't work. The screenshot you attached uses a β (Greek Small Letter Beta, U+03B2), which actually works. I just tried it. The problem persists with ß (Latin Small Letter Sharp S, U+00DF): As soon as the Search query contains a ß (Latin Small Letter Sharp S, U+00DF), the search won't return any host, even if there are matching hosts.

> show create table hosts\G
[...]
ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

Some Unicode characters are equivalent to others:

For example, the code point U+006E (the Latin lowercase "n") followed by U+0303 (the combining tilde "◌̃") is defined by Unicode to be canonically equivalent to the single code point U+00F1 (the lowercase letter "ñ" of the Spanish alphabet).

I could not find hard evidence, but since "ß" (U+00DF) is a ligature for "ſs"(U+017F U+0073) these sequences should be equivalent according to Unicode. COLLATE=utf8_bin will obviously treat them as different strings.

select hex('ß'), hex('ſs');

Would be nice if you could find out how host name is stored in the database.

Hi Glebs,

I spawned a new zabbix/zabbix-appliance Docker Container for reproducibility purpose. Then I just added a host with a ß in its Name and tried the search function. Meanwhile I used wireshark to generate a packet trace. I also took a dump of the db inside of the container using `docker container exec -it zabbix mysqldump zabbix > eszett.mysql`.

Best regards,
Max

eszett.mysql

eszett.pcapng

Request sent from your browser to Zabbix frontend:

GET /zabbix.php?action=search&search=test+%C3%9F HTTP/1.1

And here is a piece of $ grep 'INSERT INTO `hosts`' eszett.mysql | xxd:

0000ab50: 2c30 2c30 2c30 2c27 272c 2754 6573 7420  ,0,0,0,'','Test 
0000ab60: c39f 2048 6f73 7427 2c30 2c4e 554c 4c2c  .. Host',0,NULL,

In both cases there is C39F, which is a UTF-8 representation of U+00DF...

So, could you reproduce it with my dump? What information do you need?

[email protected], sorry, I haven't tried. I'm not affiliated with Zabbix, I'm just a passer-by.

I'm sure the dump will help aigars.kadikis to investigate the issue further. You can push Reopen button to let him know that information has been provided and the ticket is no longer in NEED INFO state.

Provided additional info

Hello Max,

I was able to reproduce the problem with MySQL dump eszett.mysql and with docker container:

docker run --name some-zabbix-web-apache-mysql -e DB_SERVER_HOST="10.18.0.5" -e MYSQL_DATABASE="beta" -e MYSQL_USER="zabbix" -e MYSQL_PASSWORD="zabbix" -e PHP_TZ="Europe/Riga" -p 442:80 -d zabbix/zabbix-web-apache-mysql:alpine-4.4.2

Also not working with Nginx container:

docker run --name some-zabbix-web-nginx-mysql -e DB_SERVER_HOST="10.18.0.5" -e MYSQL_DATABASE="beta" -e MYSQL_USER="zabbix" -e MYSQL_PASSWORD="zabbix" -e PHP_TZ="Europe/Riga" -p 442:80 -d zabbix/zabbix-web-nginx-mysql:alpine-4.4.2 

Somehow when Nginx is running locally the result is represented:

search-test-host.mp4

Will continue investigations.

Hi, this still seems to be around in 5.0.

Still present in 6.0 with postgresql with timescaledb and nginx.

Still present in 7.2.9 with PostgreSQL and TimescaleDB.

I investigated this problem a little bit further. What i noticed was, that if i search for "straße" it finds hosts with "strasse".
It seems that the eszett gets converted to "ss" at some point.

After looking a bit into the source code i found out that the PHP function mb_strtoupper() converts the ß to 'SS'. See at: https://github.com/zabbix/zabbix/blob/67493abc16901743ff847c50c9cd8259cc9f6e1e/ui/include/db.inc.php#L426

Looking a the table 'hosts' i saw that there is a column called 'name_upper'. In this column there are still all 'ß' intact.
I don't know where this gets converted to uppercase, but it differs from the mechanism how mb_strtoupper() does it.

I've done some tests with Postgres UPPER() function and Postgres doesn't seem to change the 'ß' into 'SS' and leaves the 'ß' intact.

To solve the problem i suggest to use the UPPER() function from the database instead of mb_strtoupper() and also use the UPPER() function when inserting data into the 'hosts' table.

To make things worse, there is now an uppercase version (since 2017), but it's not widely used yet.

EDIT: On the 'hosts' table a trigger is defined which inserts the uppercase name to 'name_upper' and it uses the Postgres UPPER() function.

I patched it and tested it. See my pull request on Github: https://github.com/zabbix/zabbix/pull/149

I have no idea if it breaks other things, it's just a quick fix and "works for me"™️

Some people more experienced with the source code should look over this.