\Drupal::entityTypeManager()->getStorage('user_role')->load() can't load non-english string

@Lawxen,
The issue is not because of the Drupal core. It was a common database error in the Chinese language. Please refer to the SQL Collation utf8_general_ci settings.

I have resolved the issue by running the below queries into the Database server.

ALTER DATABASE DBNAME CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE config CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

After running this script, I was able to successfully run the Chinese words.

@arunkumark thanks for the review:
I retest the problem:
1. Create db by official drupal doc : create-a-database →
2. Install Drupal throug browser /core/install.php
3. Check that the config table's CHARACTER is utf8mb4 and COLLATE is utf8mb4_general_ci
4. The problem still exist.
5. Has confirm that the problem didn't exist on Drupal8 and Drupal9
So this is still a bug of core.

No matter which command be used to create database;

CREATE DATABASE d10 CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE d10 CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE DATABASE d10 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

The site install will install all tables with utf8mb4 and utf8mb4_general_ci.

And execute command from arunkumark on #4 🐛 \Drupal::entityTypeManager()->getStorage('user_role')->load() can't load non-english string Active
ALTER TABLE config CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

\Drupal::entityTypeManager()->getStorage('user_role')->load("中文");

can be executed successfully.

This is wiard, But comfim this is a regression of Drupal 10.

Those character sets and collations are defaults for new tables. Drupal may deliberately set other character sets and collations, like ascii_general_ci, for some tables. I think that is the case here, and with some queries, when joining tables with differing collations, this can occur.

I can also confirm that this happens for Turkish characters.

All of my tables and database are collated as utf8mb4_general_ci

Just came here from: https://www.drupal.org/project/webform/issues/3415445 🐛 Search Chinese in /admin/structure/webform cause error: Illegal mix of collations Closed: duplicate

Workaround where no collation changes are required.

https://www.drupal.org/files/issues/2024-02-26/3415478-cant-load-non-eng... →
Created this for workaround where no collation changes are required.

The site install will install all tables with utf8mb4 and utf8mb4_general_ci.

That is true for tables, but not for columns.

This is the config table schema:

CREATE TABLE `config` (
  `collection` varchar(255) CHARACTER SET ascii NOT NULL DEFAULT '' COMMENT 'Primary Key: Config object collection.',
  `name` varchar(255) CHARACTER SET ascii NOT NULL DEFAULT '' COMMENT 'Primary Key: Config object name.',
  `data` longblob COMMENT 'A serialized configuration object data.'
)

It is impossible to query the collection or name columns with non-ASCII characters, for example, "€".

The table has had this design since #1923406: Use ASCII character set on alphanumeric fields so we can index all 255 characters → , which is from eight years ago. If this is a regression, in which version of Drupal did this work?

in which version of Drupal did this work?

I can't remember the exact version.
When the issue is created, webform+Drupal9 works. webform+Drupal10 didn't work.

This can’t be fixed as such. Webform just has to stop calling this function in that way.

See 📌 Throw an understandable exception when there is an attempt to load config entities with disallowed characters Needs work for the ideas on working toward clearing up error messaging.

There is now a more comprehensible error message that is at 'Needs review' stage of the related issue 3475540. I have tested this issue by using drush at the command line:

ddev drush ev "\Drupal::entityTypeManager()->getStorage('user_role')->load('8îïîö');"

This command triggers the same comprehensible error message as when reproducing issue 3475540. But I have adjusted the message that that it fixes this ticket. It now refers to command line input in addition to browser input.

Failing functional test has been created. The test tests creating a user role entity with invalid characters. This is not an indentical reproduction of the issue, but once the fix from 3475540 is applied this test should pass. That should mean that entity CRUD involving user role entities in this issue together with the node type entity in 3475540 are validated without touching the database and an understandable but generically worded InvalidArgumentException is returned.

@cilefen Regarding #12, I am seeing a different CREATE TABLE schema in 11.x:

config | CREATE TABLE `config` (
`collection` varchar(255) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL DEFAULT '' COMMENT 'Primary Key: Config object collection.',
`name` varchar(255) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL DEFAULT '' COMMENT 'Primary Key: Config object name.',

This part of the configuration of the 'collection' and 'name' columns is different:
COLLATE ascii_general_ci