Почему ломаются аргументы ── правила аргументов командной строки Windows

«В тестах прошло, а на ПК, где в пути есть пробел, внешнее средство не запускается.» «Перевёл C:\data\ — слилось со следующим аргументом в один.» «Перевёл JSON аргументом, кавычки пропали, другая сторона не разобрала.» Аварии, которые снова и снова бывают в коде, запускающем дочерние процессы. Причина почти никогда не в логике, а в записи без предпосылки: в Windows нет механизма передать «массив аргументов».

CreateProcess, которым в Windows создают процесс, принимает одну строку lpCommandLine. Как бы аккуратно вызывающая сторона ни готовила массив, на границе ОС он всегда склеивается в одну, и принимающая сторона делит снова. Правила деления задаёт среда выполнения принимающей стороны: среда выполнения C, CommandLineToArgvW, среда выполнения .NET, cmd.exe — разный код. Передать аргументы — собрать строку, которую парсер другой стороны разрежет как было.

Статья смотрит не со стороны сценариев PowerShell, а со стороны кода Win32 и .NET, который запускает дочерний процесс: где строка склеивается, где делится, каким правилам следует. Сторону PowerShell (смена передачи аргументов в 7.3, --%, $PSNativeCommandArgumentPassing) разбирает «Как правильно вызывать внешний exe из PowerShell»; здесь копаем слой ниже.

flowchart TB
    accTitle: Слой, который разбирает статья
    accDescr: Передачу аргументов PowerShell разбирает другая статья; эта берёт слой ниже — от CreateProcess Win32 и ProcessStartInfo .NET до парсера чужого exe
    ps["Передача аргументов PowerShell (другая статья)"] --> net["ProcessStartInfo .NET"]
    net --> win["CreateProcessW Win32"]
    win --> str["Одна строка командной строки"]
    str --> parser["Парсер чужого exe"]
    net -.->|"Область этой статьи"| parser

Рис. 1: Под PowerShell — слои .NET и Win32; с какого бы ни запускать, в конце одна строка. Статья разбирает правила этого слоя.

1. Сначала выводы

• Процессу Windows массив аргументов не передают. Одна строка, переданная в CreateProcess, доходит до нового процесса (полное имя ведущего исполняемого файла ОС иногда дополняет), GetCommandLineW её возвращает. argv собирает сама принимающая сторона.^{1 2}
• Тело правил деления — три. Делить по пробелу и табуляции, диапазон в двойных кавычках не делить, обратную косую считать особой только когда сразу за ней двойная кавычка (2n — n плюс открытие или закрытие кавычек, 2n+1 — n плюс кавычка как символ).^{3 4}
• Только ведущий токен (argv[0], имя исполняемого файла) — другое правило: обернуть кавычками можно, экранирование обратной косой не действует. Если lpApplicationName — NULL, толкование пути с пробелами двусмысленно, сначала пробуют C:\Program.exe.^{1 4}
• На стороне сборки достаточно одного: «если есть пробел или кавычка или пустая строка — обернуть кавычками, обратные косые сразу перед кавычкой и в конце удвоить, кавычку сделать \"». С .NET Core 2.1 это делает ProcessStartInfo.ArgumentList.^{5 6}
• Форму со двумя смежными кавычками внутри непустого аргумента ("ab""c") приёмники толкуют по-разному — не порождать. "" как пустой аргумент — другое и верно. cmd.exe и пакетные файлы вне этих правил, поэтому недоверенные значения через них не пускать.^{6 7}
• Предел lpCommandLine — 32 767 единиц кода UTF-16 (включая завершающий нуль; символы вроде эмодзи, суррогатная пара, считают за два), cmd.exe — 8 191 символ. Если близко к пределу — переключаться на файл ответов, только если другая сторона умеет читать @file (или её можно так поправить).^{1 8}

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 28, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Массива аргументов нет ── CreateProcess и одна строка

Второй аргумент CreateProcessW, lpCommandLine, — одна оканчивающаяся нулём строка, в которой имя исполняемого файла и аргументы стоят через пробел. Верхняя граница длины — 32 767 единиц кода UTF-16 включая завершающий нуль (число wchar_t; символы вроде эмодзи, суррогатная пара, тратят два на один видимый символ, поэтому заранее проверять «на глаз» нельзя). Юникодная версия эту строку может переписать, поэтому литерал или буфер const могут дать нарушение доступа.¹

Эта строка как есть уходит в параметры нового процесса; дочерний забирает её GetCommandLineW. ОС иногда дополняет полное имя ведущего исполняемого файла, поэтому строка, которую видит дочерний, с переданной родителем совпадает не полностью.² lpCmdLine, который получает WinMain GUI-приложения, — эта строка без имени программы.⁹

flowchart TB
    accTitle: Путь, которым аргументы доходят до дочернего процесса
    accDescr: Массив аргументов вызывающей стороны в lpCommandLine CreateProcess склеивается в одну строку и уходит в новый процесс; дочерний делит строку, забранную GetCommandLineW, своим парсером и собирает argv
    arr["Массив аргументов вызывающей стороны"] --> join["Склеить в одну строку (ответственность вызывающей стороны)"]
    join --> cp["lpCommandLine CreateProcessW"]
    cp --> peb["Параметры нового процесса"]
    peb --> gcl["Строка, которую возвращает GetCommandLineW"]
    gcl --> parse["Парсер принимающей стороны делит"]
    parse --> argv["Массив argv / args"]

Рис. 2: Массив границу не пересекает. Склейка — ответственность вызывающей стороны, деление — принимающей; исходный массив восстанавливается, только когда правила совпадают.

Важно: склейка и деление идут в разных процессах, разным кодом. Вызывающая сторона не соберёт верно, не зная, «чем другая сторона делит»; принимающая сторона не знает, «как склеили». В ОС линии Unix в execve массив передают как есть, этой задачи нет. Предпосылка, свойственная Windows, но висящая на каждом запуске процесса.

3. Кто делит ── три парсера

Код, которым принимающая сторона режет строку в argv, в основном три.

Код деления — три линии: стартовый код среды выполнения C, CommandLineToArgvW, собственный код деления среды выполнения .NET. Скелет правил один, код не тот же. Приложение .NET, запущенное через apphost или dotnet.exe, по сути делится правилами первой линии (стартовый код среды выполнения C), потому что сам хост — программа wmain на среде выполнения C MSVC. В исходниках среды выполнения .NET остаётся комментарий: CommandLineToArgvW чуть иначе себя ведёт, не используем.¹² Разница вылезает на краях вроде обращения с ""; в повседневных аргументах почти не наступают, но «одни правила, значит всё пройдёт» на краю даёт аварию.

flowchart TB
    accTitle: Три парсера принимающей стороны
    accDescr: Одну строку GetCommandLineW делят стартовый код среды выполнения C в C/C++, CommandLineToArgvW при прямом Win32, собственный код деления среды выполнения у .NET, загруженного как размещённая библиотека; скелет правил один, реализации разные. Обычное приложение .NET через apphost или dotnet.exe получает массив, который разделил стартовый код среды выполнения C хоста
    s["Строка GetCommandLineW"] --> crt["Стартовый код среды выполнения C"]
    s --> api["CommandLineToArgvW"]
    s --> net["Собственный код деления .NET (при загрузке хостом)"]
    crt --> app["То же у .NET через apphost / dotnet.exe"]
    crt --> same["Скелет правил один, реализации разные"]
    api --> same
    net --> same

Рис. 3: Код деления — три линии. Приложение .NET через apphost или dotnet.exe получает массив, который разделил стартовый код среды выполнения C хоста; собственный код деления среды выполнения — запасной путь конфигурации размещённой библиотеки. Снаружи не видно, на чём чужой exe, поэтому практическое решение — собирать строку, которая даёт один результат у любого.

У Main(string[] args) .NET в args имени программы нет; в первом элементе Environment.GetCommandLineArgs() имя программы есть. То же место, что argv[0] C/C++, — второе.¹³ При обычном запуске параметры хоста и путь приложения (dotnet.exe и app.dll) вроде dotnet app.dll x хост снимает, в args у Main доходит только x.¹⁴ GetCommandLineArgs() возвращает массив, в начало которого среда выполнения при запуске добавила имя программы (путь app.dll и x).¹¹ Собственный код деления среды выполнения делит GetCommandLineW только в конфигурации размещённой библиотеки, которая не принимает аргументы запуска; в конфигурации, где машинный хост передаёт свои argc/argv и вызывает Main, args у Main — значения, которые передал хост.

4. Правила деления ── пробел, кавычки, обратная косая

Правила, общие трём парсерам, для argv[1] и дальше.^{3 4}

1. Аргументы делят пробелом или табуляцией.
2. Диапазон в двойных кавычках — один аргумент, даже с пробелами. Сами кавычки в аргумент не входят. Кавычки можно начать с середины аргумента; если строка кончилась, не закрыв, до конца — последний аргумент.
3. Обратная косая — обычный символ. Особое правило только когда сразу за ней двойная кавычка.
4. Если перед двойной кавычкой 2n обратных косых — выводят n обратных косых, кавычка работает как «начало/конец обёртки».
5. Если перед двойной кавычкой 2n+1 обратных косых — выводят n обратных косых и кавычку как символ, состояние обёртки не меняется.
6. Карет (^) не символ экранирования (это правило cmd.exe, не парсера).

У парсера один бит состояния «внутри кавычек»; кавычка его переворачивает, строку читают слева направо. Делить ли по пробелу, решает это состояние.

flowchart TB
    accTitle: Поток деления: переключают «внутри или снаружи кавычек»
    accDescr: Снаружи кавычек парсер делит аргументы по пробелу; встретив кавычку, входит внутрь и пробел считает частью аргумента; снова встретив кавычку, выходит. Обратная косая особая, только когда сразу за ней кавычка
    out["Снаружи кавычек: делить по пробелу"] -->|"Встретили кавычку"| inq["Внутри кавычек: пробел тоже часть аргумента"]
    inq -->|"Встретили кавычку"| out
    out -->|"Сразу за обратной косой кавычка"| bs["Применить правило обратной косой"]
    inq -->|"Сразу за обратной косой кавычка"| bs
    bs -->|"2n: вывести n и открыть/закрыть"| toggle["Перевернуть состояние обёртки"]
    bs -->|"2n+1: вывести n и кавычку как символ"| lit["Состояние обёртки не менять"]

Рис. 4: Тело деления — один бит «внутри кавычек или снаружи» и число обратных косых сразу перед кавычкой.

Правила надёжнее смотреть соответствием ввода и вывода, чем заучивать текстом.

Пятая строка — лицо «перевёл C:\data\ — слилось со следующим аргументом в один» из начала. В момент, когда конечную обратную косую пути обернули кавычками, закрывающая кавычка становится символом, обёртка не закрывается.

flowchart TB
    accTitle: Как конечная обратная косая проглатывает следующий аргумент
    accDescr: Если путь с конечной обратной косой обернуть кавычками, закрывающая кавычка стоит сразу после одной обратной косой и толкуется как кавычка-символ; обёртка не закрывается и следующий аргумент читается как один
    a["В конце пути в кавычках одна обратная косая"] --> b["Перед закрывающей кавычкой нечётное число"]
    b --> c["Кавычка выводится как символ, обёртка не закрывается"]
    c --> d["Дальнейшие пробелы разделителями не становятся"]
    d --> e["До следующего аргумента доходит как один"]
    a -.->|"Удвоить обратные косые"| ok["Обёртка закрывается, аргументы разделяются"]

Рис. 5: Зачем «конечную обратную косую удваивать». Кавычки, написанные без знания правила, ломаются на конце пути.

Где реализации расходятся: две кавычки подряд внутри обёртки

В правилах среды выполнения C MSVC есть ещё пункт: «две подряд кавычки внутри строки в кавычках считают одной кавычкой» (форма вроде "ab""c", не "" пустого аргумента).⁴ В официальных правилах CommandLineToArgvW этого пункта нет, и код сборки среды выполнения .NET явно избегает порождать эту форму, потому что «кавычка вслед за закрывающей до и после VC 2008 толкуется по-разному».⁶

Принимающей стороне достаточно знать «такой ввод бывает». Собирающая сторона, чтобы передать кавычку как символ, пусть использует только форму \". Тогда любой парсер даёт один результат.

5. argv[0] — другое правило ── lpApplicationName и проблема Program.exe

Ведущий токен, то есть имя исполняемого файла, вне правил выше. Предпосылка — строка, допустимая как путь файловой системы: обернуть кавычками и включить пробел можно, правило экранирования обратной косой не применяют. Способа включить саму кавычку в argv[0] нет.^{4 3} Код сборки .NET для первого элемента тоже другой: «если есть пробел — только обернуть кавычками; если есть кавычка — исключение».⁶

На вызывающей стороне проблема — поведение, когда lpApplicationName у CreateProcess — NULL. Тогда исполняемый модуль угадывают по ведущему токену, делённому по пробелам, из lpCommandLine. Если в пути есть пробел, кандидатов несколько, ОС пробует от короткого к длинному.¹

flowchart TB
    accTitle: Порядок угадывания исполняемого файла, когда lpApplicationName — NULL
    accDescr: Без кавычек строка C:\Program Files\MyApp -L -S заставляет CreateProcess сначала проверить C:\Program.exe, затем C:\Program Files\MyApp.exe; если C:\Program.exe есть, запускается он
    in["Путь без кавычек (с пробелом) в lpCommandLine"] --> t1["Кандидат 1: пробуют C:\Program.exe"]
    t1 -->|"Есть"| bad["Запускается не тот исполняемый файл"]
    t1 -->|"Нет"| t2["Кандидат 2: пробуют C:\Program Files\MyApp.exe"]
    t2 --> ok["Запускается задуманный исполняемый файл"]
    in -.->|"Передать lpApplicationName или обернуть начало кавычками"| ok

Рис. 6: Путь с пробелом без кавычек в начале пробуют от короткого кандидата. Официальная документация прямо пишет «опасно».

Официальная документация прямо пишет: если положить C:\Program.exe, вместо задуманного приложения запустится он; не передавать NULL в lpApplicationName, а если передаёте — обернуть ведущий путь кавычками.¹ На практике делают оба. Полный путь исполняемого файла в lpApplicationName, тот же путь в кавычках в начале lpCommandLine. Когда переданы оба, исполняемый модуль задаёт lpApplicationName, argv[0] дочернего — ведущий токен lpCommandLine. По обычаю их совмещают, иначе ломается код, который свой путь берёт из argv[0]. Свой путь надёжно брать GetModuleFileNameW.⁴

flowchart TB
    accTitle: Как решаются исполняемый модуль и argv[0]
    accDescr: Если переданы и lpApplicationName, и lpCommandLine, исполняемый модуль задаёт lpApplicationName, argv[0] дочернего — ведущий токен lpCommandLine. Если они разъедутся, ломается код, который свой путь берёт из argv[0]; свой путь берут GetModuleFileNameW
    app["lpApplicationName"] --> run["Исполняемый модуль"]
    cl["Ведущий токен lpCommandLine"] --> a0["argv[0] дочернего"]
    a0 -.->|"Разъедутся — сломается"| self["Код, который свой путь берёт из argv[0]"]
    self -.->|"Вместо этого"| gmf["GetModuleFileNameW"]

Рис. 7: «Что исполняется» и «что в argv[0]» решаются раздельно. Дизайн «свой путь из argv[0]» на этом разделении не стоит.

Ещё: когда lpApplicationName — NULL, часть имени исполняемого файла в lpCommandLine ограничена MAX_PATH.¹ Длинные пути — в «MAX_PATH и ловушки путей и имён файлов в Windows — лимит 260 символов, зарезервированные имена, точка в конце, регистр».

6. Правила стороны сборки ── одной функции достаточно

Зная правила деления, «строку, которую другая сторона разрежет как было», получают, идя в обратную сторону. Для каждого аргумента с argv[1] дальше делают следующее.⁶

1. Если не пустая строка и нет ни пробела, ни кавычки — ставить как есть.
2. Иначе обернуть целиком кавычками. Внутри обёртки:
   • k обратных косых сразу перед кавычкой сделать 2k+1, затем кавычку (нечётное — «кавычка как символ»);
   • k обратных косых в конце сделать 2k (сразу перед закрывающей кавычкой чётное — «конец обёртки»);
   • остальные обратные косые как есть.
3. Пустую строку ставить как "".

flowchart TB
    accTitle: Поток решения, как собрать один аргумент
    accDescr: Если аргумент не пуст и нет ни пробела, ни кавычки — ставить как есть; иначе обернуть кавычками, обратные косые сразу перед кавычкой удвоить плюс одна, конечные удвоить, кавычку закрыть с обратной косой
    s["Принять один аргумент"] --> q{"Пуст или есть пробел или кавычка?"}
    q -->|"Нет"| raw["Ставить как есть"]
    q -->|"Да"| open["Кавычка в начало"]
    open --> scan["Сканировать слева"]
    scan --> bq["k обратных косых сразу перед кавычкой → 2k+1"]
    scan --> be["k обратных косых в конце → 2k"]
    scan --> other["Остальное как есть"]
    bq --> close["Кавычка в конец"]
    be --> close
    other --> close

Рис. 8: Сборка — обратное отображение правил деления. Ветвей три; достаточно поправить число обратных косых в конце и сразу перед кавычкой — и любая строка без NUL, укладывающаяся в предел lpCommandLine (32 767 единиц кода UTF-16 включая завершающий нуль), круговым путём проходит, если принимающая сторона делит широкими символами теми же правилами, что CommandLineToArgvW, среда выполнения C и .NET (глава 4) (цель со своей грамматикой сырой командной строки или парсер оболочки посередине — вне области) и не включила раскрытие подстановочных знаков вроде wsetargv.obj (командная строка — строка с завершающим нулём, NUL принципиально не передать; у цели с раскрытием подстановочных знаков аргумент с * или ? заменяется именем файла; глава 8; строка сверх предела CreateProcessW не примет; глава 10).

Это правило прямо отражает асимметрию «обратная косая особая только сразу перед кавычкой». Обратные косые-разделители пути механически удваивать не нужно: трогают только сразу перед кавычкой и в конце.

7. Реализация в .NET ── ArgumentList и Arguments

С .NET Core 2.1 у ProcessStartInfo есть ArgumentList, который берёт эту сборку на себя. Один элемент — один аргумент; добавленную строку заранее экранировать не нужно; в момент Process.Start .NET внутри собирает одну строку и отдаёт ОС.⁵

var psi = new ProcessStartInfo
{
    FileName = @"C:\Program Files\MyTool\convert.exe",
    UseShellExecute = false,
};
psi.ArgumentList.Add("--input");
psi.ArgumentList.Add(inputPath);      // можно с пробелом, конечной обратной косой, кавычками
psi.ArgumentList.Add("--output");
psi.ArgumentList.Add(outputPath);
psi.ArgumentList.Add("--label");
psi.ArgumentList.Add("");             // пустой аргумент тоже верно уйдёт как ""

using var proc = Process.Start(psi)
    ?? throw new InvalidOperationException("Process.Start вернул null");
proc.WaitForExit();
if (proc.ExitCode != 0)
    throw new InvalidOperationException($"convert.exe завершился неудачей (ExitCode={proc.ExitCode})");

Arguments — свойство, которое передаёт собранную вами одну строку как есть. Они независимы: когда пользуются одним, другое должно быть пустым.¹⁶ Официальная документация тоже советует ArgumentList, если в кавычках не уверены.⁵

flowchart TB
    accTitle: Где ArgumentList и Arguments становятся строкой
    accDescr: ArgumentList — .NET экранирует по элементам, склеивает в одну строку и передаёт в CreateProcess; Arguments — строку, собранную вызывающей стороной, передаёт как есть. К ОС в обоих случаях доходит одна строка
    al["ArgumentList (1 элемент = 1 аргумент)"] --> esc[".NET экранирует по элементам и склеивает"]
    ar["Arguments (одна строка, собранная вами)"] --> pass["Как есть"]
    esc --> cmd["Одна строка командной строки"]
    pass --> cmd
    cmd --> cp["CreateProcess"]

Рис. 9: Что ни взять, ОС получает одну строку. Разница только в «кто собирает»; ArgumentList отдаёт тому, кто знает правила.

Код сборки ArgumentList — сами правила главы 6. Если не пуст и нет ни пробела, ни кавычки — как есть; иначе обернуть кавычками, обратные косые сразу перед кавычкой удвоить плюс одна, конечные удвоить, перед кавычкой всегда обратная косая. Форму смежных кавычек внутри непустого аргумента не порождает. Только пустой аргумент ставят как "" — и это верно.⁶

На .NET Framework собирают сами

ArgumentList — API с .NET Core 2.1; у ProcessStartInfo .NET Framework его нет.⁵ В приложении .NET Framework 4.8 и внутренних средствах на нём правила главы 6 пишут сами и передают в Arguments.

// Под .NET Framework. Собрать одну строку для ProcessStartInfo.Arguments.
// Правила те же, что внутри ProcessStartInfo.ArgumentList.
static string BuildArguments(IEnumerable<string> args)
{
    var sb = new StringBuilder();
    foreach (var arg in args)
    {
        if (sb.Length > 0) sb.Append(' ');
        AppendArgument(sb, arg);
    }
    return sb.ToString();
}

static void AppendArgument(StringBuilder sb, string arg)
{
    if (arg.IndexOf('\0') >= 0)
        throw new ArgumentException("В аргументе не может быть символа NUL (командная строка — строка с завершающим нулём, на нём обрежется)");

    bool needsQuote = arg.Length == 0 || arg.Any(c => char.IsWhiteSpace(c) || c == '"');
    if (!needsQuote)
    {
        sb.Append(arg);                       // как есть
        return;
    }

    sb.Append('"');
    int i = 0;
    while (i < arg.Length)
    {
        int backslashes = 0;
        while (i < arg.Length && arg[i] == '\\') { i++; backslashes++; }

        if (i == arg.Length)
        {
            sb.Append('\\', backslashes * 2); // конец: сразу перед закрывающей кавычкой удвоить
        }
        else if (arg[i] == '"')
        {
            sb.Append('\\', backslashes * 2 + 1).Append('"'); // сразу перед кавычкой: удвоить плюс одна
            i++;
        }
        else
        {
            sb.Append('\\', backslashes).Append(arg[i]);      // иначе как есть
            i++;
        }
    }
    sb.Append('"');
}

Ввод и вывод рядом.

Смотрите последнюю строку. Значение без пробела и кавычек не оборачивают, поэтому конечная обратная косая выходит как есть. Без обёртки правила 4 и 5 не срабатывают, и C:\data\ доходит верно.

flowchart TB
    accTitle: Выбор средства сборки по версии .NET
    accDescr: С .NET Core 2.1 отдают ProcessStartInfo.ArgumentList; на .NET Framework строку Arguments собирают своей функцией по тем же правилам. В обоих случаях кавычки вручную в склейке не пишут
    v{"Версия .NET?"}
    v -->|"Core 2.1 и новее"| al["Добавлять в ArgumentList по одному элементу"]
    v -->|"Framework"| own["Своей функцией собрать Arguments"]
    al --> no["Кавычки не писать вручную"]
    own --> no

Рис. 10: Средств два, принцип один. «Кавычки не писать руками» — и авария на конце пути не случается.

Если UseShellExecute = true, идёт не CreateProcess, а ShellExecuteEx; содержимое ArgumentList становится параметром, который передают оболочке. Когда открывают документ или URL, сопоставление файлов собирает фактическую командную строку обработчика, поэтому собранная здесь строка до другой стороны как есть не обязана дойти. Чтобы перенаправить вывод или надёжно взять код выхода, ставят UseShellExecute = false и проектируют одновременное чтение стандартного вывода и стандартной ошибки. Это сведено в «Чек-лист безопасной работы с дочерними процессами в Windows-приложении».

8. Реализация в C++ / Win32

В C++ и сборку, и деление пишут сами. Сборка — правила главы 6 как функция.

#include <windows.h>
#include <string>
#include <stdexcept>
#include <string_view>
#include <vector>

// Добавить один аргумент с argv[1] дальше. Правила — обратные правилам деления CommandLineToArgvW / CRT.
void AppendArgument(std::wstring& cmd, std::wstring_view arg)
{
    if (!cmd.empty()) cmd += L' ';
    if (arg.find(L'\0') != std::wstring_view::npos)
        throw std::invalid_argument("В аргументе не может быть символа NUL (командная строка — строка с завершающим нулём, на нём обрежется)");

    const bool needsQuote =
        arg.empty() || arg.find_first_of(L" \t\"") != std::wstring_view::npos;
    if (!needsQuote) { cmd += arg; return; }

    cmd += L'"';
    for (size_t i = 0; ; ) {
        size_t backslashes = 0;
        while (i < arg.size() && arg[i] == L'\\') { ++i; ++backslashes; }

        if (i == arg.size()) {
            cmd.append(backslashes * 2, L'\\');           // конец: удвоить
            break;
        }
        if (arg[i] == L'"') {
            cmd.append(backslashes * 2 + 1, L'\\');       // сразу перед кавычкой: удвоить плюс одна
            cmd += L'"';
        } else {
            cmd.append(backslashes, L'\\');               // иначе как есть
            cmd += arg[i];
        }
        ++i;
    }
    cmd += L'"';
}

// argv[0] (исполняемый файл) — другое правило: если есть пробел, только обернуть кавычками. Кавычку включить нельзя.
std::wstring QuoteArgv0(std::wstring_view exe)
{
    if (exe.find(L'\0') != std::wstring_view::npos)
        throw std::invalid_argument("В пути исполняемого файла не может быть символа NUL (и lpApplicationName, и командная строка на нём обрежутся, может запуститься путь до него)");
    if (exe.find(L'"') != std::wstring_view::npos)
        throw std::invalid_argument("В пути исполняемого файла кавычки нельзя");
    if (exe.empty() || exe.find_first_of(L" \t") != std::wstring_view::npos)
        return L'"' + std::wstring(exe) + L'"';
    return std::wstring(exe);
}

При вызове полный путь исполняемого файла передают в lpApplicationName, в lpCommandLine — буфер, который можно переписать.

const std::wstring exe = LR"(C:\Program Files\MyTool\convert.exe)";

std::wstring cmd = QuoteArgv0(exe);          // argv[0] совместить с исполняемым файлом
AppendArgument(cmd, L"--input");
AppendArgument(cmd, inputPath);
AppendArgument(cmd, L"--output");
AppendArgument(cmd, outputPath);

std::vector<wchar_t> buffer(cmd.begin(), cmd.end());
buffer.push_back(L'\0');                     // CreateProcessW строку может переписать

STARTUPINFOW si{}; si.cb = sizeof(si);
PROCESS_INFORMATION pi{};
if (!CreateProcessW(exe.c_str(),             // lpApplicationName: не NULL
                    buffer.data(),           // lpCommandLine: в начале тот же путь в кавычках
                    nullptr, nullptr, FALSE, CREATE_UNICODE_ENVIRONMENT,
                    nullptr, nullptr, &si, &pi)) {
    const DWORD err = GetLastError();
    // err записать в журнал и вернуть вызывающему. не проглатывать
    return;
}
CloseHandle(pi.hThread);                     // дескриптор главного потока не нужен, закрыть сразу

switch (WaitForSingleObject(pi.hProcess, INFINITE)) {   // при необходимости с таймаутом
case WAIT_OBJECT_0: {                        // завершился. код выхода читать только в этой ветви
    DWORD exitCode = 0;
    if (!GetExitCodeProcess(pi.hProcess, &exitCode)) {
        const DWORD err = GetLastError();
        // неудачу получения тоже в журнал и вернуть вызывающему как неудачу
    } else if (exitCode != 0) {
        // другая сторона запустилась, но обработка не удалась. не считать как 0;
        // код выхода в журнал и вернуть вызывающему (то же, что проверка ExitCode в примере C#)
    }
    break;
}
case WAIT_TIMEOUT:
    // ещё работает. GetExitCodeProcess здесь вернёт только STILL_ACTIVE(259),
    // это не код выхода. в этом примере политика «превышение времени свернуть как неудачу»:
    // дождаться завершения, только если запрос на завершение прошёл, затем к CloseHandle ниже.
    // если политика — продолжать ждать, здесь break и закрывать дескриптор нельзя
    // (отпустить дочернего, пока он ещё работает). вернуться к ожиданию
    if (!TerminateProcess(pi.hProcess, 1)) {
        const DWORD err = GetLastError();
        // завершить не удалось (нехватка прав и т. п.). ждать INFINITE здесь обессмыслит
        // срок, поставленный против превышения времени. err в журнал и вернуть вызывающему
        // как неудачу, не ожидая (дочерний отпускают ещё работающим — это тоже в журнал)
        break;
    }
    WaitForSingleObject(pi.hProcess, INFINITE); // запрос на завершение прошёл, дождаться завершения, потом закрыть
    // превышение времени вернуть вызывающему как неудачу
    break;
default: {                                   // WAIT_FAILED
    const DWORD err = GetLastError();
    // неудачу самого ожидания тоже в журнал
    break;
}
}
CloseHandle(pi.hProcess);                    // забыть закрыть — при каждом запуске утечёт один дескриптор

flowchart TB
    accTitle: Разделение ролей двух аргументов CreateProcessW
    accDescr: lpApplicationName фиксирует исполняемый модуль, lpCommandLine задаёт строку, которую дочерний получит GetCommandLineW. lpCommandLine передают буфером, который можно переписать; ведущий argv[0] совмещают с lpApplicationName
    app["lpApplicationName: полный путь исполняемого файла"] --> mod["Исполняемый модуль фиксируется"]
    cl["lpCommandLine: буфер, который можно переписать"] --> child["Строка, которую дочерний получит GetCommandLineW"]
    child --> a0["Ведущий токен = argv[0]"]
    a0 -.->|"Совместить"| app
    child --> rest["Дальше = аргументы, собранные правилами главы 6"]

Рис. 11: «Что исполнять» и «что передать» задают разные аргументы. Явно указать оба — не будет ни проблемы Program.exe, ни нарушения доступа на буфере, который нельзя переписать.

На принимающей стороне возврат GetCommandLineW передают в CommandLineToArgvW и получают форму argv. Возврат освобождают одним LocalFree. Крайнее поведение: пустая строка lpCmdLine возвращает путь текущего исполняемого файла; ведущий пробел делает первый аргумент пустой строкой.³

int argc = 0;
LPWSTR* argv = CommandLineToArgvW(GetCommandLineW(), &argc);
if (argv == nullptr) {
    const DWORD err = GetLastError();
    // неудачу разбора тоже в журнал
    return 1;
}
for (int i = 0; i < argc; ++i) {
    // argv[0] — имя исполняемого файла. ОС иногда дополняет полный путь
}
LocalFree(argv);

Если пользуются main / wmain, то же при старте делает среда выполнения C. Но argv у main — узкая строка, переведённая в текущую кодовую страницу, поэтому символы, которые кодовая страница не представляет (японский путь на ПК не в японской среде и т. п.), здесь теряются. Функция сборки главы 6 «круговым путём проходит» против принимающей стороны, которая делит широкими символами: wmain, CommandLineToArgvW, .NET. По умолчанию подстановочные знаки не раскрывают, но связав setargv.obj (для wmain — wsetargv.obj), раскрывают * и ?.⁴ Если цель с этой настройкой получает аргумент с * в имени файла, дойдут не те аргументы, что задумывали.

9. Когда посередине cmd.exe и пакетный файл

Правила выше — когда из CreateProcess прямо до чужого exe. Если посередине cmd.exe, входит ещё один этап толкования.

cmd.exe считает &, |, (, ) грамматикой; чтобы передать их как аргумент, экранируют ^ или оборачивают кавычками. У обращения с кавычками строки после /c и /k свои правила: снимать ли внешние кавычки, зависит от наличия /s, числа кавычек и особых символов.¹⁷ Пакетный файл аргументы не делит и принимает сырую строку командной строки. Официальная документация PowerShell прямо предупреждает не передавать пакетному файлу недоверенный ввод.⁷ Документация CreateProcess пишет, что для запуска пакета в lpApplicationName указывают cmd.exe и передают /c и имя пакета, и сноской — что инженерная команда MSRC это не рекомендует, со ссылкой на разбор MS14-019.¹ MS14-019 закрыл захват, когда пакет передавали в CreateProcess напрямую и cmd.exe искали сначала в текущем каталоге; рекомендация MSRC — «передать полностью квалифицированный путь cmd.exe, пакет — его аргументом».¹⁸ То есть проблема — запускать пакет, не указывая cmd.exe полным путём (lpApplicationName = NULL, запуск от имени пакета), а не сам запуск /c с полным путём cmd.exe в lpApplicationName.

flowchart TB
    accTitle: cmd.exe посередине добавляет этапы толкования
    accDescr: Прямой запуск чужого exe — одно деление парсером другой стороны; через cmd.exe /c добавляется толкование грамматики cmd.exe, а пакетный файл принимает сырую строку, поэтому правила кавычек меняются на каждом этапе
    direct["Свой процесс → чужой exe"] --> p1["Деление одно: парсер другой стороны"]
    p1 ~~~ via
    via["Свой процесс → cmd.exe /c → чужой exe"] --> p2["Добавляется толкование грамматики cmd.exe (амперсанд, конвейер, круглые скобки, карет)"]
    p2 --> p3["Деление парсером другой стороны"]
    p3 ~~~ bat
    bat["Свой процесс → cmd.exe /c → пакет"] --> p4["Пакет принимает сырую строку"]
    p4 --> danger["Пропустить недоверенное значение — внедрение команд"]

Рис. 12: Чем больше этапов, тем больше смешение правил. Что можно запустить напрямую — запускать напрямую; в пакет значения извне не передавать.

Практическое решение простое. Если другая сторона — exe, cmd.exe не вставлять. Если без .bat не обойтись, принцип — не давать пакету толковать значения извне. Значение пишут в файл, пакет передаёт путь этого файла нижестоящему exe фиксированной строкой, содержимое читает сторона exe. Положить в переменную среды не граница: как только пакет раскроет %VAR%, & и | cmd.exe толкует снова. В переменную среды можно, только если нижестоящий exe читает её напрямую, минуя пакет. Если и это трудно — содержимое пакета переносят в PowerShell или свой exe («Стоит ли переносить BAT на PowerShell ── критерии решения и практика миграции»).

10. Предел длины

Предел разный по пути.

Дизайн «перечень файлов и подобные переменной длины значения ставить аргументами» в день, когда число вырастет, наступит на предел. Для применений, близких к пределу, переключайтесь на способ файла ответов: значения пишут в один файл и передают только путь этого файла. Официальный обход ограничения cmd.exe — тот же способ.⁸ Но ни CreateProcess, ни cmd.exe файл сами не раскроют. Способ стоит, только если чужая программа умеет читать файл ответов синтаксисом вроде @file, или её можно так поправить. Если цель — готовый exe, в который руки не вложить, остаётся дробить вызовы, чтобы уложиться в предел.

flowchart TB
    accTitle: Предел дизайна «передать значения переменной длины аргументами» и обход
    accDescr: Перечень файлов и подобные значения переменной длины аргументами при росте числа упираются в 8191 символ cmd.exe или 32767 единиц кода UTF-16 CreateProcess. Если цель умеет читать файл ответов (или её можно так поправить) — значения пишут в файл и передают только путь; если готовый exe читать не умеет — дробят вызовы
    list["Значения переменной длины (перечень файлов и т. п.) ставить аргументами"] --> grow["Число растёт — строка удлиняется"]
    grow --> lim["Доходят до предела (cmd.exe 8 191 / CreateProcess 32 767)"]
    lim --> fail["В какой-то день запуск внезапно не удаётся"]
    fail -.->|"Цель умеет читать файл ответов"| resp["Значения в файл, передать только путь (файл ответов)"]
    fail -.->|"Готовый exe читать не умеет"| split["Дробить вызовы"]

Рис. 13: Предел — задача вида «сегодня ещё нормально». Аргументы, которые растут пропорционально числу, с самого начала так, если цель умеет читать файл ответов (или её можно так поправить).

11. Как проверить, что на самом деле дошло

Прежде чем наугад добавлять кавычки, смотреть аргументы, которые дошли до другой стороны, — самый короткий путь. Смотреть три вещи: «строка, собранная на вызывающей стороне», «строка, дошедшая до другой стороны», «массив после деления»; средств четыре. Сначала одно обещание. Любым средством, журналируя командную строку, секреты перед записью заменяют заглушкой. Если в аргументах по дизайну пароль, ключ API, токен — и в журнале вызывающей стороны, и в журнале запуска другой стороны запись как есть оставит секрет в журнале. Журнал держат дольше процесса, видит больше людей. Командную строку, как ниже у Process Explorer, может прочитать другой процесс на той же машине, поэтому пароль и токен аргументом не передают — корень меры: стандартный ввод или защищённое хранилище настроек; заглушка в журнале — поверх этого. Либо толкуют аргументы после деления (на вызывающей стороне — элементы до сборки) и значения опасных параметров перед записью заменяют заглушкой, либо запись сырой строки включают только в ограниченном диагностическом режиме.

1. На вызывающей стороне оставить в журнале собранную строку. lpCommandLine сразу перед передачей в CreateProcess. Эта сверка исходит из запуска с UseShellExecute = false или прямого CreateProcess. При UseShellExecute = true документ или URL идут через ShellExecuteEx, сопоставление файлов собирает фактическую командную строку (глава 7), поэтому несовпадение строки вызывающей стороны и строки другой стороны бывает и без cmd.exe и пакета — это не задача главы 9. Если пользуются ArgumentList .NET, порядок элементов как есть для сравнения не годится. Элементы — значения до кавычек и удвоения конечной обратной косой; ОС получает строку, которую из них собрал .NET. Либо заново соберите одну строку из элементов теми же правилами, что BuildArguments главы 7 (тот же результат, что внутренняя сборка ArgumentList), либо сравнивайте порядок элементов напрямую с массивом после деления. Только это средство видит «исходный буфер вызывающей стороны»; Process Explorer ниже и журнал другой стороны, если посередине cmd.exe или пакет, покажут только строку, которую тот этап собрал заново. Записывая, по обещанию в начале значения элементов, которые могут быть секретом, заменяют заглушкой (заглушенный элемент со строкой другой стороны уже не совпадёт — сравнивают, исключив этот элемент).
2. Приготовить exe, который только показывает аргументы. Запускают вместо чужого exe и выводят дошедшие args по одному на строку. Писать значение как есть — аргумент с переводом строки или управляющим символом выглядит несколькими строками или затирает соседние, считают неправильно; поэтому выводят форму, экранированную как строка JSON, и длину (экранирование обратимо, исходное значение восстанавливается). Но парсеров, как в главе 3, три линии, на краю вроде двух кавычек подряд внутри обёртки толкование расходится. Берите показывающий exe, собранный на той же среде выполнения, что цель (если цель — C/C++ MSVC, то C++ с wmain; если .NET — .NET). Если цель — ваша программа, надёжнее не вставлять показывающий exe, а в журнале запуска самой цели оставить argv (по правилу заглушки следующего пункта). Для .NET хватит нескольких строк.

using System.Text.Encodings.Web;
using System.Text.Json;

// Перевод строки, управляющие символы, кавычки, обратную косую экранировать; кириллицу оставить как есть
var json = new JsonSerializerOptions { Encoder = JavaScriptEncoder.UnsafeRelaxedJsonEscaping };

Console.WriteLine("CommandLine: " + JsonSerializer.Serialize(Environment.CommandLine, json)); // одна строка
for (int i = 0; i < args.Length; i++)
    Console.WriteLine($"[{i}] len={args[i].Length} {JsonSerializer.Serialize(args[i], json)}");
    // после деления. один элемент всегда на одной строке; пустая строка видна как len=0 и "". len — единицы кода UTF-16

1. Смотреть командную строку дочернего процесса в Process Explorer. Во свойствах процесса видна строка командной строки, которую держит дочерний. Средство подтвердить «строку, дошедшую до другой стороны»; «массив после деления» не видно. Показана строка, которую держит сторона дочернего, поэтому, как в главе 2, ведущее имя исполняемого файла ОС иногда дополняет полным путём, а если посередине cmd.exe или пакет — видна строка, которую собрал cmd.exe. Не пугаться одной разницы ведущего токена; исходную строку вызывающей стороны видит только журнал пункта 1. Как пользоваться — в «Практическое руководство Sysinternals Process Explorer / Handle / VMMap».
2. При запуске своего приложения оставить в журнале принятую командную строку. Когда на месте говорят «не запускается», если осталось, какой строкой запускали, сразу отделяют, задача ли это аргументов. И здесь возврат GetCommandLineW как есть не сохраняют. По обещанию в начале толкуют аргументы после деления и значения, которые могут быть секретом, заменяют заглушкой, либо запись сырой строки включают только в ограниченном диагностическом режиме.

Порядок сверки такой. Сначала строку вызывающей стороны (пункт 1) сравнивают со строкой другой стороны (пункт 3 или 4). Если без ведущего имени исполняемого файла не совпадают — деформировал промежуточный этап. Прямой запуск — cmd.exe или пакет (глава 9); UseShellExecute = true — сопоставление оболочки (глава 7). Замена на функцию главы 6 не починит. Если совпадают — эту строку сверяют с массивом после деления (пункт 2). Режется по правилам, но не тот массив, что хотели — задача стороны сборки; не режется по правилам — задача парсера принимающей стороны.

flowchart TB
    accTitle: Порядок разбора неполадки аргументов
    accDescr: Сначала сравнивают журнал строки, собранной на вызывающей стороне, со строкой другой стороны, видимой в Process Explorer или журнале запуска. Если без ведущего имени исполняемого файла не совпадают — деформировал промежуточный этап (прямой запуск — cmd.exe или пакет, UseShellExecute=true — сопоставление оболочки). Если совпадают — сверяют с массивом после деления: режется по правилам, но не тот массив — задача стороны сборки; не режется по правилам — задача парсера принимающей стороны
    s["Аргументы не те"] --> caller["Смотреть строку, собранную на вызывающей стороне (журнал вызывающей стороны)"]
    caller --> target["Смотреть строку другой стороны (Process Explorer / журнал запуска другой стороны)"]
    target --> same{"Совпадает без ведущего имени исполняемого файла?"}
    same -->|"Нет"| mid["Деформировал промежуточный этап (главы 9 и 7)"]
    same -->|"Да"| arr["Смотреть массив после деления (показывающий exe на той же среде выполнения, что цель)"]
    arr --> cmp{"Строка и массив соответствуют правилам?"}
    cmp -->|"Да: режется, но не тот массив"| build["Задача стороны сборки: заменить на функцию главы 6"]
    cmp -->|"Нет: не режется по правилам"| recv["Задача парсера принимающей стороны"]

Рис. 14: Сравнив по порядку «строку вызывающей стороны», «строку другой стороны», «массив», ответственность механически оказывается у промежуточного этапа, стороны сборки или принимающей стороны. Экранирование наугад — после этой проверки.

12. Грубая таблица выбора

13. Итог

Аргументы командной строки Windows границу пересекают не массивом, а одной строкой. Склеивает вызывающая сторона, делит принимающая; правила деления сводятся к трём: «делить по пробелу», «обернуть кавычками», «обратная косая особая только сразу перед кавычкой». Только ведущее имя исполняемого файла — другое правило; опущение lpApplicationName делает толкование пути с пробелами двусмысленным.

На стороне сборки всё укладывается в одну функцию; с .NET Core 2.1 её несёт ArgumentList. Исполняемый файл — полный путь в lpApplicationName и тот же путь в кавычках в начале lpCommandLine (в .NET отдают FileName). Форму смежных кавычек внутри непустого аргумента не порождают ("" пустого аргумента — другое); в cmd.exe и пакетный файл значения извне не пускают; аргументы, которые растут пропорционально числу, — файл ответов, только если цель умеет его читать (или её можно так поправить), иначе дробят вызовы. Эти пять пунктов — и не будет аварий «не запускается только на ПК с пробелом» и «конечная обратная косая съела следующий аргумент».

flowchart TB
    accTitle: Пять обещаний против аварий аргументов
    accDescr: Исполняемый файл — полный путь в lpApplicationName и ведущий токен в кавычках; кавычки отдают функции по правилам или ArgumentList; форму смежных кавычек внутри непустого аргумента не порождают; в cmd.exe и пакет значения извне не пускают; растущие аргументы — файл ответов, если цель умеет читать. Исходя из того, что цель толкует опубликованными правилами деления и не включила раскрытие подстановочных знаков, эти пять пунктов предотвращают аварии пути с пробелом и конечной обратной косой
    r0["Полный путь в lpApplicationName, ведущий токен тоже в кавычках"]
    r1["Кавычки отдать функции по правилам или ArgumentList"]
    r2["Форму смежных кавычек внутри обёртки не порождать"]
    r3["В cmd.exe и пакет значения извне не пускать"]
    r4["Растущие аргументы — файл ответов (если цель умеет читать)"]
    goal["Аварий пробела и конечной обратной косой нет"]
    r0 ~~~ r1 ~~~ r2 ~~~ r3 ~~~ r4
    r0 --> goal
    r1 --> goal
    r2 --> goal
    r3 --> goal
    r4 --> goal

Рис. 15: Все пять обещаний — перефраз «фиксировать исполняемый модуль и передавать только строку, которую парсер другой стороны разрежет». Предпосылка — цель толкует опубликованными правилами деления и не включила раскрытие подстановочных знаков (главы 6 и 8); на ней эти пять пунктов предотвращают аварии пробела и конечной обратной косой.

Когда не получается — прежде чем наугад добавлять экранирование, смотрите три: строку, собранную на вызывающей стороне, строку, дошедшую до другой стороны, массив после деления. Если строки вызывающей стороны и другой стороны разные — промежуточный этап (cmd.exe или пакет, при UseShellExecute = true — сопоставление оболочки); если те же — по соответствию строки и массива решается, сторона сборки или принимающая.

Похожие статьи

• Как правильно вызывать внешний exe из PowerShell ── кавычки аргументов, код выхода, ловушки кракозябр
• Чек-лист безопасной работы с дочерними процессами в Windows-приложении
• Что остаётся после падения родителя ── дерево дочерних процессов в Job Object
• MAX_PATH и ловушки путей и имён файлов в Windows — лимит 260 символов, зарезервированные имена, точка в конце, регистр
• Интеграция с оболочкой Windows ── контекстное меню, сопоставление файлов и изменения в Windows 11
• Защита Windows-приложения от повторного запуска — именованный Mutex и активация окна при втором старте
• Безопасный вызов Win32 API из C# — практическое руководство по P/Invoke (DllImport / LibraryImport / CsWin32)
• Стоит ли переносить BAT на PowerShell ── критерии решения и практика миграции

Смежные области консультирования

Компания KomuraSoft LLC занимается проектированием Windows-приложений, которые сочетают внешние средства и внутренние EXE; расследованием запуска дочернего процесса, который «в одной среде запускается, в другой нет»; пересмотром запуска процессов при переходе с .NET Framework на .NET. Можно начать с одного случая «аргументы портятся».

• Разработка приложений для Windows
• Расследование неисправностей и анализ причин
• Использование и перенос существующих активов
• Технические консультации и ревью дизайна
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

В Windows нет API, который передаёт массив аргументов?

Нет. CreateProcess принимает одну строку lpCommandLine, и эта строка доходит до нового процесса (полное имя ведущего исполняемого файла ОС иногда дополняет). То, что выглядит массивом argv, внутри принимающего процесса собирают стартовый код среды выполнения C, CommandLineToArgvW или среда выполнения .NET, деля строку. Поэтому «передать аргументы» — то же, что «собрать строку, которую парсер другой стороны снова разрежет как было».

Когда обратная косая становится символом экранирования?

Только когда сразу за ней идёт двойная кавычка. Обратная косая, за которой двойной кавычки нет, остаётся как есть, сколько бы их ни стояло подряд. Если перед двойной кавычкой 2n обратных косых, получаются n обратных косых и открытие или закрытие кавычек; если 2n+1 — n обратных косых и кавычка как символ. Из-за этой асимметрии конечную обратную косую пути нужно удваивать, только когда путь оборачивают кавычками.

Что брать: ProcessStartInfo.ArgumentList или Arguments?

Если значения приходят из переменных — ArgumentList. Один элемент — один аргумент; нужные кавычки и экранирование делает .NET, внутри собирает одну строку и отдаёт ОС. Arguments — свойство, которое передаёт собранную вами строку как есть; они независимы и одновременно не используются. Но ArgumentList — API с .NET Core 2.1, на .NET Framework его нет. На .NET Framework Arguments собирайте функцией из этой статьи.

Можно ли внутри аргумента в кавычках поставить две кавычки подряд?

На стороне сборки не порождайте: приёмники толкуют по-разному. Имеется в виду обернуть непустой аргумент кавычками и внутри поставить две смежные кавычки. "" как пустой аргумент (только две кавычки) — другое, и это верный способ передать пустую строку. По правилам среды выполнения C MSVC две подряд кавычки внутри строки в кавычках считают одной кавычкой, но в официальных правилах CommandLineToArgvW этого нет, а исходники среды выполнения .NET прямо пишут, что форму не порождают, потому что VC до и после 2008 толкуют её по-разному. Чтобы передать кавычку как символ, ставьте перед ней обратную косую — тогда любой парсер даёт один результат.

Если в пути исполняемого файла есть пробел, что безопасно передать в CreateProcess?

Надёжно передать полный путь исполняемого файла в lpApplicationName и тот же путь, обёрнутый кавычками, поставить в начало lpCommandLine. Если lpApplicationName — NULL, CreateProcess угадывает имя исполняемого файла с начала lpCommandLine, деля по пробелам. Для строки C:\\Program Files\\MyApp -L -S сначала проверяет, есть ли C:\\Program.exe, и если там вредоносный файл — запускается он. Официальная документация прямо называет эту опасность и просит не передавать NULL или обернуть путь кавычками.

Те же правила, когда аргументы передают пакетному файлу?

Нет. Пакетный файл толкует cmd.exe, а cmd.exe не делит аргументы и берёт сырую строку командной строки. Символы вроде &, |, круглых скобок и ^ работают как грамматика cmd.exe, поэтому кавычки по правилам CommandLineToArgvW безопасными их не делают. Официальная документация предупреждает не передавать пакетному файлу недоверенный ввод. Значения пишите в файл и читайте не пакетом, а нижестоящим exe, либо перенесите содержимое пакета в PowerShell или свой exe. Положить в переменную среды тоже не граница: как только пакет раскроет %VAR%, cmd.exe снова толкует символы.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.