|
переход на UNICODE
|
|||
---|---|---|---|
#18+
Не уверен, что правилъный форум нашел, тогда сорри за оффтопик. Естъ болъшой достаточно сложный программный комплекс: client/server, сервер держит информацию в базах данных - ORACLE, MS SQL Server. Серверная частъ написана на ANSI-C. Из-за интернационализации софта поставлена задача переходитъ на UNICODE. Опыта в таком совершенно нет, так что вопрос: с чего начатъ, где можно про это посмотретъ? Меня интересует в первую очередъ база и серверные процессы ( ANSI-C + Dynamic SQL + либо ODBC либо - для ORACLE - доморощенный похожий на ODBC интерфейс). Так с ходу: меняем типы в базе: например в ORACLE - VARCHAR2 -> NVARCHAR2. Переменные в программах -> wchar_t и все строковые-функции меняем на wc.... Но что-то всё оченъ просто получается... Наверно естъ какие-то подводные камни? Заранее спасибо за совет! ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2008, 19:43 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
Еще вероятно, вот это: mbctowc ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2008, 20:22 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
UNICODE? Серверная частъ написана на ANSI-C. К чему такие сложности ? почему не С++ ? а переход на юникод примерно так и выглядит. ну еще ресурсные файлы с локализациями подгружать ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2008, 07:46 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
Lepsik К чему такие сложности ? почему не С++ ? так исторически сложилось, уже не исправить :-). В общих чертах если: задача была поставлена, чтобы 99% без изменений было портируемо на Винду или на любой -NIX. А тут с C++ некоторые сложности, т.к. -NIX -NIXу рознь Lepsikну еще ресурсные файлы с локализациями подгружать вот тут бы поподробнее плиз. Стыдно признаться, но никогда этого не делал, тк. виндовый клиент программировался на Delphi, а оно само обо всём заботится, а в серверной части этой потребности никогда не возникало. Меня сейчас интересует только база и сервер (ANSI-C!). Может такое быть, что в этом случае и не будет нужно ресурсные файлы подгружать? Может ткнет ктонибудь в ссылочку, где об этом почитать (опять-таки для Винды и -NIX-а)? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.04.2008, 14:15 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
UNICODE?Может ткнет ктонибудь в ссылочку, где об этом почитать (опять-таки для Винды и -NIX-а)? тема в целом и этот мой последний вопрос актуальности не потеряли. Может выскажется кто-нибудь всё-таки! Заранее спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2008, 12:58 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
авторСерверная частъ написана на ANSI-C в каком смысле? - 3-е звено? - dll внутри СУБД? ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2008, 13:20 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
Petro123 - dll внутри СУБД? нет! Petro123 - 3-е звено? да, наверное можно так сказать, хотя этот термин вроде больше для WEB-технологий используют, а это классический client/server. Короче отдельные сервер-процессы с Dynamic SQL, с базой общаются либо через ODBC либо через самопальный имитирующий ODBC интерфейс (для ORACLE) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2008, 15:07 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
ну, классическая 3-х звенка (если процесс несерверный). И где тут UNICODE на среднем звене, если кодировка происходит при хранении (СУБД) и отображении (клиент)? ЗЫ. СУБД - на форум СУБД ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2008, 16:24 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
UNICODE? хотя этот термин вроде больше для WEB-технологий используют, -1 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2008, 16:26 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
Petro123ну, классическая 3-х звенка (если процесс несерверный). И где тут UNICODE на среднем звене, если кодировка происходит при хранении (СУБД) и отображении (клиент)? ну сервер читает что-то из базы во внутреннюю переменную, мы увеличиваем размер поля в базе и данные уже не влезают в переменную, так что надо в любом случае лезть в сервер. Может показаться, что серверу всё-равно читает он из базы UNICODE или нет. Но берём простой пример: в логике приложения стоит сравнение значения поля с буквой "А". Переходим в базе на UNICODE, увеличиваем формально значение принимающего массива в серверном процессе и больше ничего не меняем (оставляем прежнюю функцию сравнения строк). Будет это работать? Наверное нет! Так что по-моему более простой путь - то что я в первом посте предлагал. Кроме того есть еще фоновые процессы, которые что-то там себе делают вообще без клиента. Короче прояснить бы насчет этих упомянутых "ресурсных файлов с локализациями" , всё остальное вроде ясно... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2008, 17:33 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
UNICODE? пишет: > меняем типы в базе: например в ORACLE - VARCHAR2 -> NVARCHAR2. > Переменные в программах -> wchar_t и все строковые-функции меняем на wc.... > > Но что-то всё оченъ просто получается... Ну да, в общем-то просто. Сложность здесь заключается в маленьком слове ВСЕ. Плюс данные (только строковые, естественно) будут занимать в два раза больше места - к этому надо подготовиться. Наверно естъ какие-то подводные камни? В общем наверно и нет. Вам придется еще настраивать таблицы сортировок, их может не быть для юникода таких же, как и для неюникода. Клиентские приложения могут требовать больше памяти, могут возникать проблемы переполнения буферов, могут возникать проблемы из-за того, что понятия "длина буфера в байтах" и "длина строки в символах" путаются в ваших программах. Может возникать также проблемы с тем, что длину символов программы считают постоянной - 1 или 2 байта - а это не так. А, да, еще проблемы с signed и unsigned char могут быть, что приложения закладываются на что-то из двух. При переходе sign-ость символа может поменяться. Ну и наверное есть еще прочие вредные мелочи, которые "скрасят" вам жизнь. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2008, 18:50 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
UNICODE? Короче прояснить бы насчет этих упомянутых "ресурсных файлов с локализациями" , всё остальное вроде ясно... есть классический подход - все локализованные сообщения живут в ресурсных файлых. Когда вы проводите локализацию своего продукта, то создаете ресурсы для каждого языка. И при компиляции для определенного языка подключаете необходимый ресурс. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2008, 18:59 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
UNICODE? Petro123ну, классическая 3-х звенка (если процесс несерверный). И где тут UNICODE на среднем звене, если кодировка происходит при хранении (СУБД) и отображении (клиент)? ну сервер читает что-то из базы во внутреннюю переменную, мы увеличиваем размер поля в базе и данные уже не влезают в переменную, так что надо в любом случае лезть в сервер. Может показаться, что серверу всё-равно читает он из базы UNICODE или нет. Но берём простой пример: в логике приложения стоит сравнение значения поля с буквой "А". Переходим в базе на UNICODE, увеличиваем формально значение принимающего массива в серверном процессе и больше ничего не меняем (оставляем прежнюю функцию сравнения строк). Будет это работать? Наверное нет! Так что по-моему более простой путь - то что я в первом посте предлагал. Кроме того есть еще фоновые процессы, которые что-то там себе делают вообще без клиента. Короче прояснить бы насчет этих упомянутых "ресурсных файлов с локализациями" , всё остальное вроде ясно... совершенно не про то. Код на PSQL (Oracle) - надо будет править. Зачем править код : авторСерверная частъ написана на ANSI-C. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2008, 09:38 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
UNICODE? сервер держит информацию в базах данных - ORACLE, MS SQL Server. Серверная частъ написана на ANSI-C. Самописный Сервер что? Перекладывает инфу с обоих СУБД в свои переменные? А потом посылает клиентам? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2008, 09:41 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
Petro123 Самописный Сервер что? Перекладывает инфу с обоих СУБД в свои переменные? А потом посылает клиентам? да, сервер самописный. А база у заказчика всегда только одна, просто мы поддерживаем разные - ORACLE, SQL-Server,... Сервер данные обрабатывает и уже выжимку - готовые результаты - посылает клиенту. Или не посылает (фоновый процесс). PL/SQL-код пришлось бы переделывать, согласен, но его почти нет (так, в паре триггеров...). Вся программная логика в сервере, который посылает базе простые запросы через Dynamic SQL ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2008, 10:54 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
UNICODE? Petro123 Самописный Сервер что? Перекладывает инфу с обоих СУБД в свои переменные? А потом посылает клиентам? да, сервер самописный. А база у заказчика всегда только одна, просто мы поддерживаем разные - ORACLE, SQL-Server,... Сервер данные обрабатывает и уже выжимку - готовые результаты - посылает клиенту. Или не посылает (фоновый процесс). PL/SQL-код пришлось бы переделывать, согласен, но его почти нет (так, в паре триггеров...). Вся программная логика в сервере, который посылает базе простые запросы через Dynamic SQL вместо сервера, вам хватило бы провайдера ADO к разным СУБД. Это так, к слову. авторСервер данные обрабатывает и уже выжимку если так, то будете переписывать в 3-х местах (СУБД--среднее звено - клиенты) :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2008, 11:08 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
gpЕще вероятно, вот это: mbctowc а multibyte character - это не мертворожденное микрософтовское дитя? Что-то я посмотрел - оно не поддерживается ANSI C, т.е. только для винды? Тогда нельзя наверное на это закладываться, нужно чтобы код портировался без особых сложностей и под UNIX ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2008, 11:22 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
MasterZiv В общем наверно и нет. Вам придется еще настраивать таблицы сортировок, их может не быть для юникода таких же, как и для неюникода. Клиентские приложения могут требовать больше памяти, могут возникать проблемы переполнения буферов, могут возникать проблемы из-за того, что понятия "длина буфера в байтах" и "длина строки в символах" путаются в ваших программах. Может возникать также проблемы с тем, что длину символов программы считают постоянной - 1 или 2 байта - а это не так. А, да, еще проблемы с signed и unsigned char могут быть, что приложения закладываются на что-то из двух. При переходе sign-ость символа может поменяться. Ну и наверное есть еще прочие вредные мелочи, которые "скрасят" вам жизнь. Posted via ActualForum NNTP Server 1.4 тихо сам с собою я веду беседу... :-) отличный анализ MasterZiv, спасибо, очень помог оченить обьем проблем. Буду дальше думать а пока один вопрос: если работать с wide character, то наверное не будет проблемы с разной длиной символов, т.к.: Multibyte Characters and Wide Characters ... Wide character is defined in ISO C * that all characters are expressed in fixed width of bits. .... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2008, 18:11 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
> Буду дальше думать а пока один вопрос: если работать с wide character, > то наверное не будет проблемы с разной длиной символов, т.к.: Зависит от того, с какими языками будете работать символ в UTF-16 (он же wide character, хотя конечно кодировка может быт любой), может быть от 2 до 4 байт длинной. Большинство символов мира влазит в 2 байта, но не все. Так что проблема символов переменной длины не снимается с переходом на wchar_t, а откладывается. Правда я думаю (почти наверняка), что в библиотеках работы с UTF-16 уже почти нет мест, где была бы зашита константная длина символов. Но в коде вашего приложения все может быть. Почитайте, все же написано. http://www.unicode.org/faq/utf_bom.html#1 Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2008, 19:20 |
|
переход на UNICODE
|
|||
---|---|---|---|
#18+
UNICODE? Наверно естъ какие-то подводные камни? ИМХО, их более чем достаточно. Начнем с того, что существует ОДНА - поправьте меня, если неправ - библиотека визуальных компонент с поддержкой юникода (TNT UNICODE Library, недавно куплена TMS и стала платной). Кроме того, придется переписать весь код из сторонних/своих библиотек, работающий со строками.... Ну или ждать выхода Tiburon'a, в котором типы string и PChar станут широкими (опять же на мой взгляд - очень спорное решение, может возникнуть множество проблем при портировании). Далее, вам же потребуется перевести и справочную систему, к примеру. Из существующих форматов только MS Document Explorer поддерживает широкие строки. Так что задача несколько сложнее, чем кажется на первый взгляд. Хотя, как известно, боятся только глаза, а руки - они делают. :-)) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2008, 05:37 |
|
|
start [/forum/topic.php?fid=33&fpage=44&tid=1548787]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 10ms |
total: | 141ms |
0 / 0 |