使用Java 7在文件名上使用jnlp / webstart在OSX上编码问题 [英] Encoding issue on filename with Java 7 on OSX with jnlp/webstart

问题描述

我有这个问题，已经放在我身上，并已经过几天的不成功的搜索和解决方法的尝试。

我现在有一个由jnlp / webstart分发的内部java swing程序，在osx和windows电脑上，除了别的以外，从WebDav下载一些文件。

最近，在具有OSX 10.8和Java 7的测试机上，带有重音符的文件名和目录名开始被问号所替换。

在7之前的版本中，OSX没有问题。

示例：

XXXYYY_è_ABCD/

变成

XXXYYY _？_ ABCD /

$对原始字符串使用 java.text.Normalizer （NFD，NFC，NFKD，NFKC）的b
$ b

，结果不同但仍然错误：

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行为正确。也就是说，像Andrew
Thompson指出的，如果所有以前的Apple JDK版本使用MacRoman
作为english / UTF-8语言环境的file.encoding，这里有一个
兼容性 ，可能值得在
发行说明中添加一些内容以使Oracle / OpenJDK MacOS用户显示。

原邮件

从 Joni Salonen 博客（具有无效字符的java和文件名称）我知道：

你可能知道Java使用默认字符编码到
将二进制数据转换为字符串。要使用另一个
编码读取或写入文本，您可以使用InputStreamReader或OutputStreamWriter。但
对于数据到文本的转换深深的API你没有选择，只有
更改默认编码。

和

file.encoding会怎样？

.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 = 
  pre> 
 
 
 stackoverflow最类似的问题是这样的：
  encoding-issues-on-java-7-- file-names-in-os-x  
 
 
 
但是解决方案是在一个脚本中包装java程序的执行。
 ＃！/ bin / bash 
 export LC_CTYPE =UTF-8＃尝试其他选项，如果这不工作
 exec java your.program.Here 
  
但我不认为这个选项是可用的，因为webstart，我没有找到任何方法设置LC_CTYPE 
 
 
 
任何解决方案或解决方法？
 
 
 
  PS ：
 
 
 
如果我们直接从shell运行程序，它甚至在OSX 10 + Java 7上正确写入文件/目录。
问题只出现在JNLP + OSX + Java7的组合
解决方案
我不认为这个问题有一个真正的解决方案，现在。
 
 
 
同时我得出结论，从程序内部打印的C环境变量来自Java Web Start沙盒，并且（设计，显然）你不能影响那些使用jnlp。
 
 
 
接受（公司接受）解决方法/ compromise是启动jnlp使用javash从bash脚本。 
 
 
 
显然，从浏览器或finder启动jnlp会创建一个没有设置LANG的新沙盒环境（因此设置为等于ASCII的C）。 
从命令行启动jnlp会从系统默认值打印正确的LANG，从shell继承它。
 
 
 
这允许至少保留自动更新功能的jnlp和依赖关系。
 
 
 
无论如何，我们向Oracle发送了一个错误报告，但个人我不希望它很快被解决。 p> 
I have this problem that has been dropped on me, and have been a couple of days of unsuccessful searches and workaround attempts. 

I have now an internal java swing program distributed by jnlp/webstart, on osx and windows computers, that, among other things, downloads some files from WebDav. 

Recently, on a test machine with OSX 10.8 and Java 7, filenames and directory names with accented characters started having those replaced by question marks. 

No problem on OSX with versions of Java before 7.

example :

XXXYYY_è_ABCD/

becomes

XXXYYY_?_ABCD/

using java.text.Normalizer (NFD, NFC, NFKD, NFKC) on the original string, the result is different but still wrong : 

XXXYYY_e?_ABCD/

or 

XXXYYY_e_ABCD/

I know, from correspondence between [andrew.brygin at oracle.com] and [mik3hall at gmail.com] that 

  
Yes, file.encoding is set based on the locale that the jvm is running 
  on, and if you run your java vm in xxxx.UTF-8 locale, the
  file.encoding should be UTF-8, set to MacRoman  will be problematic.
  So I believe Oracle/OpenJDK7 behaves correctly. That said, as Andrew 
  Thompson pointed out, if all previous Apple JDK releases use MacRoman
  as the file.encoding for  english/UTF-8 locale, there is a
  "compatibility" concern here, it might worth putting  something in the
  release note to give Oracle/OpenJDK MacOS user a heads up.
original mail

from Joni Salonen blog (java-and-file-names-with-invalid-characters) i know that : 

  
You probably know that Java uses a "default character encoding" to
  convert binary data to Strings. To read or write text using another
  encoding you can use an InputStreamReader or OutputStreamWriter. But
  for data-to-text conversions deep in the API you have no choice but to
  change the default encoding.
and

  
What about file.encoding?
  
  
The file.encoding system property can also be used to set the default
  character encoding that Java uses for I/O. Unfortunately it seems to
  have no effect on how file names are decoded into Strings.
executing locale from inside the jnlp invariabily prints 
LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
the most similar problem on stackoverflow with a solution is this : 
encoding-issues-on-java-7-file-names-in-os-x

but the solution is wrapping the execution of the java program in a script with
#!/bin/bash
export LC_CTYPE="UTF-8" # Try other options if this doesn't work
exec java your.program.Here
but I don't think this option is available to me because of the webstart, and I haven't found any way to set the LC_CTYPE environment variable from within the program.

Any solutions or workarounds?

P.S. :

If we run the program directly from shell, it writes the file/directory correctly even on OSX 10+Java 7. 
The problem appears only with the combination of JNLP+OSX+Java7
解决方案
I don't think there is a real solution to this problem, right now.

Meantime I came to the conclusion that the "C" environment variables printed from inside the program are from the Java Web Start sandbox, and (by design, apparently) you can't influence those using the jnlp.

The accepted (as accepted by the company) workaround/compromise was of launching the jnlp using javaws from a bash script. 

Apparently, launching the jnlp from browser or from finder creates a new sandbox environment with the LANG not setted (so is setted to "C" that is equal to ASCII). 
Launching the jnlp from command line instead prints the right LANG from the system default, inheriting it from the shell.

This permits to at least preserve the autoupdating feature of the jnlp and dependencies.

Anyway, we sent a bug report to Oracle, but personally I'm not hoping it to be resolved anytime soon, if ever.

                        
这篇关于使用Java 7在文件名上使用jnlp / webstart在OSX上编码问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！