Поддерживает ли Process.StartInfo.Arguments строку UTF-8?

Question

Можете ли вы использовать строку UTF-8 в качестве аргументов для StartInfo?

Я пытаюсь передать UTF-8 (в данном случае японскую строку) приложению в качестве аргумента консоли.

Примерно так (это всего лишь пример! (Cmd.exe было бы специальным приложением))

var process = new System.Diagnostics.Process();
process.StartInfo.Arguments = "/K \"echo これはテストです\"";
process.StartInfo.FileName = "cmd.exe";
process.StartInfo.UseShellExecute = true;

process.Start();
process.WaitForExit();

При выполнении этого, похоже, теряется строка UTF-8, и все целевое приложение видит "echo ?????????"

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

Нужно ли делать что-то особенное, чтобы включить поддержку UTF-8 в аргументах, или это просто не поддерживается?

Answer 1

Программы получают командные строки в UTF-16, ту же кодировку как .NET строк:

Arguments = "/U /K \"echo これはテストです> output.txt\"";

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

Некоторые справочная информация: C или программа C ++, которые используют 'узкую' (системную кодовую страницу) точка входа, например, main(int argc, char** argv), а не 'широкие' (UTF-16) точек входа, wmain(int argc, wchar_t** argv), называется с помощью заглушки, которая преобразует командную строку к системной кодовой странице -. которая не может быть UTF-8

До сих пор лучший вариант, чтобы изменить программу, чтобы использовать широкий EntryPoint, и просто получить тот же UTF-16, как у вас в вашей .NET строки. Если это не представляется возможным, то один трюк вы можете попробовать, чтобы передать его в UTF-16, что командную строку при преобразовании в системной кодовой странице является UTF-8 для символов, которые вы хотите его использовать:

Arguments = Encoding.Default.GetString(Encoding.UTF8.GetBytes(args));

Caveat Coder: Не удивляйтесь, если это идет ужасно неправильно, на вашей или чужой машине, это зависит от каждого возможного байта, действующей в текущем кодовой системе, система кодовая не будучи отличается от того, когда была начата программа, программа, которую вы используете, не используя данные для любого кодирования функции, зависящей от Windows (те, с A, W суффиксом версии), и так далее.

Answer 2

Это полностью зависит от программы, которую вы пытаетесь запустить. Класс Process полностью поддерживает Unicode, как и операционная система. Но программа может быть старой и использовать 8-битные символы. Он будет использовать GetCommandLineA () для получения аргументов командной строки, ANSI-версию нативной функции API Unicode GetCommandLineW (). И это преобразует строку Unicode в 8-битные символы с использованием системной кодовой страницы по умолчанию, настроенной в панели управления + «Язык и региональные стандарты», «Язык для программ, не поддерживающих Юникод». WideCharToMultiByte () с использованием CP_ACP.

Если это не японская кодовая страница, этот перевод вызывает вопросительные знаки, так как японские глифы имеют код только в японской кодовой странице. Переключение системной кодовой страницы обычно не очень желательно для не говорящих по-японски. Utf8 определенно не будет работать, программа не будет ожидать их. Попробуйте запустить эту программу на виртуальной машине.

Answer 3

Я только что создал приложение Windows Forms, которое отображает Environment.CommandLine в RichTextBox, и строка отображалась правильно, поэтому можно передавать строку Unicode таким способом.

Я думаю, что моя ОС по умолчанию использует кодовую страницу 1252, поэтому я не могу отображать эти символы в командной строке даже при вставке аргументов, как вы это делали.

Answer 4

Используемые строки [System.String или обычный string] основаны на Unicode.Так что да, они могут поддерживать вышеупомянутую кодировку.

Посмотрите здесь

Вам необходимо проверить настройки, связанные с ОС (кодовые страницы, языки и т. Д.)