Настроить кодировку для кириллицы

[LilyL]

Помогите настроить dbForge for MySQL для работы с кириллицей - у меня не получается . Скачала последнюю версию

[AlexZ]

Попробуйте установить галочку "Использовать Юникод" в редакторе соединения на страничке "Дополнительные".

Хочу также сообщить, что сейчас готовится к релизу dbForge Studio for MySQL v3.60, в котором будет включено более расширенное управление кодировками соединения.

[AlexZ]

Хочу также посоветовать почитать статью на нашем блоге https://blog.devart.com/working-with-na ... mysql.html

[LilyL]

Спасибо огромное за информацию

[m00nk]

Вижу до меня по этой теме ругались многие, я теперь тоже поругаюсь.

Хочу также сообщить, что сейчас готовится к релизу dbForge Studio for MySQL v3.60, в котором будет включено более расширенное управление кодировками соединения.

Ребята, ну когда уже с кодировками разберетесь?

Стояла версия 3.60.347.1 (и более ранние), база в UTF-8, галка "Использовать юникод" установлена - все работало прекрасно.

Сегодня установил 3.60.351.1, в настройках соединения установлено "Unicode (UTF-8) -> utf8", а все русские тексты из базы теперь в просмотре и в редакторах превратились вот в это: Тестовый продукт

Естественно, если в редакторе набрать русский текст, то он отображается нормально, но на сайте потом только вопросики...

Ребята, ну сколько уже можно топтаться на одних и тех же граблях? В одной версии исправите, в следующей сломаете...

И, кстати, уменьшите, пожалуйста, авто-ширину полей TEXT в табличном просмотре, а то если текст имеет первую строку большой длины, то приходится скроллить чтоб до кнопки редактирования добраться.

[AlexZ]

Ребята, ну когда уже с кодировками разберетесь?

Дело в том, что в версии 3.50 были проблемы с использованием кодировок, в случае выключенной опции "Использовать Юникод". Результат мог быть непредсказуемым. В версии 3.60 было в корне переделано поведение с кодировками соединения. Теперь Вы всегда должны задать правильную кодировку соединения. В том числе можете указать автоматический выбор кодировки для сервера версии ниже 4.0.
В любом случае, для понимания процесса работы с кодировками рекомендуем Вам прочитать статью в нашем блоге: https://blog.devart.com/working-with-na ... mysql.html.

Стояла версия 3.60.347.1 (и более ранние), база в UTF-8, галка "Использовать юникод" установлена - все работало прекрасно.

Здесь вышла наверно какая опечатка :( Как я уже сказал в 3.60 опции "Использовать Юникод" уже нет и логика работы с кодировками другая.

Сегодня установил 3.60.351.1, в настройках соединения установлено "Unicode (UTF-8) -> utf8", а все русские тексты из базы теперь в просмотре и в редакторах превратились вот в это: Тестовый продукт :(

Мы не можем воспроизвести данную проблему в случае корректно настроенных опций соединения. Для воспроизведения этой проблемы укажите, пожалуйста:
* версию Вашего сервера MySQL;
* DDL таблицы, с которой возникает данная проблема;
* используете ли Вы SET NAMES в скрипте, который заливает данные в таблицу и если да, то какой?
* какую кодировку соединения Вы использовали, когда заливали данные в таблицу?

Естественно, если в редакторе набрать русский текст, то он отображается нормально, но на сайте потом только вопросики...

Проверьте, пожалуйста, в какой кодировке выводятся Ваши HTML-страницы.

Ребята, ну сколько уже можно топтаться на одних и тех же граблях? В одной версии исправите, в следующей сломаете... :(

Мы стараемся изменять нашу логику по требованиям наших клиентов. Именно поэтому в 3.60 было принято решение переделать опции соединения.

И, кстати, уменьшите, пожалуйста, авто-ширину полей TEXT в табличном просмотре, а то если текст имеет первую строку большой длины, то приходится скроллить чтоб до кнопки редактирования добраться. :(

Попробуйте выключить опцию "Автоматически выравнивать ширину столбцов" (Параметры -> Редактор данных -> Общие).

[m00nk]

Для воспроизведения этой проблемы укажите, пожалуйста:

Ребята, я понимаю, что с вопросами к вам обращается масса новичков (ламеров) и часто проблема не в программе, а у них. Но все же не стоит всех считать новичками.

У меня полный порядок, MySQL 5.1.30, все таблицы создавались вашей программой еще в версии 3.50.310, (там и была галка "использовать юникод", в предыдущем посте я ошибся), все таблицы в юникоде (ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_general_ci), При соединении используется set names utf8, страницы выводятся в utf8...

Еще раз повторяю, таблицы были созданы в 3.50.310, все работало корректно.
Затем обновил версию до 3.60.347.1. Обновление прошло прекрасно, и все работало прекрасно. Никаких изменений в скриптах и соединениях не производилось.
Проблема возникла именно после установки последней версии (3.60.351.1).

Попробуйте выключить опцию "Автоматически выравнивать ширину столбцов" (Параметры -> Редактор данных -> Общие).

Я вам про одно, вы мне про другое.

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

Я прошу сделать, чтобы максимальная ширина столбца таблицы для полей типа TEXT (при включенной опции автовыравнивания ширины) была не более половины ширины рабочего окна. А сейчас она в моих таблицах по ширине равна полутора экранам.

Просто загоните в тестовую таблицу реальные данные и сами увидите насколько это неудобно.

[AlexZ]

У меня полный порядок, MySQL 5.1.30, все таблицы создавались вашей программой еще в версии 3.50.310, (там и была галка "использовать юникод", в предыдущем посте я ошибся), все таблицы в юникоде (ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_general_ci), При соединении используется set names utf8, страницы выводятся в utf8...
Еще раз повторяю, таблицы были созданы в 3.50.310, все работало корректно.
Затем обновил версию до 3.60.347.1. Обновление прошло прекрасно, и все работало прекрасно. Никаких изменений в скриптах и соединениях не производилось.
Проблема возникла именно после установки последней версии (3.60.351.1).

Мы проверяли работу с кодировками вдоль и поперек. К сожалению, указанную Вами проблему нам воспроизвести не удалось. Мы воспроизвели и исправили похожую проблему, но в случае, если у соединения была включена опция автоопределения кодировки сервера. Проверьте, включена ли эта опция у Вас? Если да, то можете выключить её и перезапустить приложение - должно помочь. В любом случае, это исправление будет доступно в следующем билде продукта.

Я прошу сделать, чтобы максимальная ширина столбца таблицы для полей типа TEXT (при включенной опции автовыравнивания ширины) была не более половины ширины рабочего окна. А сейчас она в моих таблицах по ширине равна полутора экранам.

Мы рассмотрим Ваше предложение для реализации в будущих версиях продукта.

[Viktor]

Я прошу сделать, чтобы максимальная ширина столбца таблицы для полей типа TEXT (при включенной опции автовыравнивания ширины) была не более половины ширины рабочего окна. А сейчас она в моих таблицах по ширине равна полутора экранам.

В последней версии реализован следующий механизм автовыравнивания ширины колонок с полями типа TEXT:
1. Если свободное место(после автовыравнивания других колонок) на экране занимает меньше ширины 1го экрана, то ширина колонок TEXT максимальная. В этом случае грид занимает все свободное место на 1м экране.
2. Иначе минимальная ширина TEXT полей = 1/3 ширины рабочего экрана.

[pravoverov]

Настройки соединения UTF8 работают превосходно, однако, разработчики забыли напомнить, что из десятков шрифтов услужливо предлагаемых Windows, следует выбрать поддерживающие эту кодировку. Например, Arial, Times, Tahoma, а лучше Courier, так как, в нём, все знаки имеют одинаковую ширину и нам не придётся удивляться, почему слова, или числа одинаковой длины выглядят не так, как ожидается.

[Alexander]

Если у Вас есть конкретный вопрос, не могли бы Вы прислать его на supportATdevartDOTcom вместе с детальным описанием проблемы? Скриншоты также помогли бы нам в исследовании проблемы.