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
