Cyrillic general ci as что за кодировка

Общий форум

Есть у меня один сайт, котор ый прошел блольшой и славный путь, начиная от версии Moodle 1.4, а сейчас отлично работает на 1.8.4 ( нигде нет никаких проблем, в том числе и с кодировкой). За 5 лет работы случались аварии сервера, но все успешно восстанавливали и, поскольку сайт работает без замечаний, то и смотреть что там делается в базе данных особой надобности не было.

Однако, когда мы попытались перевести его с 1.8.4 на 1.9.5, то к большому удивлению получили сообщение об ошибке, что, якобы, база данных не в юникоде, и, дескать, нужно сначала установить версию 1.7. Но у нас же 1.8 давно и успешно работает, а на юникод мы переходили еще когда ставили 1.6!

Стал я смотреть базу данных через phpMyAdmin и обнаружил, что действительно, во многих таблицах в графе сравнение значится не utf8_general_ci, а cp1251_general_ci. Но больше удивило даже не это, а количество таблиц. Их там оказалось аж 307! Причем многие таблицы явно Moodle ‘овские, но не имеют в имени префикса, указанного в config.php. Если бы та же таблица и префикс неправильный имела и сортировка в ней была не та, то было бы понятно, что ее как-то случайно сюда занесло. Но это совсем не так!

Подскажите, пожалуйста, что делать? Как отремонтировать базу данных и убрать из нее лишние таблицы? Дальше оставаться на 1.8 уже нельзя.

Сумма оценок: —
В ответ на Alexandre Scherbyna

Re: Проблемы с кодировкой в базе данных

от Alexandre Belousov — пятница, 31 июля 2009, 20:34

Как вариант — сделать копию базы, сокнвертить таблицы в utf8 при помощи iconv, поискать ссылки на таблицы без префикса (возможно, были нестандартные расширения установлены?), если нет — удалить соответствующие файлы. Внимательно просмотреть базу на предмет времени обновления файлов, удалить неиспользуемые.
Попробовать снова поставить. Должно пройти нормально

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Alexandre Scherbyna

Re: Проблемы с кодировкой в базе данных

от Alex Djachenko — пятница, 31 июля 2009, 22:34

К сожалению, это частая ситуация, когда устанавливать и обслуживать систему поручают непрофильному специалисту, иногда даже вообще просто студенту: легкость установки персональной версии на домашнем компьютере создает впечатление, что и промышленным сервером с сотнями посетителей можно управляться без навыков администрирования Linux, СУБД, веб-серверов, знания php и понимания архитектуры Moodle.

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

Рекомендую начать с полной резервной копии дампа базы данных, htdocs и moodledata. Проверьте, чтобы в дампе данные были в читаемой кодировке (не важно, будет ли дамп читался при utf-8 или cp1251, но главное чтобы читался хоть в какой-нибудь — иначе он бесполезен).

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

Кодировку сравнения всей БД и всех таблиц нужно изменить на utf8 (вообще, при миграции с 1.5 на 1.6 это делал специальный скрипт, но почему он у вас не сработал — уже не разобраться). Можно воспользоваться дампом — скопировать туда нужные таблицы, заменить кодировку, а затем восстановить. Можно, конечно и вручную, через админку.

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

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Alex Djachenko

Re: Проблемы с кодировкой в базе данных

от Alexandre Scherbyna — воскресенье, 2 августа 2009, 17:53

Спасибо всем, кто откликнулся.
Я открыл базу в phpMyAdmin. Во все таблицы, где в графе Сравнение значилось CP1251_general_ ci заходил в Структуру и менял сначала в отдельных полях Сравнение с CP1251_general_ ci на utf8_general_ci, а потом входил на вкладку Операции и устанавливал utf8_general_ci для таблицы в целом (параметр, который отображается в в графе Сравнение общего списка таблиц базы данных).
Если открыть Обзор, то содержимое всех этих и любых других таблиц прекрасно читается, и браузер подтверждает, что кодировка UTF-8.
В результате CP1251 уже не видно нигде, но это не помогло. Выдает ту же ошибку. Пишет, что база данных не в юникоде

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Alexandre Scherbyna

Re: Проблемы с кодировкой в базе данных

от Alexandre Belousov — понедельник, 3 августа 2009, 04:32

В phpmyadmin что стоит по умолчанию как mysql-кодировка? Убедитесь, пожалуйста, что физически базы в Utf8.

В базе в mdl_config строка locale в какое значение установлена? Должно быть «ru_RU.UTF-8»

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Alex Djachenko

Re: Проблемы с кодировкой в базе данных

от Alexandre Scherbyna — воскресенье, 2 августа 2009, 18:34

Да, и что во всем этом больше всего удивляет, это то, что если вернуться к Moodle 1.8.4, то эта база данных с ним прекрасно работала и до описанных выше исправлений и продолжает работать после них. Выходит то, что для 1.8.4 — юникод, для 1.9.5 — уже не юникод?

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Alex Djachenko

Не полностью отображается главное навигационное меню

от Alexandre Scherbyna — воскресенье, 2 августа 2009, 23:44

Разобраться, почему эта ошибка возникает не смог, но нашел место в файле admin/index.php, где она обнаруживается:

/// If the database is not already Unicode then we do not allow upgrading!
/// Instead, we print an error telling them to upgrade to 1.7 first. MDL-6857
if (empty($CFG->unicodedb))

Поставил после if ( восклицательный знак, и 1.9.5 установилась.
На первый взгляд работает все, кроме главного навигационного меню. В нем почему-то осталась только ссылка для перехода на главную страницу сайта, а ссылки на главную страницу дисциплины и всего, что за ней обычно следует, уже нет. Вместо всего этого – только слово Array без ссылок.

Кто-нибудь с таким сталкивался?

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Alexandre Scherbyna

Re: Не полностью отображается главное навигационное меню

от Alex Djachenko — вторник, 4 августа 2009, 18:10

Без таких грубых хаков вполне можно обойтись (и вообще лучше избегать прямого редактирования кода): добавьте в таблицу mdl_config запись unicodedb со значением 1. Это отключит предупреждение, но не решить проблему с кодировками базы данных. При неправильной кодировке может неправильно выполняться поиск и сортировка, а так же могут возникнуть проблемы с импортом и экспортом дампа базы данных. Если Вы уверены что база данных в кодировке utf-8, для базы данных и всех таблиц установлены правильные параметры сравнения, то просто внесите запись unicodedb в mdl_config и предупреждение исчезнет (то же самое можно сделать через config.php).

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Alex Djachenko

Re: Не полностью отображается главное навигационное меню

от Alexandre Scherbyna — среда, 5 августа 2009, 06:56

Спасибо Алексей, это ценная информация. Записи unicodedb в моей mdl_config действительно нет, хотя в других базах, я вижу, это самая первая запись этой таблицы.
Перед следующим обновлением я ее пропишу. В общем перечне таблиц всюду установлено utf8_general_ci, но есть же еще и сравнение для каждого поля. Будет время позаглядываю еще и внутрь таблиц, какая там сортировка установлена.
А еще я читал, что после изменения сортировки надо делать REPAIR TABLE. С помощью phpMyAdmin это как можно сделать?

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Alexandre Scherbyna

Re: Не полностью отображается главное навигационное меню

от Dmitry Pupinin — пятница, 7 августа 2009, 01:22

Александр, лучший способ быть уверенным что в базе все в utf8 сделать следующее:
1. Сделать дамп базы в текстовый файл.
2. С помощью поиска/замены установить всюду сравнение в utf8_general_ci.
3. Переименовать старую базу данных.
4. Создать новую базу установив для нее utf8_general_ci.
5. Востановить данные из дампа в новую базу данных.

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Dmitry Pupinin

Re: Не полностью отображается главное навигационное меню

от Alexandre Scherbyna — пятница, 7 августа 2009, 05:00

Есть база данных Moodle, в которой всюду используется сортировка utf 8_ general _ ci . Пытаюсь воспользоваться вашим алгоритмом, чтобы заменить ее на нужную мне utf 8_ unicode _ ci .

Открываю базу в phpMyAdmin и выбираю для всех ее таблиц Экспорт, Texy! текст , Сохранить как файл, ОК.

Получаю текстовый файл, который комбинации символов utf 8_ general _ ci нигде не содержит. Что я не так делаю?

Кусочек из созданного файла присоединяю.

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Alexandre Scherbyna

Re: Не полностью отображается главное навигационное меню

от Vadim Tabunshchik — пятница, 7 августа 2009, 15:10

Александр, в phpMyAdmin выбирайте экспорт в SQL и проверьте, отмечен ли бокс Структура.
Получите файл с расширением .sql , который можно открыть блокнотом и увидеть примерно такое:

— phpMyAdmin SQL Dump
—
— Структура таблицы `mdl_assignment`
—
CREATE TABLE IF NOT EXISTS `mdl_assignment` (
`id` int(10) unsigned NOT NULL auto_increment,
`course` int(10) unsigned NOT NULL default ‘0’,
`name` varchar(255) collate utf8_unicode_ci NOT NULL default »,
`description` text collate utf8_unicode_ci NOT NULL,
`format` tinyint(4) unsigned NOT NULL default ‘0’,
`assignmenttype` varchar(50) collate utf8_unicode_ci NOT NULL default »,
`resubmit` tinyint(2) unsigned NOT NULL default ‘0’,
`preventlate` tinyint(2) unsigned NOT NULL default ‘0’,
`emailteachers` tinyint(2) unsigned NOT NULL default ‘0’,
`var1` int(10) default ‘0’,
`var2` int(10) default ‘0’,
`var3` int(10) default ‘0’,
`var4` int(10) default ‘0’,
`var5` int(10) default ‘0’,
`maxbytes` int(10) unsigned NOT NULL default ‘100000’,
`timedue` int(10) unsigned NOT NULL default ‘0’,
`timeavailable` int(10) unsigned NOT NULL default ‘0’,
`grade` int(10) NOT NULL default ‘0’,
`timemodified` int(10) unsigned NOT NULL default ‘0’,
PRIMARY KEY (`id`),
KEY `course` (`course`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT=’Defines assignments’ AUTO_INCREMENT=265 ;

—
— Дамп данных таблицы `mdl_assignment`.

Вот тут вы и можете воспользоваться «Поиск — Замена»
Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Vadim Tabunshchik

Re: Не полностью отображается главное навигационное меню

от Alexandre Scherbyna — пятница, 7 августа 2009, 17:57

Как я понял, с помощью Поиск/Замена нужно utf8_ general _ci всюду заменить на utf8_unicode_ci. Но проблема как раз в том, что utf8_ general _ci нигде нет. В файле с расширением sql (экспортированном со структурой) тоже.

В одной из баз я в phpMyAdmin заменил сортировку нескольких полей на utf8_unicode_ci. Так там строчки COLLATE utf8_unicode_ci где-то проскакивали, но utf8_ general _ci, увы, нет нигде. Может его нет потому, что оно где-то по умолчанию установлено?

Сумма оценок: —
Постоянная ссылка Показать сообщение-родителя Ответить
В ответ на Alexandre Scherbyna

Re: Не полностью отображается главное навигационное меню

от Dmitry Pupinin — воскресенье, 16 августа 2009, 15:43

Описаный способ использовался при переходе на 1.6, когда возникли проблемы с кодировкой. Так что это не теория.

Если COLLATE отсутствует, то почему его не добавить. с помощью той же замены.

Разница между collation Cyrillic_General и Cyrillic_General_100

Устанавливаю SQL Server 2016 Express Edition на Windows 2016 Server, хотел выбрать кириллическую collation, однако их находится две: Cyrillic_General и Cyrillic_General_100 В чём между ними разница? Сомневаюсь в выборе. Вижу, что почти все сопоставления имеют два варианта (со _100 и без), что это значит и для чего нужно?

Отслеживать
задан 19 янв 2019 в 19:27
28.6k 19 19 золотых знаков 58 58 серебряных знаков 136 136 бронзовых знаков

Ага, тоже интересно стало (хоть в винде я и не в зуб ногой, как говорится). Вот тут docs.microsoft.com/ru-ru/sql/t-sql/statements/… пишут, что _100 (еще упоминают _90 ) это Версия параметров сортировки. Я бы попробовал _100

19 янв 2019 в 21:44

@avp Эти циферки напоминают уровень совместимости базы, но только у меня в голове не умещается, что выбирается не SQL collaction, а Windows collation, в которой зашит SQL-уровень — а вот в самой Windows нет никаких _100 — и это как-то бредово.

19 янв 2019 в 21:54

AK, и не говорите, мне все эти варианты тоже не нравятся. Насколько всем программерам было бы проще сортировать прямо по кодам. (А пользуны бы в конце-концов привыкли -))

19 янв 2019 в 21:55
AK, судя по принятому ответу я угадал
23 янв 2019 в 20:05

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

Cyrillic_General и Cyrillic_General_100
В чём между ними разница?

Насколько я исследовал этот вопрос, символы русского алфавита (А-Я, а-я), а также символы латинского алфавита, цифры и знаки (с кодами 0x0020-0x007E) и в Cyrillic_General и в Cyrillic_General_100 обрабатываются одинаково. Однако есть разница для кириллических символов не используемых в русском языке.

Например, в таблице символов Unicode первая в кириллическом диапазоне буква — Ѐ (е с грависом) в Cyrillic_General_CI_AI трактуется не равной букве Ё, а в Cyrillic_General_100_CI_AI буквы Ѐ и Ё равны (что, при игнорировании диакритических знаков, по-видимому, более правильно):

SELECT eq = IIF(ch1_ci_ai = ch2_ci_ai, '=', '<>'), eq_100 = IIF(ch1_100_ci_ai = ch2_100_ci_ai, '=', '<>') FROM (VALUES (N'Ѐ', N'Ё')) c(ch1, ch2) CROSS APPLY ( SELECT ch1_ci_ai = c.ch1 COLLATE Cyrillic_General_CI_AI, ch2_ci_ai = c.ch2 COLLATE Cyrillic_General_CI_AI, ch1_100_ci_ai = c.ch1 COLLATE Cyrillic_General_100_CI_AI, ch2_100_ci_ai = c.ch2 COLLATE Cyrillic_General_100_CI_AI ) c2 

Также в Cyrillic_General буквы Ѐ и ѐ не преобразуются корректно к противоположному регистру, тогда как в Cyrillic_General_100 преобразование регистра для них корректное:

SELECT le = LOWER(N'Ѐ' COLLATE Cyrillic_General_CI_AI), ue = UPPER(N'ѐ' COLLATE Cyrillic_General_CI_AI), le_100 = LOWER(N'Ѐ' COLLATE Cyrillic_General_100_CI_AI), ue_100 = UPPER(N'ѐ' COLLATE Cyrillic_General_100_CI_AI) 

Есть разница и для некоторых других кириллических символов (и для не кириллических тоже).

В общем случае для новых разработок лучше выбирать наиболее актуальные версии — это, как правило, те, что содержат _100 в имени (для японского языка в SqlServer 2017 появились версии _140). Если же нужно обеспечить совместимость с какими-то уже существующими системами — выбирайте сообразно тому, что в них используется.

Обратите внимание также, что при установке задаётся collation инстанса. Для создаваемых в последствие баз данных всегда можно указать любой другой нужный collation (если не указать, то БД будет создана с collation инстанса). Поэтому, если вы не используете символы русского алфавита в названиях баз данных, логинов, серверных ролей и прочих instance-scope вещах, то, в принципе, можете выбрать даже и Latin1_General_100.

Python-сообщество

• Начало
• » Базы данных
• » pymssql 2.0.0, проблема с кодировками

#1 Янв. 30, 2013 15:31:58

Dimitor От: Зарегистрирован: 2007-10-30 Сообщения: 13 Репутация: 0 Профиль Отправить e-mail

pymssql 2.0.0, проблема с кодировками

Добрый день
В одном из моих проектов требуется записывать в MSSQL строки на русском языке. После смены версии библиотеки pymssql на свежую столкнулся с изменением ее поведения, с которым не смог справиться самостоятельно. Покажу на тестовом примере (такая схема работала на старой версии pymssql и вполне устраивала)
(Среда выполнения: Windows, Python 2.7, pymssql 2.0.0b, MSSQL2005, Collation — Cyrillic General CI AS):

# -*- coding: cp1251 -*- import pymssql con = pymssql.connect(host='127.1.1.1',user='sa',password='pass', database='reports', charset='cp1251') cur = con.cursor() sql = u"insert into users (FirstName,LastName,Job) values ('Вася', 'Пупкин', 'Пользователь')" print sql, isinstance(sql, unicode) # Исходный запрос sql = sql.encode('cp1251') print sql, isinstance(sql, unicode) # Запрос в кодировке БД cur.execute(sql) con.commit() cur.execute('SELECT * FROM users') for row in cur: print row[0], row[1], row[2] con.close() 

В результате получаем:

insert into users (FirstName,LastName,Job) values (‘Вася’, ‘Пупкин’, ‘Пользователь’) True
insert into users (FirstName,LastName,Job) values (‘Вася’, ‘Пупкин’, ‘Пользователь’) False
…
49 Павел Иванов # Нормальные значения, внесенные старой версией
…
55 Aany Ioieei # Значения в неверной кодировке, внесенные новой версией

После некоторой медитации с доками и исходным кодом библиотеки, решил что кодировку БД достаточно указать один раз в начале, а дополнительное преобразование sql = sql.encode(‘cp1251’) уже не нужно и является старым костылем. Но стало только хуже:

insert into users (FirstName,LastName,Job) values (‘Вася’, ‘Пупкин’, ‘Пользователь’) True
insert into users (FirstName,LastName,Job) values (‘Вася’, ‘Пупкин’, ‘Пользователь’) True

Traceback (most recent call last):
File “D:\Projects\Губкинский ГПК — НТК2 — Тренажер\tools\chek_mssql.py”, line 26, in
cur.execute(sql) #, params)
File “pymssql.pyx”, line 380, in pymssql.Cursor.execute (pymssql.c:4790)
self._source._conn.execute_query(operation)
File “_mssql.pyx”, line 787, in _mssql.MSSQLConnection.execute_query (_mssql.c:8225)
cpdef execute_query(self, query_string, params=None):
File “_mssql.pyx”, line 818, in _mssql.MSSQLConnection.execute_query (_mssql.c:8107)
self.format_and_run_query(query_string, params)
File “_mssql.pyx”, line 951, in _mssql.MSSQLConnection.format_and_run_query (_mssql.c:9302)
log(query_string)
UnicodeEncodeError: ‘ascii’ codec can’t encode characters in position 52-55: ordinal not in range(128)

. вместо русских букв — AutoBB

Сегодня важный день для проекта Joomla! Мы отмечаем два года напряженной работы наших добровольцев, решивших выпускать новую основную версию каждые два года. После большого количества обсуждений, спринтов по написанию кода и устранения ошибок этот день наконец настал и мы с гордостью объявляем о выпуске новой мажорной ( major ) версии Joomla 5.0, наряду с Joomla 4.4.

В Joomla Extensions Directory появился тег совместимости с Joomla 5.

Joomla-разработчики, проверившие совместимость своих расширений с Joomla 5 могут поставить галочку ��

JoomlaDay Spain, Madrid.

В Мадриде, Испания 5-6 октября 2023 года проходит Joomla Day — конференция, посвящённая как новичкам, так и профессионалам, работающим с Joomla.