Постоянно возникает вопрос о проблеме с превращением русских символов в проекте в ?????????.
Не всегда помогает и установка чарсета в RUSSIAN_CHARSET.
Вот сейчас лично столкнулся с данной проблемой.
Как оказалось проблема решается довольно просто.
Корни ее в том, что при запуске на нерусской системе, уникод ресурсов нашей программы переводится в анси, согласно языку, установленному в системе.
Менять настройки системы некультурно.
Поэтому всего лишь нужно заставить нашу программу думать, что она запускается на русской системе.
Делается сия манипуляция элементарно.
1. Открываем наш dpr файл. (главный файл проекта, если кто не знает. Например Project1.dpr)
2. В Uses добавляем Windows.
3. Самой первой строчкой после 'begin' пишем:
Все. Программа будет культурно работать даже в китайской винде.
Главное не забывать добавлять эту строчку в каждый ваш новый проект.
Новый проект будет выглядеть примерно так:

Далее. У каждой формы нужно сменить Font. MS Sans Serif, поставленный там по умолчанию, не является юникодным шрифтом. Я рекомендую, например Tahoma.
При смене шрифта не забудьте установить Charset в RUSSIAN_CHARSET.

Во за это большое спасибо

А если у меня при запуске на нерусской винде все символы (включая английские) превращаются в ?????????. На русской винде всё ок. Твой метод поможет? Или тут что-то другое. (Delphi6)

Именно. Поэтому я и создал новую тему, чтобы она не терялась.
Достаточно вставить эту строчку и сделать у форм RUSSIAN_CHARSET.
Это лечит все проблемы.
Плюс к этому это решает вообще все проблемы с перекодированием из юникода в ANSI и наоборот.
А это уже затрагивает Delphi 1-7.
Не затрагивает только BDS2006 - там проблем нет изначально.

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 10:00

Лучше в FAQ добавить...

А фишку с копированием в буфер русских букв при английской расскладке клавиатуры и последующей вставкой ?????? ?? ?????? решает? Вроде там тоже проблемы с перекодированием в ANSI?

Просто супер!

Решает все проблемы, связанные с автоматическим конвертированием из юникода в анси и наоборот.
С буфером обмена по идее тоже должно все работать.
По крайней мере под WMVare у меня все корректно отработало.
Если кто столкнется с обратным - пишите.

мда... а я то думал тут чтото новое... Кстати, Snowy, разя я уже тут, спешу порадовать - с буфером обмена, тьфу-тьфу-тьфу, проблема исчезла.
зы: правда я винды переставил

А если в программе реализованна мультиязыковая поддержка, то это не повлияет на отображение других языков ?

Конечно повлияет. Наборы ведь разные.
Причем это НУЖНО делать. Иначе из всех языков будет работать только язык системы.
SetThreadLocale можно давать в любом месте программы. Она изменяет правила процесса юникодных перекодировок.
Для чего она дается в начале программы: чтобы формы при создании поднимали dfm в корректной кодировке.
Но можно дать SetThreadLocale и при смене языка, только код языка указать нужный. 1049 - это русский. Остальные коды можно посмотреть в MSDN или в реестре.
Также при смене языка потребуется сменить чарсет на всех формах.
Это уже сложней. Но что делать. Если этого не сделать, то вы хоть 10 раз выберите японский язык, но в индийской винде он никогда не сработает.
Так что SetThreadLocale и смену чарсета у форм нужно делать обязательно, иначе ваше "многоязыковое" приложение будет корректно отображать язык только в своей винде и только этот язык.

А если много окон то возможны глюки так как моё преложение на немецкой винде норамльно отображает только основную форму а все остальные с ?????? и это при том что я зделал всё что ты скозал и RUSSIAN_CHARSET на всех формах и SetThreadLocale(1049); прописал что делать

У меня в приложении десятки форм. Работают корректно.
Возможные причины:
1. У контролов не стоит ParentFont = true, соответственно не выставлен RUSSIAN_CHARSET.
2. Надписи в контролы добавляются динамически, а не в DisignTime. Ошибка может быть там.
3. Часть проекта (или весь) писалась не в русской винде. Или в русской, но с переключенными юникодными настройками. В данном случае в контролы проекта пропишется неверно закодированный юникод, который при декодировании будет некорректно декодирован. Я имею ввиду, что язык системы, в которой написан проект (или его часть) не 1049.
Что тут можно сделать...
Возьми приаттаченный файлик. При помощи него ты сможешь конвертнуть свои dfm файлы.

Присоединённый файл ( Кол-во скачиваний: 107 )
 DFMconv.zip 184,67 Kb

1. Всё стоит все контролы RUSSIAN_CHARSET
2. Нет надпись статична один раз написал и всё незименно
3. Всё писалось на одной ОС настройки неменялись лиш иногда менял раскладку клавиатуры Alt+Shift Ру En чтоб писать соответственно русским и английским но это я думаю не влияет

Фаил попробую и напешу о результате спасибо.

Практически было установлено, что если в настройках системы установлен английский язык для программ, не поддерживающих юникод, то ни один из этих способов не помогает. Проверено на WinXP SP2 Rus с измененными настройками, BDS2006 Update 2. 

Я и не говорил, что этот способ работает для BDS2006.
В заголовке темы указаны версии с 6-9.
С 7-кой проверял на виндах с 98 по 2005. Работает отлично.
2006 еще не исследовал. Все еще работаю на 7-ке.
Возможно там можно будет найти другое решение. 

Моя реплика относится к этой фразе:

Хотя насколько я помню в этой версии проблем с языками стало меньше, но не помню точно в каком месте  Но вот от неправильных юникодных настроек она, увы, не спасает. 

Не нашлось пока решения?

Использую Delphi 10Lite. Такая проблема: копирую в проводнике путь к файлу, вставляю в стандартный TEdit - кириллица заменяется на ????.
RUSSIAN_CHARSET и SetThreadLocale(1049) ничего не дают. В остальном проблем с русским нет.
Как побороть вставку?

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

alexeis1, 

Юзеру на это с высокой колокольни.



1. Если попробовать последовать сказанному - результат ничтожен.
2. Даже если бы так было - как объяснить юзеру что он должен танцевать с бубном и как ответить на его здоровое недоумение "зачем?". Ведь в тот же Блокнот все вставляется нормально - почему здесь криво?

forever, а все это я неправельно понял, я думал проблема при копировании текста в редактор кода делфи, просто и такая тоже встречается...

Добавлено @ 09:08 
Так это и на семерке тоже не помогает, тот же глюк.

alexeis1, 

Хм... У меня есть 7-е приложения (не мои) где это работает. В них тот же самый текст из буфера вставляется нормально, без ???. Исходников не имею, но авторы ссылаются именно на способ описанный здесь.

forever, 
Попробуйте вставлять текст из буфера обмена нажатием кнопки


Добавлено @ 10:56 
У меня сработало, если сработает и у вас, то можно будет сделать перехват
WM_TEXT всего приложения с тем чтобы исправить эту проблему для всех полей ввода сразу.

Кстати эту проблему действительно надо решать вручную, поскольку это глюк windows а не борланд! Я только что проверил вставку того же текста в поле едит созданое на MFC абсолютно тот же эффект, просто сам windows контрол edit не верно обрабатывает сообщение WM_PASTE, т.е. не верно конвертирует юникодную строку в ansi строку, вероятно он не использует для этого настройки локализации.

Добавлено @ 11:47 
От этой проблемы изначально избавлены юникодные версии контролов
Например вот такой Едит отлично вставляет русский текст

SetThreadLocale(1049) это также WinAPI комманда, а не борланда.
Мы говорим винде, что для юникодной конвертации мы хотим использовать русскую локаль.
В этом и смысл данной строки.

Замечено: если приложение использует XP манифест, то используется локаль, указанная там.
По умолчанию - это локаль 0 - нейтральная.
Пока этот вопрос не исследовал.

Я может ещё не проснулся, но не пойму о чём спор...

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

Тут такой полтергейст проявился: у товарища D7 и XP SP1, у меня D10 и XP SP2. Компилю прогу - в эдитах кириллица вставляется как ??????, отправляю exe ему - у него на системе кириллица вставляется в эдиты без проблем (в скомпиллированном у меня exe!). Неразбериху вносит обратный эксперимент: в скомпиллированный у него exe и у меня кириллица вставляется нормально. Где копать?

У меня точно такая же проблема. Глюк с искажением текста при копировании в буфер происходит на скомпилированных на моем рабочем ПК проектах. Причем если проект скомпилирован у меня, то искажение происходит на всех ПК. Если проект компилируется у моего коллеги, то проблем c искажением текста нет ни на одном ПК.


Скорее вcего так, вопрос в том, имеется ли возможность этот глюк преодолеть ?

Fedia, я же привел рабочий код вставки из буфера обмена от http://forum.vingrad.ru/index.php?showtopi...;st=15&hl=#
Напишите наследника в котором переопределена обработка WM_PASTE.

Либо пишите на апи с использованием юникодных компонентов

Я разобрался. Спросил у более опытного коллеги на работе, он удивился, что я до сих пор не в курсе, как эта проблема устраняется, и рассказал мне вот что:
1. Запускаем regedit.
2. Производим поиск значений параметров, содержащих 1252.
3. Заменяем эти значения на 1251.
4. Перезагружаемся.
5. Проводим тест и радуемся 

Fedia, 

Так это стародавняя проблема. Вот не думал, что она и здесь скажется. Но не нужно менять все вхождения 1252 - достаточно  
HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage\1252 заменить c_1252.nls на c_1251.nls


Радость омрачается тем, что на других компах скомпиллированные у меня проги ведут себя по прежнему: у кого были ??? - так и остались, у кого было нормально - тоже без изменений.

Fedia, Это решение давно извесно и было выложено н форуме, но это не выход. Тем более у него бывают побочные эффекты связаные с использованием других языков. У некоторых установлено по 3 языка и больше, а программа должна нормально функционировать на любой машине. Проблему предлогаю решить установкой локального (внутрипрограмного) перехватчика сообщеня WM_PASTE, который будет ловить сообщения до передачи их соотв. компоненту.

Как я понимаю, проблема так и не решена до конца.
Как же заставить текст правильно копироваться в буфер? Прога, скомпиленная в D6, имеет Memo с установленным RUSSIAN_CHARSET, и строка SetThreadLocale(1049) прописана. Однако, при запуске на 2000 винде скопированный ИЗ ОКНА (а не В ОКНО) программы текст вставляется в блокнот коряво. То же приложение нормально ведет себя на ХР (возможно, дело не в версиях винды, а в локализациях, но это не суть вопроса).

У меня тоже были проблемы с кодировкой при копировании в буфер.  Где-то нашел такой рецепт, у меня работает.


LangManager.LanguageID - это у меня переключатель языка интерфейса от DKLang.

  Пробовали при копировании и при вставке текста переключатель языков винды установить в положение "RU"? Это позволяет винде правильно определить таблицу перекодировки юникод -> Ansi. Иначе прийдется перехватывать вставку текста и самостоятельно конвертировать юникод в анси. Это вылечить невозможно, так этими вещами управляет винда, а не сам делфи. Тоже самое происходит, например, и в редакторе от Microsoft Visual C++ 6. Тут лечить нужно программистов Microsoft от криворукости. 

Хм, с RichEdit таких проблем не наблюдается. При этом никаких танцев с бубном, строкой SetThreadLocale(1049) и установкой RUSSIAN_CHARSET не требуется. Странно!

Romero, Ну он передает информацию в буфер обмена в формате RTF, где к для каждого символа можно узнать сопроводительную информацию, т.е. шрифт, размер, цвет, абзац, выравнивание, возможно еще и номер таблицы.

Да, занятная тема ;) В вашем полку прибыло ;) 
Вобщем приведу сразу код:

Суть этой функции в обработчике попуп-меню окна лога закинуть в буфер обмена выделенное в VTV нод с событием. Как видно из кода, я из формы с эбаутом достаю версию и время билда, он отображается нормально! А вот когда копируется в буфер обмена, то все его русские буквы становятся, даже не вопросами, а какиме-то крякозябрами ;(
Этот же код, на другой ЭВМ отрабатывает на ура, есно после сборки на той машине.

Все что оговаривалось выше не помогает, а правка в реестре мне не подойдет, т.к. я пишу мультиязычную программу. Пока вот хочу попробовать метод от mai62, но вдруг еще какие-нибудь мысли есть?

Это сообщение отредактировал(а) EvilsInterrupt - 13.11.2007, 19:53

Все, проблему решил, увидел строки в DRKB:

Сразу стало понятно, что товарищь mai62 предложил хороший способ ;) Спасибо

http://forum.vingrad.ru/forum/topic-180473.html

Добавлено через 9 минут и 1 секунду

а вот у меня какраз токи в 2006. Messegedlg показывает вопросы и что интересно из 50 компьютеролв тока на одном... 

Может там винда не русская стоит?

aktuba, Можешь подскажешь выход из такой ситуации:
Если у меня выбрана русская раскладка, то в буфер обмена копируется и последующая вставка куда-либо(к примеру сюда в окно поста сообщения на форум), то все отображается отлично и никакой крякозябрины. Но если же я выберу английскую раскладку, то после копирования в буфер и последующей вствки куда-либо(к примеру сюда в окно поста сообщения на форум), то крякозябры ;(

Я конечно догадываюсь,что англичание не должны шарить о существовании русского языка. Но как пользователю же пофиг на это! ;)
Может имеет смысл насильно перекодировать на русский в самом буфере обмена, если конечно выбран русский язык или какой-либо другой, к примеру китайский ?

Проблема решена, MetalFan подсказал.

ведь по идее:

А подскажите такой момент пожалуста.
Есть сервер с DB2 UDB 8.2. Кодировка стоит 1251 и в программе весь русский отображается прекрасно на всех компьютера без исключений, но есть 2 компа, на которых стоит Novel-клиент. На них весь русский язык отображается нормально, кроме выгрузки данных в Excel. Сам файл-шаблон отображается нормально, а вот выгруженные данные отображаются непонятной кодировкой (я так и не выяснил какая кодировка). При использовании Shell API и выборе директории с русским названием появляется та же непонятная кодировка.
Может кто знает как исправить это в программе?

Если в Windows открыть Панель управления, а там апплет "Язык и региональные стандарты", то на закладке "Дополнительно" можно лицезреть кодовую страницу для неюникодных программ. В нешем случае там всегда установлен "Русский (Россия)".

Так вот. Как узнать, какая кодовая страница установлена на данный момент в системе?
Есть примеры в интернете, которые позволяют узнать активный язык(раскладку клавиатуры), но это не то. В какую сторону копать?

В общем это связано с тем, что перед началом какой-либо обработки текста нужно установить какую-либо активную раскладку клавиатуры. Для русского языка это:

А если винда, например, чешская, то нужно активировать чешский язык. Т.е. вместо '00000419' нужно подставить код чешского языка.

Добавлено через 4 минуты и 9 секунд

можно ещё


Добавлено через 9 минут и 16 секунд
О, нашёл

Теперь при старте программы достаточно выполнить такую процедуру:

Я вот свою игрушку отюникодить пытаюсь. Пока безрезультатно.  Проверять приходится перестройкой Windows с Russian на любую другую кодировку. Выходит много чего, от ошибок баз, до неверных отображений символов (вопросы)

Версия: Delphi XE

Используются компоненты для работы с БД (AdoTable, AdoQuery)

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


Это сообщение отредактировал(а) PsiMagistr - 11.8.2011, 09:45

И в чём вопрос?

Akella, да вопрос прост. 

как ее заюникодить все-таки?

У меня встречный вопрос: а как вы умудрились сделать обратное?

Что именно и откель юникодить?

Мне нужен русский интерфейс на любой винде.

Ваши предложения, господа.

PsiMagistr напрягая телепатические возможности предположу что у вас таблицы в БД в Ansi кодировке и осуществляется преобразование Ansi -> Unicode с неправильной таблицей символов, точнее говоря с кодовой таблицей по умолчанию, которая может не совпадать с кириллической. 

Alexeis, И каков выход?

Перевести все на юникод.

А русский шрифт-то на этой винде есть?

Добавлено через 5 минут и 24 секунды


Какие могут быть предложения?

Вам же сказали, что Delphi 2009 и выше (включая Delphi XE) ситуация по умолчанию: ваша программа одинаково работает на любой системе. При условии, что в системе стоит шрифт с кириллицей. Скажем, unicode-шрифт.

Если же у вас не так - это значит, что вы у себя в коде что-то делаете не так.

Внимание, вопрос: КАК мы можем это знать?

Мы можем лишь угадывать, чем (гаданием) и занимается Alexeis в своём последнем посте.

  Да вроде как шрифты по умолчанию и так юникодные. 

  Если такие дело в БД, то наилучшим решением будет конвертация таблиц в utf8. Так чтобы при загрузке строк не требовалось кодовых таблиц. Если такое решение не подходит то пробуйте приведенный выше вариант с SetThreadLocale . 

На старых системах Unicode шрифты ставились только с офисом или расширенной поддержкой символов. Т.е. по дефолту их может не быть.

Использовать юникодную среду разработки D2009+ или Юникодные компоненты, aka TNT или TMS

Добавлено @ 20:19

Использовать нормальные СУБД, а не какую-то там недоСУБД.