How to make Windows file associations work with non-ASCII file names?

Question

I need to register the file association for a certain file type - in fact, I just need to launch a certain Java program with certain arguments and a name of that file.

I got as far as the following:

// in fff-assoc.cmd file:
assoc .fff=SomeFile
ftype SomeFile=java -jar some.jar <arguments1> "%%1" <arguments2>

It works properly for ASCII file names. But when I try to double-click some file with non-ASCII symbols in name, the argument passed looks like "????" (int value of each char = 63).

How can I fix those associations?

Answer 1

If what bobince says is accurate and you cannot reliably get the data to java directly, one alternative solution would be to write a small "shim" program in another language (e.g. C, C++ or C#).

The idea is that the program grabs the input as UNICODE, encodes it so that it's expressible using only ASCII characters (e.g. by using base64, or even something as simple as encoding every character as its numerical equivalent) and then assembles the command line argument to use and launches java itself using CreateProcess.

Your Java code could "undo" the encoding, reconstructing the UNICODE name and proceeding to use it. It's a bit of a roundabout way and requires an extra component for your software, but it should work around the restriction detailed above, if indeed that is an actual restriction.

Update: This is the basic code for the shim program. It encodes input as a sequence of integers, separated by colons. It doesn't do much in the way of error checking and you might want to improve it slightly, but it should at least get you started and going in the right direction.

You should grab Visual Studio Express (if you don't already have Visual Studio) and create a new Visual C++ project, choose "Win32" and select "Win32 Project". Choose "Win32 application". After the project is created, replace everything in the .cpp file that is displayed with this code:

#include "stdafx.h"
#include <string>

int APIENTRY _tWinMain(HINSTANCE, HINSTANCE, LPTSTR lpCmdLine, int)
{
    std::string filename;

    while((lpCmdLine != NULL) && (*lpCmdLine != 0))
    {
        if(filename.length() != 0)
            filename.append(":");

        char buf[32];

        sprintf(buf, "%u", (unsigned int)(*lpCmdLine++));

        filename.append(buf);   
    }

    if(filename.length() == 0)
        return 0;

    PROCESS_INFORMATION pi;
    memset(&pi, 0, sizeof(PROCESS_INFORMATION));

    STARTUPINFOA si;
    memset(&si, 0, sizeof(STARTUPINFOA));
    si.cb = sizeof(STARTUPINFOA);

    char *buf = new char[filename.length() + 256]; // ensure that 256 is enough for your extra arguments!

    sprintf(buf, "java.exe -jar some.jar <arguments1> \"%s\" <arguments2>", filename.c_str());

    // CHECKME: You hard-coded the path for java.exe here. While that may work on your system
    // is it guaranteed that it will work on every system?

    if(CreateProcessA("C:\\Program Files\\Java\\jre7\\bin\\java.exe", buf, NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi))
    {
        CloseHandle(pi.hThread);
        CloseHandle(pi.hProcess);
    }

    delete[] buf;

    return 0;
}

You should be able to figure the details on how to compile and so on fairly easily.

Answer 2

I just need to launch a certain Java program with certain arguments and a name of that file.

Unfortunately this 'just' is not actually possible, due to the MS implementation of the standard C library that Java uses to receive argument input (amongst other things). Unless you go straight to the native Win32 API, bypassing standard Java or C interfaces,

See this question for background.

Answer 3

When calling java from the command line, you can specify the encoding of the parameters (which will be used to create the strings in args[]):

java -jar -Dsun.jnu.encoding=cp1252 yourFileName

When using non-ASCII characters, the specified charset has an impact on the value of args[0]. Not sure if that would apply to file associations though.

Note: I'm not sure what other uses that parameter has - this post seems to say none.