Application getParameters() not returning Umlaute properly

[John Hendrikx]

On 11/04/2022 08:15, Daniel Peintner wrote:
> All,
>
> I run into a *strange* behaviour.
>
> In my application I associate a file extension which works fine. Clicking
> on the desktop opens the app and loads the file I clicked on.
>
> This works fine for Windows and Mac on its own.
>
> Assume a file named "Kostenschätzung.avax" is stored on MacOS and gets
> opened afterwards on Windows it fails. The filename on Windows is shown
> correctly but after clicking on it on Windows the following call
Where is this file stored? On a shared NAS? With SMB?
> [javafx.application.Application].getParameters().getRaw()
>
> --> reports ->
>
> [C:\...\Kostenscha¨tzung.avax]
>
> As you can see the character "ä" becomes "a¨".

That second character is a special unicode character that should be 
combined with the previous character.

> Note: loading of the file fails because this file does not exist.
>
> Choosing the file via FileChooser and storing it again on Windows solves
> the problem.

What happens here is that the filename when you save it with Windows 
gets stored differently, even though they look the same. The accented 
character is no longer stored as "a" + separate umlaut (0x61 0xcc88) but 
as a composed character (0xc3a4).

Try this in Java to see the two different codes which result in the same 
character: System.out.println("\u00e4 vs a\u0308");

See also here: 
https://stackoverflow.com/questions/6153345/different-utf8-encoding-in-filenames-os-x

For some reason, the parameters provided via the command line don't seem 
to properly decode the second form (a + composing umlaut) but do 
understand the first form (precomposed a-umlaut). This could be JavaFX, 
but could be lower level as well.  You could see what happens if you do 
this with a non-JavaFX program, and get the parameters directly from a 
`main` method.

--John