在我的Windows副本中，路径分隔符不是反斜杠，而是韩元货币符号，即Unicode中的字符U20A9。
但是，当我的程序在表示文件路径的字符串中搜索此字符时，它找不到它，即使它在打印路径时按预期显示。
我的程序在资源管理器中注册，显示在文件的右键菜单中，因此它从资源管理器接收文件路径作为命令行参数。
这里发生了什么？如何在命令行参数中找到路径分隔符？
答案 0 :(得分：1)
您使用的是日语版还是韩语版的Windows？在这种情况下，路径符号仍应 U + 005C 显示（但实际上与本地货币字符不同）（例如₩< / kbd>和¥）而不是 \ 。如果您尝试搜索 U + 005C 而不是 U + 20A9 ，那会有效吗？
但是，我对你的问题感到困惑：
Java无法将文件作为File对象打开，因为我的Windows副本中的文件分隔符不是反斜杠，而是韩元货币符号（U20A9）。
只要您没有自己输入测试路径，并且使用货币字符的“错误”版本（并且只要文件没有其他问题），它仍然可以工作。如果我们能看到您的代码，可能会有所帮助。
原因是用于显示的代码页。 Kaplan曾经在MSDN上发布过关于此的博文，但它已经消失了。它基本上说“日文代码页932：0x005C是YEN SIGN。韩文代码页949：0x005C是WON SIGN。”
在日语系统上使用的Windows代码页和OEM字符集包含日元符号（¥）而不是反斜杠（\）。 ...将Unicode映射到日语代码页时，转换函数会将反斜杠（U + 005C）和普通的Unicode Yen符号（U + 00A5）映射到同一个字符。
根据上面的参考，请注意，如果您尝试使用实际的Won和Yen字符（ U + 00A5 和 U + 20A9 ）作为路径分隔符，您可以' t没有映射/将它们映射到 U + 005C 。
相关琐事
我不记得我在哪里读到这个，但它有助于理解为什么会发生这一切，以及为什么 / 在文件路径中工作。
显然Windows使用 \ 而不是* nix的 / 是因为（当DOS出生时）有人在MS / IBM中使用了很多DOS程序< kbd> / 作为DOS程序的“切换”字符？这是一个决定可能来自甚至在DOS CP / M之前，通过QDOS，到MSDOS。 DOS不支持目录，因此与* nix的冲突并不重要。当DOS 2.0出现文件和文件路径时，他们想要一个* nix样式的文件路径命名系统但是不能使用“DOS开关” / 所以他们使用 \ 相反。
但是 - 他们将DOS编码为接受 \ 和/ ，因为他们真的更喜欢使用* nix风格。 （他们还添加了一个操作系统机制来改变开关字符，我记不清了，但是windows世界从未完全“切换”到* nix风格的路径和开关）。
修改
davea.name 的Dave Angel davea Tue Feb 26 03:23:58 CET 2013
实际上MSDOS使用反斜杠的原因是因为它已经使用过了 切换字符的正斜杠。那么对于版本2，用硬 第一次支持磁盘，他们使用反斜杠 代替。那时我和他们谈过支持“switchchar”电话 更改为使用短划线切换字符，并斜线为 子目录。