Комстрока в винде
Alexey Korop
Обнаружил, что для консольного приложения под Win32 комстрока передается в
кодировке ANSI, что, как правило, неправильно. Вскрытие показало, что это
происходит в результате использования в RTL (конкретно - в
\VP21\SOURCE\RTL\VPSYSW32.PAS) виндовой функции GetCommandLine (фактически -
GetCommandLineA).
Самое смешное, что там же рядом лежит и корректное решение этой проблемы:
использовать функцию GetCommandLineW, возвращающую комстроку в ее первозданном
юникодном виде, и затем перекодировать из юникода в текущую кодировку консоли.
Hо это решение зачем-то запрятано под {$IFDEF SysCmdlnUniCode}, хотя оно без
проблем работает под всем версиями винды (я проверил под Win95 OSR2, NT 4 SP 6
и XP SP2). Зачем надо было правильное и беспроблемное решение прятать, а
неправильное - включать по умолчанию, я не понимаю.
В общем, оргвывод: в VPSYSW32.PAS активизировать SysCmdlnUniCode и
пересобрать RTL.
С уважением, Alexey.
...В действительности всё совсем не так, как на самом деле.
Sp0Raw
AK> передается в кодировке ANSI, что, как правило, неправильно. Вскрытие
AK> показало, что это происходит в результате использования в RTL
AK> (конкретно - в \VP21\SOURCE\RTL\VPSYSW32.PAS) виндовой функции
AK> GetCommandLine (фактически - GetCommandLineA).
AK> Самое смешное, что там же рядом лежит и корректное решение этой
AK> проблемы: использовать функцию GetCommandLineW, возвращающую комстроку
AK> в ее первозданном юникодном виде, и затем перекодировать из юникода в
AK> текущую кодировку консоли. Hо это решение зачем-то запрятано под
AK> {$IFDEF SysCmdlnUniCode}, хотя оно без проблем работает под всем
AK> версиями винды (я проверил под Win95 OSR2, NT 4 SP 6 и XP SP2). Зачем
AK> надо было правильное и беспроблемное решение прятать, а неправильное -
AK> включать по умолчанию, я не понимаю.
AK> В общем, оргвывод: в VPSYSW32.PAS активизировать SysCmdlnUniCode и
AK> пересобрать RTL.
Затем, что по умолчанию приложения делаются не нормальные Unicode'ные, а
обычные ANSI.
Alexey Korop
15.12.2006 в 00:26:00 Sp0Raw написал к Alexey Korop:
AK>> Зачем надо было правильное и беспроблемное решение прятать, а
AK>> неправильное - включать по умолчанию, я не понимаю. В общем,
AK>> оргвывод: в VPSYSW32.PAS активизировать SysCmdlnUniCode и
AK>> пересобрать RTL.
S> Затем, что по умолчанию приложения делаются не нормальные Unicode'ные,
S> а обычные ANSI.
Я не понял, что ты хотел сказать, но попробую возразить :)
В ANSI обычно работают гуёвые приложения, а для консольных типично OEM. Так
вот, если активизировать SysCmdlnUniCode, то проблем нет нигде: для гуёвых
приложение комстрока получается в ANSI, а для консольных - в текущей кодировке
консоли, то есть, нормально в OEM.
А юникодные приложения никакой поддержки в VP не имеют, в том числе, и в
части комстроки.
Так вот, повторяю. Для *любого* типа виндового приложения с *однобайтной*
кодировкой целесообразно активизировать SysCmdlnUniCode.
Alexey Fayans
On 16 Dec 2006 09:37 you wrote Sp0Raw:
S>> Затем, что по умолчанию приложения делаются не нормальные
S>> Unicode'ные, а обычные ANSI.
AK> Я не понял, что ты хотел сказать, но попробую возразить :)
AK> В ANSI обычно работают гуёвые приложения, а для консольных типично
AK> OEM. Так вот, если активизировать SysCmdlnUniCode, то проблем нет
AK> нигде: для гуёвых приложение комстрока получается в ANSI, а для
AK> консольных - в текущей кодировке консоли, то есть, нормально в OEM.
AK> А юникодные приложения никакой поддержки в VP не имеют, в том
AK> числе, и в части комстроки.
AK> Так вот, повторяю. Для *любого* типа виндового приложения с
AK> *однобайтной* кодировкой целесообразно активизировать SysCmdlnUniCode.
Я это сделал черт знает как давно уже... :) Когда в самый первый раз
скомпиленная в VP программа отказалась понимать русскоязычные параметры
комстроки. Кстати, FreePascal их до сих пор не понимает, AFAIK. :)