Так что да, обычно это происходит из-за неправильно настроенных баз данных / таблиц / схем, но это новый код, и я хочу убедиться, что он работает правильно, потому что я не уверен на 100%.

На самом деле это проблема UeberDB, но все в порядке. Логика здесь: https://github.com/ether/ueberDB/blob/master/mysql_db.js#L81

Я собираюсь сделать предположение, что ваша база данных Etherpad называется etherpad_lite_db . Если это не так, замените по мере необходимости.

Выполните следующие команды:

mysql -uroot -p

use etherpad_lite_db

SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'etherpad_lite_db';

Скопируйте и вставьте вывод (здесь все в порядке).

Далее ... Скопируйте / вставьте последнюю команду ..

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 = 'etherpad_lite_db' AND T.table_name = 'store';

Скопируйте и вставьте вывод.

Ваши два выхода должны быть

| DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME |
+----------------------------+------------------------+
| utf8mb4                    | utf8mb4_general_ci     |
+----------------------------+------------------------+

а также

| character_set_name |
+--------------------+
| utf8mb4            |
+--------------------+

В противном случае ваша база данных не была настроена должным образом, и определенные символы _ потенциально_ сломают некоторые контактные площадки на вашем экземпляре. Если вы вообще видите там латынь, y'dun облажался, и вам нужно будет запустить эти команды (я думаю [не проверено]) ...

ALTER DATABASE `etherpad_lite_db` CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

а также

ALTER TABLE `store` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

Если они не сработают, дай мне знать.

Вот результат первой команды:

| DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME |
+----------------------------+------------------------+
| utf8mb4                    | utf8mb4_general_ci     |
+----------------------------+------------------------+

Таким было ваше желание

И это уже второе ...

| character_set_name |
+--------------------+
| utf8               |
+--------------------+

Упс…
Что я могу сделать сейчас ?

извините, я немного поторопился, не увидев конца сообщения, сейчас я собираюсь протестировать модификацию базы данных.

Большой! Это сработало.
Больше сообщений в журналах нет

Победить. Приятно видеть, что моя работа / усилия подтверждаются, поэтому спасибо, чувак! :)

Спасибо за эти команды! На одном из моих серверов здесь было "latin1".

Однако я, конечно, никогда не говорил etherpad использовать latin1, почему etherpad не может правильно настроить свою базу данных? Ожидается ли, что каждый администратор должен вручную настроить набор символов для каждой базы данных?

Спасибо за эти команды! На одном из моих серверов здесь было "latin1".

Однако я, конечно, никогда не говорил etherpad использовать latin1, почему etherpad не может правильно настроить свою базу данных? Ожидается ли, что каждый администратор должен вручную настроить набор символов для каждой базы данных?

1. latin1 - это значение по умолчанию в MySQL, по-прежнему, в 2020 году. Это не имеет отношения к Etherpad!
2. Etherpad может правильно настроить саму базу данных, но мы решили не делать этого, потому что мы не хотим принудительно использовать utf8mb4 и др. Для администраторов, поскольку администраторы могут предпочесть другую кодировку. Мы не администраторы баз данных.
3. Администраторы должны создать базу данных, поэтому, когда вы создаете базу данных, вы копируете / вставляете команду alter. Это только для MySQL, если вы используете другую базу данных, это не проблема. Мы не можем обрабатывать каждый пограничный случай каждого развертывания в каждом экземпляре. Существует ограничение на объем нашей работы (который заключается в создании совместного редактора)
4. Etherpad здесь не несет ответственности, UeberDB. Просто эта проблема здесь, потому что Etherpad является крупнейшим пользователем UeberDB. Мы находимся в процессе модернизации UeberDB, и это предупреждение было первым шагом. Мы не можем принудить к изменению из-за пункта 2

Я думаю, что наш подход здесь был сбалансированным и правильным, но я могу понять, если вы немного расстроены, что это не «щелкни и вперед»! <3

Etherpad может правильно настроить саму базу данных, но мы решили не делать этого, потому что мы не хотим принудительно использовать utf8mb4 и др. Для администраторов, поскольку администраторы могут предпочесть другую кодировку. Мы не администраторы баз данных.

Я администратор, но не думаю, что могу решить, с какой кодировкой работает приложение - имеет ли смысл оставлять этот выбор мне? Я ожидал, что неправильный выбор просто сломает приложение. Я не принимаю решения ни о кодировке HTTP-запроса / ответов, ни о кодировке файлов, хранящихся в файловой системе.

Поэтому мне кажется довольно странным, что именно администратор должен определять внутренние детали приложения, такие как кодировка, используемая для базы данных. Вы также не оставляете мне схему базы данных. ;)

latin1 - это значение по умолчанию в MySQL, по-прежнему, в 2020 году. Это не имеет ничего общего с Etherpad!

О, я вижу. Ну это ... грустно, наверное? Похоже, что в наши дни проблема с кодировкой решена переходом на utf8, за исключением mysql ... :(

Так что на данный момент ответ, кажется, будет «да, администраторы должны настроить это сами». Я понимаю, что это ситуация в экосистеме mysql, а не ваша работа, я просто хотел дать некоторую обратную связь с точки зрения пользователя. Наличие ошибки в журналах - отличное начало, но я также не сканирую журналы на наличие ошибок регулярно, просто в журналах слишком много информации.

Возможно, одним из возможных решений было бы для etherpad изменить базу данных по умолчанию по умолчанию, но иметь параметр конфигурации, чтобы отключить это на случай, если администраторы баз данных захотят сделать другой выбор? Это позволило бы избежать использования ножного ружья - я видел эту проблему только по чистой случайности, обычно я бы никогда не заметил. Возможно, я наивен, но я ожидаю, что количество администраторов, которые захотят отменить этот выбор, будет крошечным.

Отметил с благодарностью :)