# Umlauts and special characters in icingaweb2 **URL:** \ **Category:** Icinga Web\ **Tags:** mysql, mariadb\ **Created:** [January 8, 2021, 8:26am UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415 "2021-01-08T08:26:08Z")\ **Posts on this page:** 11\ **Page:** 2
**Author:** ![nilmerg](https://community.icinga.com/user_avatar/community.icinga.com/nilmerg/32/277_2.png) [@nilmerg](https://community.icinga.com/u/nilmerg)\ **Post date:** [January 18, 2021, 1:12pm UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/21 "2021-01-18T13:12:45Z")
So, I’ve replaced my MySQL 8 container now with a MariaDB 10.3.25-focal (docker) container. Everything else is the same as before. Umlauts also work pretty fine. So I’d rule that out. Which browser are you using? Have you tried a different one? The `locale` output from above, was that from the machine that’s running the temperature check? If not, please check the locale on this machine as well. ---
**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\ **Post date:** [January 18, 2021, 2:32pm UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/22 "2021-01-18T14:32:05Z")
> [@nilmerg](#): > > Which browser are you using? Have you tried a different one? Chrome, firefox and old IE show the same behavior. Check, DB, webinterface and core are all running on the same VM. ---
**Author:** ![nilmerg](https://community.icinga.com/user_avatar/community.icinga.com/nilmerg/32/277_2.png) [@nilmerg](https://community.icinga.com/u/nilmerg)\ **Post date:** [January 20, 2021, 3:12pm UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/23 "2021-01-20T15:12:00Z")
Well, then I’m out of ideas. 🙄 ---
**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\ **Post date:** [January 21, 2021, 1:13pm UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/24 "2021-01-21T13:13:06Z")
💩 I’ll set up a CentOS and Ubuntu VM for testing, when I find the time and report back 🙂 Thanks for your help so far! ---
**Author:** ![mdicss](https://community.icinga.com/letter_avatar_proxy/v4/letter/m/13edae/32.png) [@mdicss](https://community.icinga.com/u/mdicss)\ **Post date:** [January 25, 2021, 8:31am UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/25 "2021-01-25T08:31:46Z")
For python unicode support see: [Unicode HOWTO — Python 3.9.1 documentation](https://docs.python.org/3/howto/unicode.html#reading-and-writing-unicode-data) You can look at the code of the plugin. Maybe you only have to add the encoding to an open statement: open(‘unicode.txt’, encoding=‘ **utf-8** ’) ---
**Author:** ![staypekos](https://community.icinga.com/user_avatar/community.icinga.com/staypekos/32/3773_2.png) [@staypekos](https://community.icinga.com/u/staypekos)\ **Post date:** [January 25, 2021, 4:46pm UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/26 "2021-01-25T16:46:53Z")
Hmm, everything works good for me ![image](https://community.icinga.com/uploads/default/original/2X/a/a4b8dc75706d12332869d4346551a5df8d4fabe3.png) | ![image](https://community.icinga.com/uploads/default/original/2X/a/ad687522aef850626fd97048cd9f30da2e006941.png) But it seems I’ve the same setup as @nilmerg What do you see in API? I see `"__name":"tt\u00e4esting \u00b0C \u00df\u00d7h\u00e4esting \u00b0C \u00df\u00d7h"` for host called `täesting °C ß×h` which in database is stored as `täesting °C ß×h` > **My settings** > > Stored in database > > ``` > select comment_data from icinga_comments where comment_id = 120; > +------------------------------------------------+ > | comment_data | > +------------------------------------------------+ > | Umlaut ä > some special chars ¤×°C | > +------------------------------------------------+ > > ``` > > MariaDB > > ``` > Server version: 10.3.27-MariaDB-0+deb10u1 Debian 10 > > ``` > > locale > > ``` > LANG=en_US.UTF-8 > LANGUAGE=en_US:en > LC_CTYPE="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_PAPER="en_US.UTF-8" > LC_NAME="en_US.UTF-8" > LC_ADDRESS="en_US.UTF-8" > LC_TELEPHONE="en_US.UTF-8" > LC_MEASUREMENT="en_US.UTF-8" > LC_IDENTIFICATION="en_US.UTF-8" > LC_ALL= > > ``` > > database charsets > > ``` > SELECT default_character_set_name FROM information_schema.SCHEMATA WHERE schema_name = "icinga2"; > | default_character_set_name | > +----------------------------+ > | utf8mb4 | > > MariaDB [(none)]> SELECT CCSA.character_set_name FROM information_schema.`TABLES` T, information_schema.`COLLATION_CHARACTER_SET_APPLICABILITY` CCSA WHERE CCSA.collation_name = T.table_collation AND T.table_schema = "icinga2" AND T.table_name = "icinga_comments"; > | character_set_name | > +--------------------+ > | utf8mb4 | > > MariaDB [(none)]> SELECT character_set_name FROM information_schema.`COLUMNS` WHERE table_schema = "icinga2" AND table_name = "icinga_comments" AND column_name = "comment_data"; > | character_set_name | > +--------------------+ > | latin1 | > > ``` ido settings ``` [icinga_ido] type = "db" db = "mysql" host = "localhost" dbname = "icinga2" username = "***" password = "***" charset = "latin1" use_ssl = "0" ``` If I change `charset = "utf8"` the symbols are displayes wrongly ---
**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\ **Post date:** [January 27, 2021, 11:09am UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/27 "2021-01-27T11:09:02Z")
Just set up icinga on a ubuntu 20.04 test system again. All done with the ansible stuff as well. No problems here, umlauts are displayed correctly. The DB shows them not correctly though: ![image](https://community.icinga.com/uploads/default/original/2X/6/65f4204bcd200d3ffa8c929d05ad0167f40fb774.png) char\_set is latin1 ```auto MariaDB [(none)]> SELECT default_character_set_name FROM information_schema.SCHEMATA WHERE schema_name = "icinga2"; +----------------------------+ | default_character_set_name | +----------------------------+ | latin1 | +----------------------------+ 1 row in set (0.001 sec) MariaDB [(none)]> SELECT CCSA.character_set_name FROM information_schema.`TABLES` T, information_schema.`COLLATION_CHARACTER_SET_APPLICABILITY` CCSA WHERE CCSA.collation_name = T.table_collation AND T.table_schema = "icinga2" AND T.table_name = "icinga_comments"; +--------------------+ | character_set_name | +--------------------+ | latin1 | +--------------------+ 1 row in set (0.002 sec) MariaDB [(none)]> SELECT character_set_name FROM information_schema.`COLUMNS` WHERE table_schema = "icinga2" AND table_name = "icinga_comments" AND column_name = "comment_data"; +--------------------+ | character_set_name | +--------------------+ | latin1 | +--------------------+ 1 row in set (0.001 sec) ``` will keep this in mind for future setups, but I don’t know why/how this is happening. Maybe on the problematic VM something went wrong during the icinga setup or something is wrong with the VM setup itself (was not setup be me, so I don’t know the exact settings) ---
**Author:** ![nilmerg](https://community.icinga.com/user_avatar/community.icinga.com/nilmerg/32/277_2.png) [@nilmerg](https://community.icinga.com/u/nilmerg)\ **Post date:** [January 27, 2021, 12:01pm UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/28 "2021-01-27T12:01:26Z")
> [@log1c](#): > > No problems here, umlauts are displayed correctly. Glad to hear! > [@log1c](#): > > The DB shows them not correctly though: That’s to be expected. The comment is now with `utf8` encoded, but the database tries to interpret it as `latin1`. Try `SET NAMES latin1` before you run your query. That’s the same what Icinga Web 2 does and why it’s necessary to set the resource’s charset to `latin1`. This way mysql won’t try to transcode the comment and you’ll get the raw (correct) value. ---
**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\ **Post date:** [February 17, 2021, 12:01pm UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/29 "2021-02-17T12:01:31Z")
@nilmerg sorry for pulling this up again 😅 I just experienced a strange behavior. System on Ubuntu 20.04.2. when having “latin1” in charset option of resource: ![image](https://community.icinga.com/uploads/default/original/2X/b/b4d075884d75656e8f70b574a20a19089e7dbc93.png) when removing “latin1” for charset option ![image](https://community.icinga.com/uploads/default/original/2X/f/f298364ef55e7a10906a3eadfc0ee1f63b38b460.png) As I am using Graphite I need to set “latin1” in the charset option, otherwise the graphs are not displayed. Setup was create DBs with default MariaDB settings and them schema import. ```auto MariaDB [(none)]> SELECT default_character_set_name FROM information_schema.SCHEMATA WHERE schema_name = "icinga2"; +----------------------------+ | default_character_set_name | +----------------------------+ | utf8mb4 | +----------------------------+ 1 row in set (0.001 sec) MariaDB [(none)]> SELECT CCSA.character_set_name FROM information_schema.`TABLES` T, information_schema.`COLLATION_CHARACTER_SET_APPLICABILITY` CCSA WHERE CCSA.collation_name = T.table_collation AND T.table_schema = "icinga2" AND T.table_name = "icinga_comments"; +--------------------+ | character_set_name | +--------------------+ | utf8mb4 | +--------------------+ 1 row in set (0.001 sec) MariaDB [(none)]> SELECT character_set_name FROM information_schema.`COLUMNS` WHERE table_schema = "icinga2" AND table_name = "icinga_comments" AND column_name = "comment_data"; +--------------------+ | character_set_name | +--------------------+ | latin1 | +--------------------+ 1 row in set (0.001 sec) ``` Can you make any sense of that? ---
**Author:** ![nilmerg](https://community.icinga.com/user_avatar/community.icinga.com/nilmerg/32/277_2.png) [@nilmerg](https://community.icinga.com/u/nilmerg)\ **Post date:** [February 17, 2021, 1:10pm UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/30 "2021-02-17T13:10:19Z")
Not really. But as we experienced it before, Icinga 2 just accepts any and all encodings and puts them straight into the database no matter its charset. Icinga Web 2 just reads it as utf-8. If the real encoding is a subset of utf-8, all is fine albeit it not being utf-8. If it overlaps with another encoding not compatible with utf-8 (e.g. latin1 (aka ISO-8859-1, cp1252)) … yes, really, latin1, as mentioned previously, that config option only prevents transcoding … it will fail badly. Or may produce weird results because a code point of such an encoding is indeed part of utf-8, but will represent an entirely different glyph. (char) So, with that said, make sure your check plugins all accept utf-8 (input) and put out utf-8 (output). ---
**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\ **Post date:** [February 17, 2021, 2:38pm UTC](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415/31 "2021-02-17T14:38:14Z")
Thanks for the quick feedback. Seems like I was to fixed on the “latin1”. Putting utf8 into the charset option solves both problems: - the umlauts and special characters are displayed - the graphite graphs are displayed [Previous page](https://community.icinga.com/t/umlauts-and-special-characters-in-icingaweb2/6415.md?page=1)