100napb Опубликовано: 21 августа 2018 Поделиться Опубликовано: 21 августа 2018 (изменено) Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Spoiler Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Изменено 21 августа 2018 пользователем 100napb 9 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 21 августа 2018 Автор Поделиться Опубликовано: 21 августа 2018 (изменено) не удержался, обновил кодировки в таблице oc_order_history. Теперь отправляю красивые письма клиентам )) Вот так в истории заказов: Spoiler А вот так у получателя: Spoiler Изменено 21 августа 2018 пользователем 100napb Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 месяц спустя... bratok1988 Опубликовано: 18 октября 2018 Поделиться Опубликовано: 18 октября 2018 В 21.08.2018 в 16:25, 100napb сказал: Показать контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. А у меня парадокс получился )) На первом сайте (дефолтный шаблон стоит) Второй и третий пункт сделал как у вас. И все ок) А на втором (другой шаблон) пошли крякозяблики. Проторчал пол дня, что я только не менял. В итоге вернул резервные файлы. И начал по порядку. Так вот на пункте 2 закончил и все работает. Спасибо Вам за решение со смайликами)) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 8 месяцев спустя... krluch Опубликовано: 18 июля 2019 Поделиться Опубликовано: 18 июля 2019 (изменено) Супер! То, что доктор прописал Emoji нельзя использовать при вставке через модификатор. Если у кого способ решения? Изменено 18 июля 2019 пользователем krluch Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 19 июля 2019 Поделиться Опубликовано: 19 июля 2019 В 18.07.2019 в 14:50, krluch сказал: Супер! То, что доктор прописал Нихрена не супер сайт перестал работать, пришлось бекап восстанавливать. Проблема была в кодировке @100napb вы не сталкивались с такой проблемой? Может есть рецепт как запустить сайт с emoji? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 19 июля 2019 Автор Поделиться Опубликовано: 19 июля 2019 34 minutes ago, krluch said: сайт перестал работать, пришлось бекап восстанавливать. Проблема была в кодировке Без логов и указаний на конкретные ошибки, которые являлись причиной падения сайта и отката с бэкапов, сложно дать однозначные, конкретные ответы. 43 minutes ago, krluch said: Может есть рецепт как запустить сайт с emoji? что Вы имеете ввиду? у меня, например, есть проект, на котором эмодзи могут содержаться в отзывах клиентов, описаниях продуктов\статьях и в комментариях к заказам (отправяляются на почту клиентам). Исправно работает больше года по рецепту, которым делился выше. Если нужна помощь, а не совет, то пишите в ЛС. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 26 июля 2019 Поделиться Опубликовано: 26 июля 2019 На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... johngalt1 Опубликовано: 29 июля 2019 Поделиться Опубликовано: 29 июля 2019 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Показать контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Тоже актуально. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 4 недели спустя... 100napb Опубликовано: 21 августа 2019 Автор Поделиться Опубликовано: 21 августа 2019 19 minutes ago, smartcoder said: Сделали такой модуль, для редактора summernote без изменений в базе. звучит здорово. Из любопытства и для большего понимания (думаю, не мне одному может быть интересно): получается, вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. ниже пару скринов с демо-сайта модуля Spoiler Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Гость smartcoder Опубликовано: 21 августа 2019 Поделиться Опубликовано: 21 августа 2019 16 минут назад, 100napb сказал: вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. Да, выводятся как картинки. Поэтому никаких изменений с бд делать не нужно для этого модуля. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 месяц спустя... storer Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 В 26.07.2019 в 17:19, krluch сказал: На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Всем привет. Эти запрос к БД как-то могут убить контент, который уже есть в БД? Может конфликт какой возникнет или еще что-то? Сыкотно немного) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 1 час назад, storer сказал: Эти запрос к БД как-то могут убить контент У меня не навредило, но если сомневаешься - сделай бекап Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... maksym41193 Опубликовано: 17 апреля 2020 Поделиться Опубликовано: 17 апреля 2020 В 21.08.2018 в 16:25, 100napb сказал: Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 17 апреля 2020 Автор Поделиться Опубликовано: 17 апреля 2020 4 hours ago, maksym41193 said: все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? каких-то естественных причин для этого нет. Возможно у Вас работает\работал какой-то экспорт-импорт, интеграция с внешними системами или что-то перегоняет данные с искажением кодировки. Может быть откатывались из бэкапа или хостер что-то начудил... сложно сказать наверняка. Для начала проверьте а) по-прежнему ли стоит нужная кодировка для выбранных полей в БД ? б) есть ли какие-нибудь механизмы, которые заливают данные на сайт? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 год спустя... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Добрый день, подскажите, пожалуйста, а как Вы решаете проблему с необходимым уменьшением размера поля VARCHAR 255? Дело в том, что после изменения кодировки таблицы целиком по-хорошему нужно уменьшить значение типа столбца VARCHAR до 249. Проблема в том, что я не нашел как-бы так найти допустим все столбики во всех таблицах типа VARCHAR 255 с кодировкой utf8mb4_unicode_ci и заменить значение для этого типа на 249, но как выполнить такой запрос я так и не нашел. Может у Вас есть какой-то вариант? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 21 июля 2021 Автор Поделиться Опубликовано: 21 июля 2021 25 minutes ago, AlektroNik said: Может у Вас есть какой-то вариант? я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 3 Перейти к списку тем Похожие публикации Дублируються запросы в базу данных. Автор: mario512, 6 сентября 2022 mysql opencart (и ещё 1) Теги: mysql opencart птн пнх 4 ответа 654 просмотра mario512 6 сентября 2022 работа с базой данных Автор: AlexMax13, 1 августа 2022 база данных mysql 8 ответов 1 073 просмотра diterknobloch 27 февраля 2023 [Поддержка] Поддержка Emoji (unicode) Автор: SirGrey, 14 марта 2020 emoji смайлы (и ещё 1) Теги: emoji смайлы utf8mb4 0 ответов 1 096 просмотров SirGrey 17 марта 2020 Модуль SQL менеджер SQL Buddy [Поддержка] 1 2 Автор: sv2109, 26 июля 2013 mysql 32 ответа 6 786 просмотров PetrSemenov 29 октября 2017 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 2.x Opencart 2.x: Настройка и оптимизация Эмодзи VS Opencart. Кодировки в Mysql и правки mysqli.php Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
100napb Опубликовано: 21 августа 2018 Автор Поделиться Опубликовано: 21 августа 2018 (изменено) не удержался, обновил кодировки в таблице oc_order_history. Теперь отправляю красивые письма клиентам )) Вот так в истории заказов: Spoiler А вот так у получателя: Spoiler Изменено 21 августа 2018 пользователем 100napb Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 месяц спустя... bratok1988 Опубликовано: 18 октября 2018 Поделиться Опубликовано: 18 октября 2018 В 21.08.2018 в 16:25, 100napb сказал: Показать контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. А у меня парадокс получился )) На первом сайте (дефолтный шаблон стоит) Второй и третий пункт сделал как у вас. И все ок) А на втором (другой шаблон) пошли крякозяблики. Проторчал пол дня, что я только не менял. В итоге вернул резервные файлы. И начал по порядку. Так вот на пункте 2 закончил и все работает. Спасибо Вам за решение со смайликами)) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 8 месяцев спустя... krluch Опубликовано: 18 июля 2019 Поделиться Опубликовано: 18 июля 2019 (изменено) Супер! То, что доктор прописал Emoji нельзя использовать при вставке через модификатор. Если у кого способ решения? Изменено 18 июля 2019 пользователем krluch Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 19 июля 2019 Поделиться Опубликовано: 19 июля 2019 В 18.07.2019 в 14:50, krluch сказал: Супер! То, что доктор прописал Нихрена не супер сайт перестал работать, пришлось бекап восстанавливать. Проблема была в кодировке @100napb вы не сталкивались с такой проблемой? Может есть рецепт как запустить сайт с emoji? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 19 июля 2019 Автор Поделиться Опубликовано: 19 июля 2019 34 minutes ago, krluch said: сайт перестал работать, пришлось бекап восстанавливать. Проблема была в кодировке Без логов и указаний на конкретные ошибки, которые являлись причиной падения сайта и отката с бэкапов, сложно дать однозначные, конкретные ответы. 43 minutes ago, krluch said: Может есть рецепт как запустить сайт с emoji? что Вы имеете ввиду? у меня, например, есть проект, на котором эмодзи могут содержаться в отзывах клиентов, описаниях продуктов\статьях и в комментариях к заказам (отправяляются на почту клиентам). Исправно работает больше года по рецепту, которым делился выше. Если нужна помощь, а не совет, то пишите в ЛС. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 26 июля 2019 Поделиться Опубликовано: 26 июля 2019 На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... johngalt1 Опубликовано: 29 июля 2019 Поделиться Опубликовано: 29 июля 2019 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Показать контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Тоже актуально. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 4 недели спустя... 100napb Опубликовано: 21 августа 2019 Автор Поделиться Опубликовано: 21 августа 2019 19 minutes ago, smartcoder said: Сделали такой модуль, для редактора summernote без изменений в базе. звучит здорово. Из любопытства и для большего понимания (думаю, не мне одному может быть интересно): получается, вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. ниже пару скринов с демо-сайта модуля Spoiler Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Гость smartcoder Опубликовано: 21 августа 2019 Поделиться Опубликовано: 21 августа 2019 16 минут назад, 100napb сказал: вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. Да, выводятся как картинки. Поэтому никаких изменений с бд делать не нужно для этого модуля. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 месяц спустя... storer Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 В 26.07.2019 в 17:19, krluch сказал: На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Всем привет. Эти запрос к БД как-то могут убить контент, который уже есть в БД? Может конфликт какой возникнет или еще что-то? Сыкотно немного) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 1 час назад, storer сказал: Эти запрос к БД как-то могут убить контент У меня не навредило, но если сомневаешься - сделай бекап Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... maksym41193 Опубликовано: 17 апреля 2020 Поделиться Опубликовано: 17 апреля 2020 В 21.08.2018 в 16:25, 100napb сказал: Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 17 апреля 2020 Автор Поделиться Опубликовано: 17 апреля 2020 4 hours ago, maksym41193 said: все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? каких-то естественных причин для этого нет. Возможно у Вас работает\работал какой-то экспорт-импорт, интеграция с внешними системами или что-то перегоняет данные с искажением кодировки. Может быть откатывались из бэкапа или хостер что-то начудил... сложно сказать наверняка. Для начала проверьте а) по-прежнему ли стоит нужная кодировка для выбранных полей в БД ? б) есть ли какие-нибудь механизмы, которые заливают данные на сайт? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 год спустя... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Добрый день, подскажите, пожалуйста, а как Вы решаете проблему с необходимым уменьшением размера поля VARCHAR 255? Дело в том, что после изменения кодировки таблицы целиком по-хорошему нужно уменьшить значение типа столбца VARCHAR до 249. Проблема в том, что я не нашел как-бы так найти допустим все столбики во всех таблицах типа VARCHAR 255 с кодировкой utf8mb4_unicode_ci и заменить значение для этого типа на 249, но как выполнить такой запрос я так и не нашел. Может у Вас есть какой-то вариант? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 21 июля 2021 Автор Поделиться Опубликовано: 21 июля 2021 25 minutes ago, AlektroNik said: Может у Вас есть какой-то вариант? я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 3 Перейти к списку тем Похожие публикации Дублируються запросы в базу данных. Автор: mario512, 6 сентября 2022 mysql opencart (и ещё 1) Теги: mysql opencart птн пнх 4 ответа 654 просмотра mario512 6 сентября 2022 работа с базой данных Автор: AlexMax13, 1 августа 2022 база данных mysql 8 ответов 1 073 просмотра diterknobloch 27 февраля 2023 [Поддержка] Поддержка Emoji (unicode) Автор: SirGrey, 14 марта 2020 emoji смайлы (и ещё 1) Теги: emoji смайлы utf8mb4 0 ответов 1 096 просмотров SirGrey 17 марта 2020 Модуль SQL менеджер SQL Buddy [Поддержка] 1 2 Автор: sv2109, 26 июля 2013 mysql 32 ответа 6 786 просмотров PetrSemenov 29 октября 2017 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 2.x Opencart 2.x: Настройка и оптимизация Эмодзи VS Opencart. Кодировки в Mysql и правки mysqli.php Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
bratok1988 Опубликовано: 18 октября 2018 Поделиться Опубликовано: 18 октября 2018 В 21.08.2018 в 16:25, 100napb сказал: Показать контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. А у меня парадокс получился )) На первом сайте (дефолтный шаблон стоит) Второй и третий пункт сделал как у вас. И все ок) А на втором (другой шаблон) пошли крякозяблики. Проторчал пол дня, что я только не менял. В итоге вернул резервные файлы. И начал по порядку. Так вот на пункте 2 закончил и все работает. Спасибо Вам за решение со смайликами)) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
krluch Опубликовано: 18 июля 2019 Поделиться Опубликовано: 18 июля 2019 (изменено) Супер! То, что доктор прописал Emoji нельзя использовать при вставке через модификатор. Если у кого способ решения? Изменено 18 июля 2019 пользователем krluch Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 19 июля 2019 Поделиться Опубликовано: 19 июля 2019 В 18.07.2019 в 14:50, krluch сказал: Супер! То, что доктор прописал Нихрена не супер сайт перестал работать, пришлось бекап восстанавливать. Проблема была в кодировке @100napb вы не сталкивались с такой проблемой? Может есть рецепт как запустить сайт с emoji? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 19 июля 2019 Автор Поделиться Опубликовано: 19 июля 2019 34 minutes ago, krluch said: сайт перестал работать, пришлось бекап восстанавливать. Проблема была в кодировке Без логов и указаний на конкретные ошибки, которые являлись причиной падения сайта и отката с бэкапов, сложно дать однозначные, конкретные ответы. 43 minutes ago, krluch said: Может есть рецепт как запустить сайт с emoji? что Вы имеете ввиду? у меня, например, есть проект, на котором эмодзи могут содержаться в отзывах клиентов, описаниях продуктов\статьях и в комментариях к заказам (отправяляются на почту клиентам). Исправно работает больше года по рецепту, которым делился выше. Если нужна помощь, а не совет, то пишите в ЛС. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 26 июля 2019 Поделиться Опубликовано: 26 июля 2019 На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... johngalt1 Опубликовано: 29 июля 2019 Поделиться Опубликовано: 29 июля 2019 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Показать контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Тоже актуально. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 4 недели спустя... 100napb Опубликовано: 21 августа 2019 Автор Поделиться Опубликовано: 21 августа 2019 19 minutes ago, smartcoder said: Сделали такой модуль, для редактора summernote без изменений в базе. звучит здорово. Из любопытства и для большего понимания (думаю, не мне одному может быть интересно): получается, вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. ниже пару скринов с демо-сайта модуля Spoiler Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Гость smartcoder Опубликовано: 21 августа 2019 Поделиться Опубликовано: 21 августа 2019 16 минут назад, 100napb сказал: вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. Да, выводятся как картинки. Поэтому никаких изменений с бд делать не нужно для этого модуля. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 месяц спустя... storer Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 В 26.07.2019 в 17:19, krluch сказал: На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Всем привет. Эти запрос к БД как-то могут убить контент, который уже есть в БД? Может конфликт какой возникнет или еще что-то? Сыкотно немного) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 1 час назад, storer сказал: Эти запрос к БД как-то могут убить контент У меня не навредило, но если сомневаешься - сделай бекап Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... maksym41193 Опубликовано: 17 апреля 2020 Поделиться Опубликовано: 17 апреля 2020 В 21.08.2018 в 16:25, 100napb сказал: Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 17 апреля 2020 Автор Поделиться Опубликовано: 17 апреля 2020 4 hours ago, maksym41193 said: все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? каких-то естественных причин для этого нет. Возможно у Вас работает\работал какой-то экспорт-импорт, интеграция с внешними системами или что-то перегоняет данные с искажением кодировки. Может быть откатывались из бэкапа или хостер что-то начудил... сложно сказать наверняка. Для начала проверьте а) по-прежнему ли стоит нужная кодировка для выбранных полей в БД ? б) есть ли какие-нибудь механизмы, которые заливают данные на сайт? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 год спустя... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Добрый день, подскажите, пожалуйста, а как Вы решаете проблему с необходимым уменьшением размера поля VARCHAR 255? Дело в том, что после изменения кодировки таблицы целиком по-хорошему нужно уменьшить значение типа столбца VARCHAR до 249. Проблема в том, что я не нашел как-бы так найти допустим все столбики во всех таблицах типа VARCHAR 255 с кодировкой utf8mb4_unicode_ci и заменить значение для этого типа на 249, но как выполнить такой запрос я так и не нашел. Может у Вас есть какой-то вариант? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 21 июля 2021 Автор Поделиться Опубликовано: 21 июля 2021 25 minutes ago, AlektroNik said: Может у Вас есть какой-то вариант? я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 3 Перейти к списку тем Похожие публикации Дублируються запросы в базу данных. Автор: mario512, 6 сентября 2022 mysql opencart (и ещё 1) Теги: mysql opencart птн пнх 4 ответа 654 просмотра mario512 6 сентября 2022 работа с базой данных Автор: AlexMax13, 1 августа 2022 база данных mysql 8 ответов 1 073 просмотра diterknobloch 27 февраля 2023 [Поддержка] Поддержка Emoji (unicode) Автор: SirGrey, 14 марта 2020 emoji смайлы (и ещё 1) Теги: emoji смайлы utf8mb4 0 ответов 1 096 просмотров SirGrey 17 марта 2020 Модуль SQL менеджер SQL Buddy [Поддержка] 1 2 Автор: sv2109, 26 июля 2013 mysql 32 ответа 6 786 просмотров PetrSemenov 29 октября 2017 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 2.x Opencart 2.x: Настройка и оптимизация Эмодзи VS Opencart. Кодировки в Mysql и правки mysqli.php Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
krluch Опубликовано: 19 июля 2019 Поделиться Опубликовано: 19 июля 2019 В 18.07.2019 в 14:50, krluch сказал: Супер! То, что доктор прописал Нихрена не супер сайт перестал работать, пришлось бекап восстанавливать. Проблема была в кодировке @100napb вы не сталкивались с такой проблемой? Может есть рецепт как запустить сайт с emoji? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 19 июля 2019 Автор Поделиться Опубликовано: 19 июля 2019 34 minutes ago, krluch said: сайт перестал работать, пришлось бекап восстанавливать. Проблема была в кодировке Без логов и указаний на конкретные ошибки, которые являлись причиной падения сайта и отката с бэкапов, сложно дать однозначные, конкретные ответы. 43 minutes ago, krluch said: Может есть рецепт как запустить сайт с emoji? что Вы имеете ввиду? у меня, например, есть проект, на котором эмодзи могут содержаться в отзывах клиентов, описаниях продуктов\статьях и в комментариях к заказам (отправяляются на почту клиентам). Исправно работает больше года по рецепту, которым делился выше. Если нужна помощь, а не совет, то пишите в ЛС. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 26 июля 2019 Поделиться Опубликовано: 26 июля 2019 На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... johngalt1 Опубликовано: 29 июля 2019 Поделиться Опубликовано: 29 июля 2019 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Показать контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Тоже актуально. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 4 недели спустя... 100napb Опубликовано: 21 августа 2019 Автор Поделиться Опубликовано: 21 августа 2019 19 minutes ago, smartcoder said: Сделали такой модуль, для редактора summernote без изменений в базе. звучит здорово. Из любопытства и для большего понимания (думаю, не мне одному может быть интересно): получается, вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. ниже пару скринов с демо-сайта модуля Spoiler Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Гость smartcoder Опубликовано: 21 августа 2019 Поделиться Опубликовано: 21 августа 2019 16 минут назад, 100napb сказал: вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. Да, выводятся как картинки. Поэтому никаких изменений с бд делать не нужно для этого модуля. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 месяц спустя... storer Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 В 26.07.2019 в 17:19, krluch сказал: На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Всем привет. Эти запрос к БД как-то могут убить контент, который уже есть в БД? Может конфликт какой возникнет или еще что-то? Сыкотно немного) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 1 час назад, storer сказал: Эти запрос к БД как-то могут убить контент У меня не навредило, но если сомневаешься - сделай бекап Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... maksym41193 Опубликовано: 17 апреля 2020 Поделиться Опубликовано: 17 апреля 2020 В 21.08.2018 в 16:25, 100napb сказал: Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 17 апреля 2020 Автор Поделиться Опубликовано: 17 апреля 2020 4 hours ago, maksym41193 said: все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? каких-то естественных причин для этого нет. Возможно у Вас работает\работал какой-то экспорт-импорт, интеграция с внешними системами или что-то перегоняет данные с искажением кодировки. Может быть откатывались из бэкапа или хостер что-то начудил... сложно сказать наверняка. Для начала проверьте а) по-прежнему ли стоит нужная кодировка для выбранных полей в БД ? б) есть ли какие-нибудь механизмы, которые заливают данные на сайт? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 год спустя... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Добрый день, подскажите, пожалуйста, а как Вы решаете проблему с необходимым уменьшением размера поля VARCHAR 255? Дело в том, что после изменения кодировки таблицы целиком по-хорошему нужно уменьшить значение типа столбца VARCHAR до 249. Проблема в том, что я не нашел как-бы так найти допустим все столбики во всех таблицах типа VARCHAR 255 с кодировкой utf8mb4_unicode_ci и заменить значение для этого типа на 249, но как выполнить такой запрос я так и не нашел. Может у Вас есть какой-то вариант? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 21 июля 2021 Автор Поделиться Опубликовано: 21 июля 2021 25 minutes ago, AlektroNik said: Может у Вас есть какой-то вариант? я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 3 Перейти к списку тем Похожие публикации Дублируються запросы в базу данных. Автор: mario512, 6 сентября 2022 mysql opencart (и ещё 1) Теги: mysql opencart птн пнх 4 ответа 654 просмотра mario512 6 сентября 2022 работа с базой данных Автор: AlexMax13, 1 августа 2022 база данных mysql 8 ответов 1 073 просмотра diterknobloch 27 февраля 2023 [Поддержка] Поддержка Emoji (unicode) Автор: SirGrey, 14 марта 2020 emoji смайлы (и ещё 1) Теги: emoji смайлы utf8mb4 0 ответов 1 096 просмотров SirGrey 17 марта 2020 Модуль SQL менеджер SQL Buddy [Поддержка] 1 2 Автор: sv2109, 26 июля 2013 mysql 32 ответа 6 786 просмотров PetrSemenov 29 октября 2017 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 2.x Opencart 2.x: Настройка и оптимизация Эмодзи VS Opencart. Кодировки в Mysql и правки mysqli.php Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
100napb Опубликовано: 19 июля 2019 Автор Поделиться Опубликовано: 19 июля 2019 34 minutes ago, krluch said: сайт перестал работать, пришлось бекап восстанавливать. Проблема была в кодировке Без логов и указаний на конкретные ошибки, которые являлись причиной падения сайта и отката с бэкапов, сложно дать однозначные, конкретные ответы. 43 minutes ago, krluch said: Может есть рецепт как запустить сайт с emoji? что Вы имеете ввиду? у меня, например, есть проект, на котором эмодзи могут содержаться в отзывах клиентов, описаниях продуктов\статьях и в комментариях к заказам (отправяляются на почту клиентам). Исправно работает больше года по рецепту, которым делился выше. Если нужна помощь, а не совет, то пишите в ЛС. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 26 июля 2019 Поделиться Опубликовано: 26 июля 2019 На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... johngalt1 Опубликовано: 29 июля 2019 Поделиться Опубликовано: 29 июля 2019 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Показать контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Тоже актуально. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 4 недели спустя... 100napb Опубликовано: 21 августа 2019 Автор Поделиться Опубликовано: 21 августа 2019 19 minutes ago, smartcoder said: Сделали такой модуль, для редактора summernote без изменений в базе. звучит здорово. Из любопытства и для большего понимания (думаю, не мне одному может быть интересно): получается, вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. ниже пару скринов с демо-сайта модуля Spoiler Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Гость smartcoder Опубликовано: 21 августа 2019 Поделиться Опубликовано: 21 августа 2019 16 минут назад, 100napb сказал: вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. Да, выводятся как картинки. Поэтому никаких изменений с бд делать не нужно для этого модуля. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 месяц спустя... storer Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 В 26.07.2019 в 17:19, krluch сказал: На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Всем привет. Эти запрос к БД как-то могут убить контент, который уже есть в БД? Может конфликт какой возникнет или еще что-то? Сыкотно немного) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 1 час назад, storer сказал: Эти запрос к БД как-то могут убить контент У меня не навредило, но если сомневаешься - сделай бекап Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... maksym41193 Опубликовано: 17 апреля 2020 Поделиться Опубликовано: 17 апреля 2020 В 21.08.2018 в 16:25, 100napb сказал: Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 17 апреля 2020 Автор Поделиться Опубликовано: 17 апреля 2020 4 hours ago, maksym41193 said: все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? каких-то естественных причин для этого нет. Возможно у Вас работает\работал какой-то экспорт-импорт, интеграция с внешними системами или что-то перегоняет данные с искажением кодировки. Может быть откатывались из бэкапа или хостер что-то начудил... сложно сказать наверняка. Для начала проверьте а) по-прежнему ли стоит нужная кодировка для выбранных полей в БД ? б) есть ли какие-нибудь механизмы, которые заливают данные на сайт? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 год спустя... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Добрый день, подскажите, пожалуйста, а как Вы решаете проблему с необходимым уменьшением размера поля VARCHAR 255? Дело в том, что после изменения кодировки таблицы целиком по-хорошему нужно уменьшить значение типа столбца VARCHAR до 249. Проблема в том, что я не нашел как-бы так найти допустим все столбики во всех таблицах типа VARCHAR 255 с кодировкой utf8mb4_unicode_ci и заменить значение для этого типа на 249, но как выполнить такой запрос я так и не нашел. Может у Вас есть какой-то вариант? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 21 июля 2021 Автор Поделиться Опубликовано: 21 июля 2021 25 minutes ago, AlektroNik said: Может у Вас есть какой-то вариант? я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 3 Перейти к списку тем Похожие публикации Дублируються запросы в базу данных. Автор: mario512, 6 сентября 2022 mysql opencart (и ещё 1) Теги: mysql opencart птн пнх 4 ответа 654 просмотра mario512 6 сентября 2022 работа с базой данных Автор: AlexMax13, 1 августа 2022 база данных mysql 8 ответов 1 073 просмотра diterknobloch 27 февраля 2023 [Поддержка] Поддержка Emoji (unicode) Автор: SirGrey, 14 марта 2020 emoji смайлы (и ещё 1) Теги: emoji смайлы utf8mb4 0 ответов 1 096 просмотров SirGrey 17 марта 2020 Модуль SQL менеджер SQL Buddy [Поддержка] 1 2 Автор: sv2109, 26 июля 2013 mysql 32 ответа 6 786 просмотров PetrSemenov 29 октября 2017 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 2.x Opencart 2.x: Настройка и оптимизация Эмодзи VS Opencart. Кодировки в Mysql и правки mysqli.php Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
krluch Опубликовано: 26 июля 2019 Поделиться Опубликовано: 26 июля 2019 На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... johngalt1 Опубликовано: 29 июля 2019 Поделиться Опубликовано: 29 июля 2019 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Показать контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Тоже актуально. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 4 недели спустя... 100napb Опубликовано: 21 августа 2019 Автор Поделиться Опубликовано: 21 августа 2019 19 minutes ago, smartcoder said: Сделали такой модуль, для редактора summernote без изменений в базе. звучит здорово. Из любопытства и для большего понимания (думаю, не мне одному может быть интересно): получается, вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. ниже пару скринов с демо-сайта модуля Spoiler Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Гость smartcoder Опубликовано: 21 августа 2019 Поделиться Опубликовано: 21 августа 2019 16 минут назад, 100napb сказал: вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. Да, выводятся как картинки. Поэтому никаких изменений с бд делать не нужно для этого модуля. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 месяц спустя... storer Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 В 26.07.2019 в 17:19, krluch сказал: На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Всем привет. Эти запрос к БД как-то могут убить контент, который уже есть в БД? Может конфликт какой возникнет или еще что-то? Сыкотно немного) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 1 час назад, storer сказал: Эти запрос к БД как-то могут убить контент У меня не навредило, но если сомневаешься - сделай бекап Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... maksym41193 Опубликовано: 17 апреля 2020 Поделиться Опубликовано: 17 апреля 2020 В 21.08.2018 в 16:25, 100napb сказал: Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 17 апреля 2020 Автор Поделиться Опубликовано: 17 апреля 2020 4 hours ago, maksym41193 said: все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? каких-то естественных причин для этого нет. Возможно у Вас работает\работал какой-то экспорт-импорт, интеграция с внешними системами или что-то перегоняет данные с искажением кодировки. Может быть откатывались из бэкапа или хостер что-то начудил... сложно сказать наверняка. Для начала проверьте а) по-прежнему ли стоит нужная кодировка для выбранных полей в БД ? б) есть ли какие-нибудь механизмы, которые заливают данные на сайт? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 год спустя... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Добрый день, подскажите, пожалуйста, а как Вы решаете проблему с необходимым уменьшением размера поля VARCHAR 255? Дело в том, что после изменения кодировки таблицы целиком по-хорошему нужно уменьшить значение типа столбца VARCHAR до 249. Проблема в том, что я не нашел как-бы так найти допустим все столбики во всех таблицах типа VARCHAR 255 с кодировкой utf8mb4_unicode_ci и заменить значение для этого типа на 249, но как выполнить такой запрос я так и не нашел. Может у Вас есть какой-то вариант? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 21 июля 2021 Автор Поделиться Опубликовано: 21 июля 2021 25 minutes ago, AlektroNik said: Может у Вас есть какой-то вариант? я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 3 Перейти к списку тем Похожие публикации Дублируються запросы в базу данных. Автор: mario512, 6 сентября 2022 mysql opencart (и ещё 1) Теги: mysql opencart птн пнх 4 ответа 654 просмотра mario512 6 сентября 2022 работа с базой данных Автор: AlexMax13, 1 августа 2022 база данных mysql 8 ответов 1 073 просмотра diterknobloch 27 февраля 2023 [Поддержка] Поддержка Emoji (unicode) Автор: SirGrey, 14 марта 2020 emoji смайлы (и ещё 1) Теги: emoji смайлы utf8mb4 0 ответов 1 096 просмотров SirGrey 17 марта 2020 Модуль SQL менеджер SQL Buddy [Поддержка] 1 2 Автор: sv2109, 26 июля 2013 mysql 32 ответа 6 786 просмотров PetrSemenov 29 октября 2017 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 2.x Opencart 2.x: Настройка и оптимизация Эмодзи VS Opencart. Кодировки в Mysql и правки mysqli.php Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
johngalt1 Опубликовано: 29 июля 2019 Поделиться Опубликовано: 29 июля 2019 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Показать контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Тоже актуально. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
100napb Опубликовано: 21 августа 2019 Автор Поделиться Опубликовано: 21 августа 2019 19 minutes ago, smartcoder said: Сделали такой модуль, для редактора summernote без изменений в базе. звучит здорово. Из любопытства и для большего понимания (думаю, не мне одному может быть интересно): получается, вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. ниже пару скринов с демо-сайта модуля Spoiler Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Гость smartcoder Опубликовано: 21 августа 2019 Поделиться Опубликовано: 21 августа 2019 16 минут назад, 100napb сказал: вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. Да, выводятся как картинки. Поэтому никаких изменений с бд делать не нужно для этого модуля. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 месяц спустя... storer Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 В 26.07.2019 в 17:19, krluch сказал: На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Всем привет. Эти запрос к БД как-то могут убить контент, который уже есть в БД? Может конфликт какой возникнет или еще что-то? Сыкотно немного) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... krluch Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 1 час назад, storer сказал: Эти запрос к БД как-то могут убить контент У меня не навредило, но если сомневаешься - сделай бекап Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... maksym41193 Опубликовано: 17 апреля 2020 Поделиться Опубликовано: 17 апреля 2020 В 21.08.2018 в 16:25, 100napb сказал: Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 17 апреля 2020 Автор Поделиться Опубликовано: 17 апреля 2020 4 hours ago, maksym41193 said: все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? каких-то естественных причин для этого нет. Возможно у Вас работает\работал какой-то экспорт-импорт, интеграция с внешними системами или что-то перегоняет данные с искажением кодировки. Может быть откатывались из бэкапа или хостер что-то начудил... сложно сказать наверняка. Для начала проверьте а) по-прежнему ли стоит нужная кодировка для выбранных полей в БД ? б) есть ли какие-нибудь механизмы, которые заливают данные на сайт? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 год спустя... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Добрый день, подскажите, пожалуйста, а как Вы решаете проблему с необходимым уменьшением размера поля VARCHAR 255? Дело в том, что после изменения кодировки таблицы целиком по-хорошему нужно уменьшить значение типа столбца VARCHAR до 249. Проблема в том, что я не нашел как-бы так найти допустим все столбики во всех таблицах типа VARCHAR 255 с кодировкой utf8mb4_unicode_ci и заменить значение для этого типа на 249, но как выполнить такой запрос я так и не нашел. Может у Вас есть какой-то вариант? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 21 июля 2021 Автор Поделиться Опубликовано: 21 июля 2021 25 minutes ago, AlektroNik said: Может у Вас есть какой-то вариант? я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 3 Перейти к списку тем Похожие публикации Дублируються запросы в базу данных. Автор: mario512, 6 сентября 2022 mysql opencart (и ещё 1) Теги: mysql opencart птн пнх 4 ответа 654 просмотра mario512 6 сентября 2022 работа с базой данных Автор: AlexMax13, 1 августа 2022 база данных mysql 8 ответов 1 073 просмотра diterknobloch 27 февраля 2023 [Поддержка] Поддержка Emoji (unicode) Автор: SirGrey, 14 марта 2020 emoji смайлы (и ещё 1) Теги: emoji смайлы utf8mb4 0 ответов 1 096 просмотров SirGrey 17 марта 2020 Модуль SQL менеджер SQL Buddy [Поддержка] 1 2 Автор: sv2109, 26 июля 2013 mysql 32 ответа 6 786 просмотров PetrSemenov 29 октября 2017 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 2.x Opencart 2.x: Настройка и оптимизация Эмодзи VS Opencart. Кодировки в Mysql и правки mysqli.php Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha
Гость smartcoder Опубликовано: 21 августа 2019 Поделиться Опубликовано: 21 августа 2019 16 минут назад, 100napb сказал: вы научили редактор саммернот в админке сохранять что-то вроде bb-кодов для эмодзи, а сами эмотиконы выводятся на страничках сайта не как текст\шрифт, а как картинки? оригинальненько. Да, выводятся как картинки. Поэтому никаких изменений с бд делать не нужно для этого модуля. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
storer Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 В 26.07.2019 в 17:19, krluch сказал: На ocStore лучше сразу для всех таблиц ALTER TABLE oc_review CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_review_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_article_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_blog_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_category_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_information_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE oc_product_description CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Всем привет. Эти запрос к БД как-то могут убить контент, который уже есть в БД? Может конфликт какой возникнет или еще что-то? Сыкотно немного) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
krluch Опубликовано: 7 октября 2019 Поделиться Опубликовано: 7 октября 2019 1 час назад, storer сказал: Эти запрос к БД как-то могут убить контент У меня не навредило, но если сомневаешься - сделай бекап Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... maksym41193 Опубликовано: 17 апреля 2020 Поделиться Опубликовано: 17 апреля 2020 В 21.08.2018 в 16:25, 100napb сказал: Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 17 апреля 2020 Автор Поделиться Опубликовано: 17 апреля 2020 4 hours ago, maksym41193 said: все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? каких-то естественных причин для этого нет. Возможно у Вас работает\работал какой-то экспорт-импорт, интеграция с внешними системами или что-то перегоняет данные с искажением кодировки. Может быть откатывались из бэкапа или хостер что-то начудил... сложно сказать наверняка. Для начала проверьте а) по-прежнему ли стоит нужная кодировка для выбранных полей в БД ? б) есть ли какие-нибудь механизмы, которые заливают данные на сайт? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 год спустя... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Добрый день, подскажите, пожалуйста, а как Вы решаете проблему с необходимым уменьшением размера поля VARCHAR 255? Дело в том, что после изменения кодировки таблицы целиком по-хорошему нужно уменьшить значение типа столбца VARCHAR до 249. Проблема в том, что я не нашел как-бы так найти допустим все столбики во всех таблицах типа VARCHAR 255 с кодировкой utf8mb4_unicode_ci и заменить значение для этого типа на 249, но как выполнить такой запрос я так и не нашел. Может у Вас есть какой-то вариант? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 21 июля 2021 Автор Поделиться Опубликовано: 21 июля 2021 25 minutes ago, AlektroNik said: Может у Вас есть какой-то вариант? я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 3 Перейти к списку тем Похожие публикации Дублируються запросы в базу данных. Автор: mario512, 6 сентября 2022 mysql opencart (и ещё 1) Теги: mysql opencart птн пнх 4 ответа 654 просмотра mario512 6 сентября 2022 работа с базой данных Автор: AlexMax13, 1 августа 2022 база данных mysql 8 ответов 1 073 просмотра diterknobloch 27 февраля 2023 [Поддержка] Поддержка Emoji (unicode) Автор: SirGrey, 14 марта 2020 emoji смайлы (и ещё 1) Теги: emoji смайлы utf8mb4 0 ответов 1 096 просмотров SirGrey 17 марта 2020 Модуль SQL менеджер SQL Buddy [Поддержка] 1 2 Автор: sv2109, 26 июля 2013 mysql 32 ответа 6 786 просмотров PetrSemenov 29 октября 2017 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 2.x Opencart 2.x: Настройка и оптимизация Эмодзи VS Opencart. Кодировки в Mysql и правки mysqli.php
maksym41193 Опубликовано: 17 апреля 2020 Поделиться Опубликовано: 17 апреля 2020 В 21.08.2018 в 16:25, 100napb сказал: Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
100napb Опубликовано: 17 апреля 2020 Автор Поделиться Опубликовано: 17 апреля 2020 4 hours ago, maksym41193 said: все сделал так же, в админке все сохраняется http://joxi.ru/krDgwVeTJ9q8YA но вот какая беда, спустя какое-то время (1+ дней) вместо них появляется " ? " не подскажите почему так происходит? каких-то естественных причин для этого нет. Возможно у Вас работает\работал какой-то экспорт-импорт, интеграция с внешними системами или что-то перегоняет данные с искажением кодировки. Может быть откатывались из бэкапа или хостер что-то начудил... сложно сказать наверняка. Для начала проверьте а) по-прежнему ли стоит нужная кодировка для выбранных полей в БД ? б) есть ли какие-нибудь механизмы, которые заливают данные на сайт? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 1 год спустя... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Добрый день, подскажите, пожалуйста, а как Вы решаете проблему с необходимым уменьшением размера поля VARCHAR 255? Дело в том, что после изменения кодировки таблицы целиком по-хорошему нужно уменьшить значение типа столбца VARCHAR до 249. Проблема в том, что я не нашел как-бы так найти допустим все столбики во всех таблицах типа VARCHAR 255 с кодировкой utf8mb4_unicode_ci и заменить значение для этого типа на 249, но как выполнить такой запрос я так и не нашел. Может у Вас есть какой-то вариант? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 100napb Опубликовано: 21 июля 2021 Автор Поделиться Опубликовано: 21 июля 2021 25 minutes ago, AlektroNik said: Может у Вас есть какой-то вариант? я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 3 Перейти к списку тем Похожие публикации Дублируються запросы в базу данных. Автор: mario512, 6 сентября 2022 mysql opencart (и ещё 1) Теги: mysql opencart птн пнх 4 ответа 654 просмотра mario512 6 сентября 2022 работа с базой данных Автор: AlexMax13, 1 августа 2022 база данных mysql 8 ответов 1 073 просмотра diterknobloch 27 февраля 2023 [Поддержка] Поддержка Emoji (unicode) Автор: SirGrey, 14 марта 2020 emoji смайлы (и ещё 1) Теги: emoji смайлы utf8mb4 0 ответов 1 096 просмотров SirGrey 17 марта 2020 Модуль SQL менеджер SQL Buddy [Поддержка] 1 2 Автор: sv2109, 26 июля 2013 mysql 32 ответа 6 786 просмотров PetrSemenov 29 октября 2017 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу.
AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Добрый день, подскажите, пожалуйста, а как Вы решаете проблему с необходимым уменьшением размера поля VARCHAR 255? Дело в том, что после изменения кодировки таблицы целиком по-хорошему нужно уменьшить значение типа столбца VARCHAR до 249. Проблема в том, что я не нашел как-бы так найти допустим все столбики во всех таблицах типа VARCHAR 255 с кодировкой utf8mb4_unicode_ci и заменить значение для этого типа на 249, но как выполнить такой запрос я так и не нашел. Может у Вас есть какой-то вариант? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
100napb Опубликовано: 21 июля 2021 Автор Поделиться Опубликовано: 21 июля 2021 25 minutes ago, AlektroNik said: Может у Вас есть какой-то вариант? я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... 6 месяцев спустя... alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 3
AlektroNik Опубликовано: 21 июля 2021 Поделиться Опубликовано: 21 июля 2021 6 минут назад, 100napb сказал: я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет... Да, я именно об этом предупреждении. Ну математика немного не такая, вы забыли плюс 1 байт хранит длину строки. Т. е. в моем случае получается (249 + 1)*4=1000 В принципе ругается только на индексы (если опустить строки, где уже слишком длинные данные), но MariaDB без проблем меняет все кодировки. Смущает только то, что индексы обрезаются до 250 в любом случае. Значит, чисто теоретически, может быть ситуация, когда индекс выведет больше строк чем положено. Тип таблиц в большинстве случаев MyISAM. Менять бы не хотелось, наверное разрабам виднее какая таблица какого типа должна быть. Т. е. официальную структуру хотелось бы максимально оставить нетронутой. Поэтому сделал выбор в пользу точечного редактирования, но если бы можно было найти как-то автоматически все столбики с типами данных, которые превышают лимиты, это бы сильно ускорило и упростило процесс. Но я пока даже не смог найти команду которой просто можно вывести столбики определенного типа, допустим VARCHER. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
alexstekk Опубликовано: 9 февраля 2022 Поделиться Опубликовано: 9 февраля 2022 В 21.08.2018 в 16:25, 100napb сказал: Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Скрыть контент Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать? Метод рабочий на OCStore 2.3, после 3 шага всё заработало. Спасибо огромное! 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
Рекомендованные сообщения