感谢大家的回应。我已经了解了很多有关此问题的知识，并发现了以下解决了我问题的方法：
如前所述，在Windows上，argv使用当前代码页进行编码。但是，您可以使用GetCommandLineW将命令行检索为UTF-16。不建议在支持unipre的现代Windows应用程序中使用argv，因为不建议使用代码页。
在Unixes上，argv没有固定的编码：
a）通过制表符补全/通配符插入的文件名将在argv 逐字 出现，恰好是它们在磁盘上被命名的字节序列。即使这些字节序列在当前语言环境中没有意义，也是这样。
b）用户使用其IME直接输入的输入将以区域设置编码在argv中出现。（Ubuntu似乎使用LOCALE来决定如何对IME输入进行编码，而OS
X使用Terminal.app编码首选项。）
对于想要将命令行参数视为字符串的语言，例如Python，Haskell或Java，这很烦人。他们需要决定如何解码
argv为内部使用的任何编码
String（对于这些语言，编码为UTF-16）。但是，如果他们只是使用语言环境编码来执行此解码，则输入中的有效文件名可能无法解码，从而导致异常。
Python
3采用的解决此问题的方法是代理字节编码方案（http://www.python.org/dev/peps/pep-0383/），该方案将argv中任何不可解码的字节表示为特殊的Unipre代码点。当该代码点被解码回字节流时，它再次变成原始字节。这允许通过本地Python字符串类型将来自argv的在当前编码中无效的数据（即，以当前语言环境以外的名称命名的文件名）通过本机Python字符串类型往返，并返回到字节，而不会丢失信息。
如您所见，情况非常混乱：-)
