Process.StartInfo.Arguments supporta una stringa UTF-8?

Question

È possibile utilizzare una stringa UTF-8 come argomento per un oggetto StartInfo?

Sto cercando di passare un UTF-8 (in questo caso una stringa giapponese) a un'applicazione come argomento della console.

Qualcosa di simile (questo è solo un esempio! (Cmd.exe sarebbe un'applicazione personalizzata))

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

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

L'esecuzione di questo sembra perdere la stringa UTF-8 e tutta l'applicazione di destinazione vede è " eco ?????????"

Quando si esegue questo comando direttamente sulla riga di comando (incollando gli argomenti) l'applicazione di destinazione riceve correttamente la stringa anche se la riga di comando stessa non sembra visualizzarla correttamente.

Devo fare qualcosa di speciale per abilitare il supporto UTF-8 negli argomenti o questo non è supportato?

Answer 1

Dipende completamente dal programma che si sta tentando di avviare. La classe Process supporta pienamente Unicode, così come il sistema operativo. Ma il programma potrebbe essere vecchio e utilizzare caratteri a 8 bit. Verrà utilizzato GetCommandLineA() per recuperare gli argomenti della riga di comando, la versione ANSI della funzione API Unicode GetCommandLineW() nativa. E ciò traduce la stringa Unicode in caratteri a 8 bit utilizzando la tabella codici predefinita del sistema come configurata in Pannello di controllo + Opzioni internazionali e della lingua, Lingua per programmi non Unicode. WideCharToMultiByte() utilizzando CP_ACP.

Se questa non è la tabella codici giapponese, tale traduzione produce punti interrogativi poiché i glifi giapponesi hanno solo un codice nella tabella codici giapponese. La commutazione della tabella codici di sistema non è solitamente molto auspicabile per i diffusori non giapponesi. Utf8 sicuramente non funzionerà, il programma non si aspetterà da loro. Prendi in considerazione l'esecuzione di questo programma in una macchina virtuale.

Answer 2

Ho appena creato un'applicazione Windows Form che visualizza Environment.CommandLine in un RichTextBox e la stringa è stata visualizzata correttamente, quindi è possibile passare una stringa Unicode in questo modo.

Penso che il mio sistema operativo utilizzi la codepage 1252 di default, quindi non posso visualizzare questi caratteri nel prompt dei comandi anche se si incollano gli argomenti come hai fatto tu.

Answer 3

Le stringhe utilizzate [System.String o semplice string] sono basate su Unicode. Quindi, sì, possono sostenere la suddetta codifica.

Date un'occhiata here

È necessario verificare le impostazioni relative OS (tabelle codici, lingue ecc)

Answer 4

programmi ricevono le loro linee di comando in UTF-16, la stessa codifica come stringhe .NET:

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

È la finestra della console che non può visualizzare caratteri al di fuori della sua codepage corrente/carattere selezionato. Tuttavia, suppongo che tu non voglia chiamare echo, quindi questo dipende interamente da come viene scritto il programma che stai chiamando.

Alcune informazioni di fondo: C o C++ programmi che utilizzano le (tabella codici di sistema) i punti di ingresso 'stretti', ad esempio main(int argc, char** argv), piuttosto che le (UTF-16) punti di ingresso 'larghe', wmain(int argc, wchar_t** argv), sono chiamati da uno stub che converte la riga di comando nella codepage di sistema, che non può essere UTF-8.

L'opzione migliore è di modificare il programma per utilizzare un punto di accesso ampio e ottenere semplicemente lo stesso UTF-16 della stringa .NET. Se ciò non è possibile, allora un trucco si può provare è quello di passare un UTF-16 a riga di comando che, quando convertito la tabella codici del sistema è UTF-8 per i caratteri che si desidera utilizzare:

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

Caveat Coder : Non sorprenderti se questo è orribilmente sbagliato sulla tua macchina o su qualcun altro, dipende da ogni possibile byte valido nella codepage corrente del sistema, la codepage del sistema non è diversa da quando è stato avviato il tuo programma, il programma che stai utilizzando non utilizzare i dati per alcuna funzione di Windows dipendente dalla codifica (quelli con versioni con suffisso A, W) e così via.