Können Sie eine UTF-8-Zeichenfolge als Argument für eine StartInfo verwenden?
Ich versuche, ein UTF-8 (in diesem Fall eine japanische Zeichenkette) als Konsolenargument an eine Anwendung zu übergeben.
So etwas (das ist nur ein Beispiel! (cmd.exe wäre eine benutzerdefinierte App))
%Vor%Bei der Ausführung scheint die UTF-8-Zeichenfolge verloren zu gehen, und die gesamte Zielanwendung sieht "echo ?????????" "
Wenn Sie diesen Befehl direkt in der Befehlszeile ausführen (indem Sie die Argumente einfügen), empfängt die Zielanwendung die Zeichenfolge korrekt, obwohl die Befehlszeile selbst sie nicht korrekt anzuzeigen scheint.
Muss ich etwas Besonderes tun, um UTF-8-Unterstützung in den Argumenten zu aktivieren, oder wird das einfach nicht unterstützt?
Es hängt vollständig von dem Programm ab, das Sie starten möchten. Die Process-Klasse unterstützt Unicode vollständig, ebenso wie das Betriebssystem. Aber das Programm könnte alt sein und 8-Bit-Zeichen verwenden. GetCommandLineA () wird verwendet, um die Befehlszeilenargumente abzurufen, die ANSI-Version der systemeigenen Unicode-API-Funktion "GetCommandLineW ()". Und das übersetzt den Unicode-String in 8-Bit-Zeichen unter Verwendung der Systemstandard-Codepage, wie in Systemsteuerung + Regions- und Sprachoptionen, Sprache für Nicht-Unicode-Programme konfiguriert. WideCharToMultiByte () mit CP_ACP.
Wenn dies nicht die japanische Codepage ist, erzeugt diese Übersetzung Fragezeichen, da die japanischen Glyphen nur einen Code in der japanischen Codepage haben. Das Umschalten der Systemcodeseite ist normalerweise für nicht-japanische Sprecher nicht sehr wünschenswert. Utf8 wird sicherlich nicht funktionieren, das Programm wird sie nicht erwarten. Ziehen Sie in Betracht, dieses Programm in einer virtuellen Maschine auszuführen.
Programme erhalten ihre Befehlszeilen in UTF-16 mit der gleichen Codierung wie .NET-Zeichenfolgen:
%Vor%Es ist das Konsolenfenster, das keine Zeichen außerhalb der aktuellen Codepage / ausgewählten Schriftart anzeigen kann. Ich gehe jedoch davon aus, dass Sie kein Echo aufrufen wollen, das hängt also ganz davon ab, wie das Programm, das Sie aufrufen, geschrieben ist.
Einige Hintergrundinformationen: C- oder C ++ - Programme, die die Einstiegspunkte "eng" (System-Codepage) verwenden, z. B. main(int argc, char** argv) , und nicht die Einstiegspunkte "Wide" (UTF-16), wmain(int argc, wchar_t** argv) , werden aufgerufen durch einen Stub, der die Befehlszeile in die System-Codepage konvertiert - die nicht UTF-8 sein kann.
Bei weitem die beste Option besteht darin, das Programm so zu ändern, dass es einen breiten Einstiegspunkt verwendet und einfach dasselbe UTF-16 wie in Ihrer .NET-Zeichenkette erhält. Wenn das nicht möglich ist, können Sie es mit einer UTF-16-Befehlszeile umgehen, die bei der Konvertierung in die Systemcodepage UTF-8 für die Zeichen enthält, die Sie verwenden möchten:
%Vor%Caveat Coder: Seien Sie nicht überrascht, wenn dies auf Ihrem oder einem anderen Computer schrecklich schief geht, es hängt davon ab, dass jedes mögliche Byte auf der aktuellen System-Codepage gültig ist, die System-Codepage unterscheidet sich nicht von dem Zeitpunkt, an dem Ihr Programm gestartet wurde. Das Programm, das Sie ausführen, verwendet die Daten nicht für eine codierungsabhängige Windows-Funktion (die mit den Suffixversionen A, W usw.).
Ich habe gerade eine Windows Forms-Anwendung erstellt, die die Environment.CommandLine in einer RichTextBox anzeigt, und die Zeichenfolge wurde korrekt angezeigt, so dass es möglich ist, eine Unicode-Zeichenfolge auf diese Weise zu übergeben.
Ich denke, dass mein Betriebssystem die Codepage 1252 standardmäßig verwendet. Daher kann ich diese Zeichen nicht in der Eingabeaufforderung anzeigen, auch nicht beim Einfügen der Argumente wie bei Ihnen.