这个问题基本解释了这个问题。
我正在使用Windows XP专业版Service Pack 3
COMSPEC = C：\窗口\ system32 \ cmd.exe的
我通过启动…运行对话框cmd.exe启动了控制台
这是我的控制台的“视图”：
该命令，然后输出（和我的/ /评论）
C:\> chcp 850 Active code page: 850 // output is as expected C:\> echo @chcp ^& REM 850>test850.cmd // no output; as ecpected) C:\> type test850.cmd @chcp & REM 850 // output is as expected C:\> call test850.cmd Active code page: 850 // output is as expected 上述工作正常（如预期）。 Windows-land的情况是令人高兴的，但是当我切换到65001的代码页时，“呼叫”失败
C:\> chcp 65001 Active code page: 65001 // output is as expected C:\> echo @chcp ^& REM 65001>test65001.cmd // no output; as ecpected C:\> type test65001.cmd @chcp & REM 65001 // output is as expected C:\> call test65001.cmd // NO OUTPUT, NO ERROR, NO ANYTHING, NADA... other than frustration :)
这里发生了什么（不发生）？
有趣的是，它实际上并没有运行它。 如果您执行以下操作：
pax> echo echo yy >xx.cmd pax> chcp 850 pax> xx yy pax> chcp 65001 pax> xx pax> _
你什么都得不到 这不仅仅是缺少输出，它完全没有运行（通过在echo线之前放置start . ）。 在代码页850，Explorer运行，而不是代码页65001。
这里有一些关于这个问题的讨论。 你可以让你的脚本运行：
chcp 65001 && xx.cmd && chcp 850
所以它似乎是启动命令文件时的一些问题，但只有当代码页是65001之前，你输入命令！
网络上的其他人似乎认为PowerShell可能是一个不错的选择，因为在cmd.exe的挑剔的支持。 这是你必须为自己评估的一个决定，但是，在一个大型组织中，我有许多工具可以做同样的工作，我怀疑微软将会在PowerShell之后而不是老式的命令外壳上进行增强。 他们的资源很大，但不是无限的。
造成这种情况的原因是当cmd.exe for windows xp内部使用值为1的参数dwFlags调用函数MultiByteToWideChar时。文档中提到：“对于UTF-8，必须将dwFlags设置为0.否则，函数将失败” 。
在这里补丁： http : //consolesoft.com/p/cmd-xp-65001-fix/index.html