#22884 closed defect (duplicate)
File open dialog does not support swedish characters
| Reported by: | anonymous | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Core | Version: | |
| Keywords: | template_report | Cc: | yrafyra@… |
Description
What steps will reproduce the problem?
- Open file dialog to load gpx file
- It bugs always when entering my home folder on Ubuntu 22.04 (100% reproducible)
- The problem seems to be that I'm running Ubuntu in swedish and my Download folder is called "Hämtningar". The swedish letter Ä ä is the issue.
What is the expected result?
Files should be listed
What happens instead?
Bug window and no file displayed for my home folder.
Please provide any additional information below. Attach a screenshot if possible.
Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2023-03-01 15:17:42 +0100 (Wed, 01 Mar 2023)
Revision:18678
Build-Date:2023-03-02 02:30:57
URL:https://josm.openstreetmap.de/svn/trunk
Identification: JOSM/1.5 (18678 en) Linux Ubuntu 22.04.2 LTS
Memory Usage: 264 MB / 1958 MB (172 MB allocated, but free)
Java version: 11.0.16+8-post-Ubuntu-0ubuntu120.04, Ubuntu, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: sv_SE.UTF-8
System property file.encoding: ANSI_X3.4-1968
System property sun.jnu.encoding: ANSI_X3.4-1968
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: ubuntu:GNOME
VM arguments: [-Duser.home=${HOME}]
Last errors/warnings:
- 00225.817 E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /home/<user.name>/H��mtningar
- 00225.835 E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /home/<user.name>/H��mtningar
- 00225.840 E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /home/<user.name>/H��mtningar
- 00251.816 E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /home/<user.name>/H��mtningar
- 00383.007 E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /home/<user.name>/H��mtningar
- 00399.333 W: Warning - <html>Cannot open 1 file because file does not exist or no suitable file importer is available.<br><ul><li>/home/<user.name>/Hämtningar (<i>does not exist</i>)</li></ul></html>
- 00405.888 E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /home/<user.name>/H��mtningar
- 00405.900 E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /home/<user.name>/H��mtningar
=== REPORTED CRASH DATA ===
BugReportExceptionHandler#handleException:
No data collected.
Warning issued by: BugReportExceptionHandler#handleException
=== STACK TRACE ===
Thread: Basic L&F File Loading Thread (138)
java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /home/broms/H��mtningar
at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
at java.base/java.nio.file.Path.of(Path.java:147)
at java.base/java.nio.file.Paths.get(Paths.java:69)
at java.desktop/sun.awt.shell.ShellFolder.getShellFolder(ShellFolder.java:247)
at java.desktop/javax.swing.filechooser.FileSystemView.getFiles(FileSystemView.java:523)
at java.desktop/javax.swing.plaf.basic.BasicDirectoryModel$FilesLoader.run0(BasicDirectoryModel.java:300)
at java.desktop/javax.swing.plaf.basic.BasicDirectoryModel$FilesLoader.run(BasicDirectoryModel.java:289)
at java.base/java.lang.Thread.run(Thread.java:829)
Attachments (0)
Change History (10)
comment:1 by , 14 months ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
comment:2 by , 14 months ago
It feels really strange that you duplicate it to a ticket that was duplicated to another ticket that was closed as invalid 6 years ago.
I think this is a problem that will happen for many users.
I had installed JOSM on Ubuntu 22.04 using the built in software downloader in Ubuntu. I know that is not the latest version of JOSM, but good enough for most users. I therefore think that setup should work out of the box with any language settings made by normal users.
comment:3 by , 14 months ago
Was meant to go to the final target #14596. I mixed up a bit. See there.
Issue very likely is that you use Flatpak or something similar and the authors of the package don't fix the wrong setup. There is not much we can do about this.
If the system tells JOSM to use wrong charset, then JOSM wont work correct.
Environment variable LANG: sv_SE.UTF-8
System property file.encoding: ANSI_X3.4-1968
System property sun.jnu.encoding: ANSI_X3.4-1968
There should be UTF-8 everywhere for a modern Linux.
comment:4 by , 14 months ago
Identification: JOSM/1.5 (18678 en) Linux Ubuntu 22.04.2 LTS
Java version: 11.0.16+8-post-Ubuntu-0ubuntu120.04, Ubuntu, OpenJDK 64-Bit Server VM
VM arguments: [-Duser.home=${HOME}]
I think they are using the josm-tested.jar file and running it with java -jar ${path_to_jar}. They are not using the flatpak (Identification: JOSM/1.5 (18565) Linux Freedesktop.org 21.08.15 (Flatpak runtime)).
@anonymous: Can you try with Java 18+? Ubuntu 22.04 has both Java 18 and Java 19 in their repos. You might also want to look at source:trunk/native/linux/tested/usr/bin/josm -- there are some missing VM arguments that may prevent other bugs.
comment:5 by , 14 months ago
If I do a simple java -jar /usr/share/java/josm-tested.jar on openSUSE I get
Environment variable LANG: de_DE.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
which is logical, as my disks are mounted with UTF-8 encoded filenames (using java 19).
follow-up: 8 comment:6 by , 14 months ago
I think this might be an Ubuntu thing (or maybe a Debian thing -- I haven't checked Debian). In a ubuntu:22.04 container, I ran java -jar josm-tested.jar --status-report and it had
System property file.encoding: ANSI_X3.4-1968 System property sun.jnu.encoding: ANSI_X3.4-1968
There was no LANG output (by default); there was if I set the LANG env variable to en_US.UTF-8, but the file.encoding and sun.jnu.encoding did not change.
I didn't see that on my Pi (Ubuntu 22.10), so it is possible that 22.04 is just borked, or users upgraded from an older version and the appropriate settings weren't updated, or something else.
comment:8 by , 14 months ago
Replying to taylor.smock:
There was no
LANGoutput (by default); there was if I set theLANGenv variable toen_US.UTF-8, but thefile.encodingandsun.jnu.encodingdid not change.
Yes, I remember problems installing a minimal OS with no LANG or LANG=C set and changing it later.
comment:9 by , 14 months ago
I downloaded josm-tested.jar (18700) and ran it with java-11. It worked nicely, no issues with strange characters.
I think the problem is related to how JOSM is started.
My "josm" executable is linked to snap, and could find this page: https://snapcraft.io/josm
Maybe that is someone to contact...
comment:10 by , 14 months ago
OK. Good to know. I've opened another ticket for updating the snap for Ubuntu (see #22887). It isn't going to be easy, since I don't think anyone on the team is familiar with snap packaging, and when I looked into it awhile back, there were a lot of things that needed to be changed.
Closed as duplicate of #22853.