I've done some more tests: Installed a new VM with mariadb. Checked mariadb configuration: *character-set-server = utf8mb4 collation-server = utf8mb4_general_ci* This is the default charset/collation and should have full compatibility with all special characters
Checked Locale: *LANG=pt_PT.UTF-8 LANGUAGE=pt:pt_BR:en /<-- This is correct on a PT installation/ LC_CTYPE="pt_PT.UTF-8" LC_NUMERIC=pt_PT LC_TIME=pt_PT LC_COLLATE="pt_PT.UTF-8" LC_MONETARY=pt_PT LC_MESSAGES="pt_PT.UTF-8" LC_PAPER=pt_PT LC_NAME=pt_PT LC_ADDRESS=pt_PT LC_TELEPHONE=pt_PT LC_MEASUREMENT=pt_PT LC_IDENTIFICATION=pt_PT LC_ALL=* Then I've created a Koha instance with UNIMARC language *FR* --> Same problem Then I've created a Koha instance with UNIMARC language *EN* --> Same problem I've made a no data dump of DB: mysqldump --no-data [db_name] -u[user] -p[password] > schemafile.sql O the beginning I have this: *Server version 10.0.29-MariaDB-0ubuntu0.16.04.1 SET NAMES utf8mb4 */;* Than all the tables have: */*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; /*!40101 SET character_set_client = @saved_cs_client */;* Example of one table: *-- Table structure for table `import_records` -- DROP TABLE IF EXISTS `import_records`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `import_records` ( `import_record_id` int(11) NOT NULL AUTO_INCREMENT, `import_batch_id` int(11) NOT NULL, `branchcode` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL, `record_sequence` int(11) NOT NULL DEFAULT '0', `upload_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `import_date` date DEFAULT NULL, `marc` longblob NOT NULL, `marcxml` longtext COLLATE utf8_unicode_ci NOT NULL, `marcxml_old` longtext COLLATE utf8_unicode_ci NOT NULL, `record_type` enum('biblio','auth','holdings') COLLATE utf8_unicode_ci NOT NULL DEFAULT 'biblio', `overlay_status` enum('no_match','auto_match','manual_match','match_applied') COLLATE utf8_unicode_ci NOT NULL DEFAULT 'no_match', `status` enum('error','staged','imported','reverted','items_reverted','ignored') COLLATE utf8_unicode_ci NOT NULL DEFAULT 'staged', `import_error` mediumtext COLLATE utf8_unicode_ci, `encoding` varchar(40) COLLATE utf8_unicode_ci NOT NULL DEFAULT '', `z3950random` varchar(40) COLLATE utf8_unicode_ci DEFAULT NULL, PRIMARY KEY (`import_record_id`), KEY `branchcode` (`branchcode`), KEY `batch_sequence` (`import_batch_id`,`record_sequence`), KEY `batch_id_record_type` (`import_batch_id`,`record_type`), CONSTRAINT `import_records_ifbk_1` FOREIGN KEY (`import_batch_id`) REFERENCES `import_batches` (`import_batch_id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; /*!40101 SET character_set_client = @saved_cs_client */;* Can't see any problem here.... ----- Koha version: 16.05.05 - - José Anjos -- View this message in context: http://koha.1045719.n5.nabble.com/Z39-50-encoding-problem-tested-on-2-koha-servers-tp5938540p5939527.html Sent from the Koha-general mailing list archive at Nabble.com. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha