使用jnlp/webstart在OSX上使用Java 7对文件名进行编码的问题

我有这个问题，我已经放弃了，并已成功搜索和解决尝试了几天

我现在有一个内部java swing程序，由jnlp/webstart在osx和windows计算机上发布，其中包括从WebDav下载一些文件

最近，在OSX 10.8和Java 7的测试机上，带有重音字符的文件名和目录名开始被问号取代

7之前的Java版本在OSX上没有问题

例如：

XXXYYYèU ABCD/

变成

XXXYYY_uu？u ABCD/

在原始字符串上使用java.text.Normalizer（NFD、NFC、NFKD、NFKC），结果不同，但仍然错误：

XXXYYY__e？_ABCD/

或

XXXYYY_e__ABCD/

我知道，从[andrew.brygin在oracle.com]和[mik3hall在gmail.com]之间的通信中

是的，file.encoding是根据jvm运行的区域设置的 如果您在xxxx.UTF-8语言环境中运行java vm，则 file.encoding应为UTF-8，设置为MacRoman将有问题。 所以我相信Oracle/OpenJDK7的行为是正确的。也就是说，安德鲁 汤普森指出，如果之前所有的苹果JDK版本都使用MacRoman 作为英语/UTF-8语言环境的file.encoding，有一个 这里的“兼容性”问题，可能值得在 发布说明，让Oracle/OpenJDK MacOS用户了解情况

从博客（）我知道：

您可能知道Java使用“默认字符编码”来 将二进制数据转换为字符串。用另一种语言读或写文本 编码您可以使用InputStreamReader或OutputStreamWriter。但是 对于API中深层的数据到文本转换，您别无选择，只能 更改默认编码

及

那file.encoding呢

file.encoding系统属性也可用于设置默认值 Java用于I/O的字符编码 对文件名如何解码为字符串没有影响

从jnlp内部执行区域设置时不变地打印

LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

stackoverflow上最类似的问题是：

但是，解决方案是将java程序的执行包装在一个带有

#!/bin/bash
export LC_CTYPE="UTF-8" # Try other options if this doesn't work
exec java your.program.Here

但是由于webstart的原因，我认为这个选项对我不可用，而且我还没有找到在程序中设置LC_CTYPE环境变量的任何方法

有什么解决办法或变通办法吗

p.S.：

如果我们直接从shell运行程序，即使在OSX 10+Java 7上，它也能正确地写入文件/目录。

---

这个问题只出现在JNLP+OSX+Java7的组合中：在使用OSX进行了更多的实验之后，我意识到我的答案完全错误，所以我正在重做

如果您的JVM在JVM命令行上支持

-Dfile.encoding=UTF-8

，则可能会解决此问题。我相信这是一个标准的财产，但我不确定

与其他兼容POSIX的文件系统一样，HFS Plus将文件名存储为字节。但与Linux的ext3文件系统不同，它强制文件名为有效的UTF-8。这可以在我的OSX系统上的Python解释器中看到，它从一个空目录开始

$ python
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) 
>>> import os
>>> os.mkdir('\xc3\xa8')
>>> os.mkdir('e\xcc\x80')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 17] File exists: 'e\xcc\x80'
>>> os.mkdir('\x8f')
>>> os.listdir('.')
['%8F', 'e\xcc\x80']
>>> ^D
$ ls
%8F è

$python
Python 2.7.1（r271:868321911年7月31日19:30:53）
>>>导入操作系统
>>>os.mkdir（'\xc3\xa8'）
>>>os.mkdir（'e\xcc\x80'）
回溯（最近一次呼叫最后一次）：
文件“”，第1行，在
OSError:[Errno 17]文件存在：“e\xcc\x80”
>>>os.mkdir（'\x8f'）
>>>os.listdir（'.'））
['%8F'，'e\xcc\x80']
>>>^D
$ls
%8Fè

这证明了文件系统上的目录名不能采用Mac Roman编码（即，只要是HFS Plus文件系统，就不能使用字节值

8F

，其中可以看到

è

）。但当然，JVM不能保证有HFS Plus文件系统，而且SMB和NFS没有相同的编码保证，因此JVM不应该采用这种方案

---

因此，您必须说服JVM使用UTF-8编码解释文件和目录名，以便正确地将名称读取为

java.lang.String

对象。

暗中拍摄：文件编码不会影响文件名的创建方式，内容是如何写入文件的-请在此处查看这家伙：

以下是来自苹果公司的简短评论：

与此相比，我假设您想使用

Normalizer\u string=Normalizer.normalize（目标字符，Normalizer.Form.NFD）

在将文件名传递给文件构造函数之前规范化文件名。这有帮助吗？
我认为文件名的最大ASCII表示形式是可以接受的，它几乎适用于任何编码

首先，您希望专门使用NFKD，以便最大限度地以ASCII形式保留信息。例如，
“2⁵"变为
“25”
，而不仅仅是
“2”
，
“fi”
一旦过滤掉非ascii和非控制字符，就变成了
“fi”
而不是
“
等

String str = "XXXYYY_è_ABCD/";
str = Normalizer.normalize(str, Normalizer.Form.NFKD);
str = str.replaceAll( "[^\\x20-\\x7E]", "");
//The file name will be XXXYYY_e_ABCD no matter what system encoding

然后，您将始终通过此筛选器传递文件名以获取其文件系统名。您只会丢失一些唯一性，即file
asdé.txt
是相同的
正如
asde.txt
一样，在这个系统中，它们是无法区分的。
我认为目前还没有解决这个问题的真正办法

同时，我得出结论，从程序内部打印的“C”环境变量来自JavaWebStart沙箱，而且（显然是设计上的）您不能影响那些使用jnlp的人

公认的（正如公司所接受的）解决方案/折衷方案是从bash脚本使用javaws启动jnlp

显然，从浏览器或finder启动jnlp会创建一个新的沙盒环境，其中LANG未设置（所以设置）
Files.readAllLines(myPath, StandardCharsets.UTF_8)