Japanese characters from args giving question marks on Japanese OS

Question

Hi,
We are internationalising our product to japanese, and one of the features is to be able to open a file containing japanese characters from a double click on a japanese windows OS.
The double click is set up in the registry, and indeed it works properly for most characters. There are a few characters though (unicode character 20060 among them) that it doesn't work for, and what happens is that between the double clicking of the file, and the command line name of the file to open ("%1" in the registry / args[0] in java), the character in question is converted into the literal character for "?" (ascii 63), and java can't open the file.
Testing wordpad directly with this character is fine, the file opens. I've written a simple C++ app and a simple JAVA app which fork wordpad with the fileName param passed to it from the registry, and it didn't open the file passed because of that character.
So our java application, a simple java program and a simple C++ program can't resolve the fileName passed to it because of this character.
The thing is, wordpad is using the same regedit method to get its parameters as we do ("appName.exe" "%1" in shell/open/command) and it opens files containing this character without a problem.
Any ideas on what I'm missing?
Thanks very much
Jack

Answer 1

Hi,
We are internationalising our product to japanese,
and one of the features is to be able to open a file
containing japanese characters from a double click on
a japanese windows OS.
The double click is set up in the registry, and
indeed it works properly for most characters. There
are a few characters though (unicode character 20060
among them) that it doesn't work for, and what
happens is that between the double clicking of the
file, and the command line name of the file to open
("%1" in the registry / args[0] in java), the
character in question is converted into the literal
character for "?" (ascii 63), and java can't open the
file.
Testing wordpad directly with this character is fine,
the file opens. I've written a simple C++ app and a
simple JAVA app which fork wordpad with the fileName
param passed to it from the registry, and it didn't
open the file passed because of that character.
So our java application, a simple java program and a
simple C++ program can't resolve the fileName passed
to it because of this character.
The thing is, wordpad is using the same regedit
method to get its parameters as we do ("appName.exe"
"%1" in shell/open/command) and it opens files
containing this character without a problem.
Any ideas on what I'm missing?
Thanks very much
JackUnicode 20060 belongs to an extended part of JIS Kanji code set and there can be many
applications or systems that do not support those characters. Shift_JIS doesn't and
EUC-JP use 24 bit code for representig those chars which, unfortunately, aren't supported
by most exixting apps.