BiTel

С 5.3 планируется всю работу с БД, а также почти все остальные взаимодействия перевести на UTF-8. Новые базы будут создаваться уже в UTF-8, старые без перекодировки работать тоже будут (ну планируется по крайней мере). Но свою тестовую мы хотим перекодировать для чистоты эксперимента. Так что новые разработки тестироваться будут уже как будто база в UTF-8.
Вопрос: будете ли вы перекодировать свою БД? Или оставите в 1251? И почему. И вообще какие мысли на этот счёт? Дискасс!

_________________
I'm clever. I've got a computer.

А можно услышать причины? Что изменится для конечного пользователя? Новые плюшки или что-то из-за чего стоит вообще это делать?
Так например переходя с 5.1 на 5.2 я знал что мне нужны шаблоны договора в новом FOP, модуль Inet в будущем ну и еще пара плюшек о которых я уже не упомню.

А тут что будет нового?

да, лень читать в интернете. я знаю что там будет поддерживаться больше кодировок и блаблабла, что символ в cp1251 весит 1 байт а в утф8 - 2 байта... Но, что это даст в данном конкретном случае?

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

давно пора, что тут обсуждать.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

Надеюсь это будет utf8_general_ci, т.к. согласно ману:




Доступ будет через SET NAMES? Смысл?



Да, буду. Да, это:

займет немного времени, но UTF-изация того стоит, ящитаю.



Люди наконец то смогут использовать родные языки.

Phricker писал(а):

символ в cp1251 весит 1 байт а в утф8 - 2 байта

Это, пожалуй, единственный геморрой.


Единственный, пока не ясный для меня момент - это кодировка динкода. Если БД будет в UTF, то код, наверное, тоже надо будет конвертить, т.к. русская "строка" в 1251 и "строка" в UTF (цифрам пофиг, речь про строчки поиска, например) - это разные строки, не?

Узнал что аллилуя пишется через два Л )))

А для меня родной - русский. Так что я просто присоединюсь ко всеобщей радости )

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

А насколько это критично? Плюсы, минусы? Какие могут быть проблемы, если не перекодировать?

эээээ, я тоже не в теме, для меня это очередной гемор при переходе

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Гемор конечно будет, но перекодировать базу на utf8 будем.
Главное продумать процесс перекодировки базы более детально.

Никто не говорит об обязательной конвертации . Хотели сделать поддержку utf8 для тех, кто хочет конвертировать, и для новых клиентов рекомендовать utf8.

Дин код итак уже в utf8 . Это не связано с кодировкой базы

Изменится то, что однобайтовые кодировки — зло. Потенциальный гемор с кодировками и кракозябрами в дальнейшем уменьшается на порядки.
Новых фишек это не даст, просто стандарт это и везде если utf-8, то это хорошо.

Символ кириллицы занимает 2 байта, да. Но русских символов относительно общего объёма БД там 1% наберётся ли? В основном размер то всякие логи, и прочая шняга. Ну вырастет размер базы на 0.5% — это некритично, имхо.

_________________
I'm clever. I've got a computer.

Не, обмен с сервером от кодировки базы мало зависит, драйвер и драйвер jdbc сам решает чего там как.
Т.е. у нас сейчас уже некоторые сидят на юникодной базе.

_________________
I'm clever. I've got a computer.

Пока не знаем, но скоро узнаем

_________________
I'm clever. I've got a computer.

Вопрос возник ещё такой интересный. Что делать с выгружаемыми файлами csv, например. С одной стороны однобайтовые кодировки там парфозны, с другой будет много вопросов про «неправильные шрифты в экселе» ©.

_________________
I'm clever. I've got a computer.

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

А это excell ? Или openoffice/libreoffice?. У меня винды под руками нет , поэтому не могу проверить в excell, почему то мне запомнилось что он не спрашивает кодировку при открытии csv-файлов . В openoffice/libreoffice то проблем нет - там сразу окошко вылетает с выбором кодировки при открытии.

поздно, я везде уже поменял

_________________
I'm clever. I've got a computer.

Это openoffice, но можу и на ёкселе проверить если надо.

О. ну таки здравый смысл восторжествовал! Одобрям-с целиком и полностью...
Менять однозначно. Особенно тем, у кого биллинг вертится на Linux...

А лучше всем и сразу, дабы вообще забыть тему кодировок как класс. Писать данные в базу можно будет на любом языке...

Минус, кроме дополнительной операции при апгрейде, база станет больше. Точнее та часть, что отвечает за договора. Это мизер, если у вас база хранит данные за 3-4 года...

В общем всё правильно делаете, ребята... Желаю вам удачи.

Я, к счастью или к сожалению, из телекома ушёл в разработку и уже наверное не ваш клиент. Но должен сказать, что BG-Billing оставил впечатление надежного, рабочего продукта. Особенно на фоне всяких UTM и LAN-billing'ов наших партнеров. За 6-7 лет эксплуатации серьезных сбоев по вине биллинга не было ни разу... Но backup'ы всё равно рулят... ))

_________________
С уважением...

У кого-нибудь есть успешный опыт конвертации? Есть какие-нибудь грабли?
Хочу попробовать конвертнуться в utf

Сервер 5.2 сборка 1443

У некоторых из наших клиентов база всегда была в utf-8, вроде всё работало. По сути никакой разницы биллингу нету, мы проверяли

_________________
I'm clever. I've got a computer.

А у меня сконвертить не получается
iconv спотыкается на символах 0x098:
iconv: illegal input sequence at position ...

а этих символов в дампе базы чуть менее чем много...

а как конвертитуете то?

_________________
I'm clever. I've got a computer.

Скорее всего так:

Но походу в дампе есть табличка с модулями лежащими в БД и на ней iconv спотыкается.

точно

P.S.
Базу я уже грохнул и создал изначально уникодовой

Делай дамп _без_ таблички с модулями - все прокатит.

Не факт.. Еще есть поля, где хранится xml целиком(счета в бухгалтерии, и другие места есть). Там 2 случая
1) xml уже в utf8, тогда конвертер ее испортит .
2) xml в cp1251, то конвертер поменяет ее содержимое на правильное , но не поменяет заголовок , поэтому при чтении они неправильно будет интерпретироваться, в этом случае заголовок отдельным запросом поправить нужно.

Еще есть способ через alter table ..convert .
http://deer.org.ua/2009/08/02/1/

Но с xml опять те же проблемы .

Кстати, хоть я и получил в итоге utf8 базу (пересоздав) и хоть я и коннекчусь к ней из сервера по utf8:
db.url=jdbc:mysql://127.0.0.1/bgbilling?useUnicode=true&characterEncoding=utf8&allowUrlInLocalInfile=...
и домашний кабинет открывается тоже в utf8, все равно иноязычные символы будучи вбиты - например - в новости, отображаются и клиенте и в домашнем кабинете как вопросики....