"Введённое значение содержит символы, такие как эмодзи, которые не разрешены"

Это вот что такое?? Как разрешить эмодзи?

10 часов назад, seobot сказал:

"Введённое значение содержит символы, такие как эмодзи, которые не разрешены"

Это вот что такое?? Как разрешить эмодзи?

Сменить кодировку БД на UTF-8 MB4

4 часа назад, IAF сказал:

Сменить кодировку БД на UTF-8 MB4

Так там не только сменой кодировкой дело ограничивается. Хотелось бы более подробной инструкцией, как грамотно перейти на UTF-8 MB4, и будет ли это нормально функционировать на IPS.

47 минут назад, ZeRik сказал:

Так там не только сменой кодировкой дело ограничивается. Хотелось бы более подробной инструкцией, как грамотно перейти на UTF-8 MB4, и будет ли это нормально функционировать на IPS.

Нормально функционировать будет, т.к. инсталлер при установке предлагает UTF8MB4.

Вам нужно просто сменить кодировку всех таблиц и сопоставление БД на utf8mb4_unicode_ci.

сейчас стоит кодировка везде utf8_generic_ci

Как сконвертировать их?

ALTER TABLE table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

 

6 часов назад, seobot сказал:

utf8_generic_ci

@seobot Удалось поменять на?

utf8mb4_unicode_ci

13 часов назад, IAF сказал:

Нормально функционировать будет, т.к. инсталлер при установке предлагает UTF8MB4.

Вам нужно просто сменить кодировку всех таблиц и сопоставление БД на utf8mb4_unicode_ci.

А в конфигах IPS ничего править не нужно? + в UTF8MB4 длина столбцов должна быть меньше, никакие столбцы править не нужно?

3 часа назад, ZeRik сказал:

А в конфигах IPS ничего править не нужно? + в UTF8MB4 длина столбцов должна быть меньше, никакие столбцы править не нужно?

Насколько я знаю - нет.

Просто сделайте дамп БД и экспериментируйте.

7 часов назад, Sipsb сказал:

@seobot Удалось поменять на?

utf8mb4_unicode_ci

Да

1 час назад, IAF сказал:

Насколько я знаю - нет.

Просто сделайте дамп БД и экспериментируйте.

Собственно, как я и говорил. При попытке сменить кодировку некоторых таблиц, получаю ошибку - #1071 - Specified key was too long; max key length is 767 bytes

Странно, что IPS не опубликовали никакой документации по этому поводу.

ATER TABLE table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Выполнить SQL-запрос к базе данных? Что-то у меня не получилось.

26 минут назад, Sipsb сказал:

ATER TABLE table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Выполнить SQL-запрос к базе данных? Что-то у меня не получилось.

Ковентировать по одной таблице долго и не практично. Выполняем сначала данный SQL запрос -

SELECT CONCAT('ALTER TABLE `', t.`TABLE_SCHEMA`, '`.`', t.`TABLE_NAME`, '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;') as sqlcode
  FROM `information_schema`.`TABLES` t
WHERE 1
  AND t.`TABLE_SCHEMA` = 'db_name'
ORDER BY 1

db_name - имя вашей базы данных.

ОН автоматически выдаст запросы на все таблицы. Вы копируете - и выполняете один большой SQL запрос.

Только это все бесполезно, на некоторых таблицах вылетит ошибка - #1071 - Specified key was too long; max key length is 767 bytes, т.к. максимальная длина символа в utf8mb4 равна 4, а не 3. Индексы типа VARCHAR(255) нужно менять на VARCHAR(191), и т.д..

В принципе, всё удалось) Выдал 16 ошибок, ручками поправил с VARCHAR(255) на VARCHAR(191).

 

5 часов назад, ZeRik сказал:

в UTF8MB4 длина столбцов должна быть меньше, никакие столбцы править не нужно?

Это не длина столбцов должна быть меньше, это размер индекса не должен превышать 767 байт. Это немного разные вещи, потому что размер индексу можно задать такой, чтобы он умещался в это количество байтов. Поэтому IPS использует индексы KEY `name_index` (`name`(191))

 

6 часов назад, ZeRik сказал:

Индексы типа VARCHAR(255) нужно менять на VARCHAR(191), и т.д..

Именно что индексы, а не column definition.  Индексы полей размером varchar(255) в IPS  использует только 191 символов. Вот вы посоветовали поменять varchar(255) на 191 и неизвестно что Sipsb поменял размер столбца или размер индекса...

 

О блин!!! Так как быть? Может вернуть всё обратно, пока не поздно =)

Делал так, в проблемных местах заходил в Индексы и менял всё что VARCHAR(255) на VARCHAR(191), правильно ли это?

Если в индексы то наверное правильно.

А почему там 255 и в каких полях?
 

Откатил всё обратно! Вот, что было эти поля я поменял на VARCHAR(191)

Не знаю что меняли, так как я не пользуюсь данной тулзой. Если это было в опции индексы, то логически можно предположить что изменения касались индекса. Чтобы это проверить - после изменения тип в данной колонки должен остаться прежний, либо посмотрев структуру таблицы в разделе индексы или запросом SHOW CREATE TABLE.
Некоторые индексы действительно имеют размер больше чем 191, потому что в myisam максимальный размер индекса 1000byte по сравнению с innoDB.

9 часов назад, Гость Mr.Hack сказал:

 

Это не длина столбцов должна быть меньше, это размер индекса не должен превышать 767 байт. Это немного разные вещи, потому что размер индексу можно задать такой, чтобы он умещался в это количество байтов. Поэтому IPS использует индексы KEY `name_index` (`name`(191))

 

Именно что индексы, а не column definition.  Индексы полей размером varchar(255) в IPS  использует только 191 символов. Вот вы посоветовали поменять varchar(255) на 191 и неизвестно что Sipsb поменял размер столбца или размер индекса...

 

Я имел ввиду максимальную длину символа, которая в utf8mb4 имеет размер 4 байта, а не 3. В следствии чего длина столбцов и ключей индексов становится меньше.

На конкретном примере: есть столбец типа TINYTEXT (255), который вместит в себя 85 3-х байтовых символов (85 х 3 = 255), или 63 4-х байтовых символов ( 64 х 4 = 255), абсолютно тоже самое и для ключей индексов - в 3-байтовых символов выходит 255, а в 4-байтовых символов 191 (т.к. в InnoDB максимальная длина индекса = 767 байт).

Поэтому, все, что я говорил до этого - абсолютно верно. Если не поняли суть того, о чем я говорю - не нужно поправлять и путать человека.

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

Размер индекса становится не меньше а БОЛЬШЕ, потому что для хранения индекса mysql выделяет на один символ 4 байта. Для поле varchar(255) в 255 символов это будет составлять 255 * 4 = 1020 байт, что намного больше максимального размера по умолчанию в innodb - 767 байт (это значение можно увеличить до 3067 байт). Чтобы уместиться в этот размер, индексируют только первые 191 симоволов - 191 * 4 = 764 байт. В myisam максимальный размер 1000 байт, где при четырех байтов как раз умещаются 250 символов. Поэтому в ips4 встречаются как индексы длиной 191 так и длиной в 250, видимо индусы не смогли решить какокому типу таблиц отдать предпочтения. 

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

 

Пс.

Что касается вашего примера. 255 - это символы. Прочитайте документацию, там идет речь о characters. Теперь посмотрите на ваш пример.

Кстати - проблема так и не ушла. Дело не в кодировке, а в глюке движка. Такая ошибка появляется при редактировании и сохранении уже готового сообщения, а не при создании нового. Так что можно и не конвертировать ничего.

Ошибка задолбала! Как ее вылечить?

3 часа назад, seobot сказал:

Ошибка задолбала! Как ее вылечить?

Указать в conf_global.php sql_utf8mb4 => true

 

В Monday, December 07, 2015 в 05:50, ZeRik сказал:

На конкретном примере: есть столбец типа TINYTEXT (255), который вместит в себя 85 3-х байтовых символов (85 х 3 = 255), или 63 4-х байтовых символов ( 64 х 4 = 255)

Такая ересь имеет место быть только когда данные в одной кодировки пытаются всунуть в таблицу другой. Например когда поле имеет кодировку cp1251, а туда вставляют двухбайтную кириллицу в utf-8, в итоге она обрезается наполовину потому что для нее рассчитано только 255 байт. На самом деле mysql выделяет столько место, сколько занимают символы в этой кодировке. varchar(255) будет содержать максимум 255 символов, а занимать место будет согласно кодировке этого поле.