垃圾字符替换 Windows 命令提示符中的“/”

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/6897314/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-15 17:39:17  来源:igfitidea点击:

Junk character replaces the '/' in windows command prompt

windowscommand-linefontsraster

提问by Naga

I am facing a strange problem. I am seeing in windows command prompt, every '/' character is replaced by a junk character (yen symbol). I selected two font types "MS Gothic" and "Raster". But same problem. If I use Raster the problem is intermittent. Please let me know how to solve the problem.

我正面临一个奇怪的问题。我在 Windows 命令提示符中看到,每个“/”字符都被一个垃圾字符(日元符号)替换。我选择了两种字体类型“MS Gothic”和“Raster”。但同样的问题。如果我使用 Raster 问题是间歇性的。请让我知道如何解决问题。

Thanks, Naga

谢谢,娜迦

回答by J.J.

Type chcpat the command prompt, and I bet you'll see Active code page: 932

键入chcp在命令提示符下,我敢打赌,你会看到Active code page: 932

The windows console has the concept of code pages, a relic of pre-unicode days, where the bytes 0-255 are mapped to different characters, depending upon the language. While the characters a-z, A-Z, 0-9 are consistent, lesser-used characters are mapped to characters popular in the target language.

Windows 控制台具有code pages的概念,这是 unicode 之前的遗留物,其中字节 0-255 映射到不同的字符,具体取决于语言。虽然字符 az、AZ、0-9 是一致的,但较少使用的字符被映射到目标语言中流行的字符。

In code page 932, the backslash is mapped to the yen character.

代码页 932 中,反斜杠映射到日元字符。

This is a common issue. See Microsoft's note on MSDN:

这是一个常见的问题。请参阅Microsoft 在 MSDN 上的说明

CautionWindows code page and OEM code page character sets used on Japanese-language operating systems contain the Yen symbol (¥) instead of a backslash (). Thus, the Yen symbol is a prohibited character for NTFS and FAT file systems. When mapping Unicode to a Japanese-language code page, WideCharToMultiByte and other conversion functions map both backslash (U+005C) and the normal Unicode Yen symbol (U+00A5) to this same character. For security reasons, your applications should not typically allow the character U+00A5 in a Unicode string that might be converted for use as a FAT file name. For more information, see Security Considerations: International Features.

注意在日语操作系统上使用的 Windows 代码页和 OEM 代码页字符集包含日元符号 (¥) 而不是反斜杠 ()。因此,日元符号是 NTFS 和 FAT 文件系统的禁止字符。将 Unicode 映射到日语代码页时,WideCharToMultiByte 和其他转换函数会将反斜杠 (U+005C) 和普通的 Unicode 日元符号 (U+00A5) 映射到同一个字符。出于安全原因,您的应用程序通常不应允许在可能被转换为用作 FAT 文件名的 Unicode 字符串中使用字符 U+00A5。有关更多信息,请参阅安全注意事项:国际功能。

UPDATE

更新

Sorry for the delay, it took me a bit to recall where I had originally read about this. The best reference is Mike Kaplan's weblog entry here. michkap is the best Microsoft blog for all things unicode. If you deal with charsets, encoding issues and the dark corners of internationalization, his blog is an essential reference.

抱歉耽搁了,我花了一点时间才回想起我最初在哪里读到的。最好的参考是 Mike Kaplan 的博客条目在这里。michkap 是所有 unicode 方面最好的 Microsoft 博客。如果您处理字符集、编码问题和国际化的黑暗角落,他的博客是必不可少的参考。

From his entry on the yen character as the backslash:

从他输入的日元字符作为反斜杠:

...on Japanese code page 932, 0x5c is the YEN SIGN, and on Korean code page 949, 0x5c is the WON SIGN.

Which is not to say that 0x5c does not act as a path separator -- it still does. And which is also not to say that the Unicode code points for the Yen and the Won (U+00a5 and U+20a9) do act as path separators -- because they do not.

...

In practice, after many years of code page based systems in Japan and Korea using their respective currency symbols as the path separators, it is believed customers were simply used to this appearance. And there was therefore little interest in changing that appearance (when the system settings were Japanese or Korean) to anything but those symbols.

To support this expectation, Japanese and Korean fonts, whenever the default system locale is set to Japanese or Korean, respectively, will display the currency symbol rather than the backslash when U+005c is shown.

...在日文代码页 932 上,0x5c 是日元符号,而在韩文代码页 949 上,0x5c 是 WON 符号。

这并不是说 0x5c 不能作为路径分隔符——它仍然可以。这也并不是说日元和韩元的 Unicode 代码点(U+00a5 和 U+20a9)确实充当了路径分隔符——因为它们没有。

...

在实践中,在日本和韩国基于代码页的系统使用各自的货币符号作为路径分隔符多年后,相信客户只是习惯了这种外观。因此,除了这些符号之外,几乎没有兴趣将外观(当系统设置为日语或韩语时)更改为任何其他内容。

为了支持这种期望,当默认系统区域设置分别设置为日语或韩语时,日语和韩语字体将在显示 U+005c 时显示货币符号而不是反斜杠。

You'll be hard pressed to find a better reference than that one, I believe.

我相信你很难找到比那个更好的参考。

回答by MSalters

Both the Yen and the \ character have byte value 0x5C, just in different character sets. This is so common that the Japanese are generally aware of this, and don't consider it a problem.

Yen 和 \ 字符都有字节值 0x5C,只是在不同的字符集中。这太普遍了,日本人普遍意识到这一点,并不认为这是一个问题。

See the comment section of this blog post- Norman Diamond at 27 Dec 2004 1:45 AM writes "Windows paths work with a Japanese default system locale because 0x5c is the yen sign and the yen sign is the path separator. " (Norman works in Japan)

请参阅此博客文章的评论部分- Norman Diamond 在 2004 年 12 月 27 日凌晨 1:45 写道“Windows 路径使用日语默认系统区域设置,因为 0x5c 是日元符号,而日元符号是路径分隔符。”(诺曼在日本)