Under Wine I run a Japanese game which has some text files whose names use Shift_JIS encoding (found at https://www.dropbox.com/sh/rjtmd247d6c6uma/AAAR3f6fPu3CWwmuVzZfA7rGa/elonaplus1.58.zip?dl=0). If I try to open such a file with kwrite it tells me that the file wasn't found. Reproducible: Always Choosing the file with "kdialog --getopenfilename" doesn't raise any problems.
Actually, it might be a file-opener dialog after all. If I do "vi *.txt", I can get vi to open the files (even though it displays as binary data), but if I do "vi `kdialog --getopenfilename .`" it gives an error. So I think the open file dialog is changing characters it can't recognize to different characters before passing it on elsewhere.
Dropbox link does not work. Is the file too big to be attached?
Created attachment 100000 [details] Tarball containing some shift_JIS file names That was a download link for an earlier version of the full game; attached is just the text files, some of which are shift_JIS.
I can open the files using Kate either from Dolphin or Kate's file open dialog. Arch Linux 64-bit Kate 16.04.2 KDE Frameworks 5.23.0 Qt 5.7 xcb wm
My versions: Kwrite 16.04.2 KDE Frameworks 5.23.0
Could it maybe be an environmental variable? If I set LC_ALL=C or LC_ALL=en it makes the output of "kdialog --getopenfilename ." change (though it's still not the correct output).
Oops, should have included, my current environment has: LANG=en_US.UTF-8 LANGUAGE=en_US
Already the file dialog can't handle that files (KF5), KDE 4 based file dialog does handle it well (kdialog).
I can reproduce this issue with Kate 20.08.03 and, huh, kio 5.20.2 (that's what kioclient5 --version states). The tarball contains four files that can be opened with Kate and five with what I assume are japanese characters (they're rendered as squares) plus (elona) or (elonaplus) in their name, those are the ones that do not open on Kate. Dolphin displays a chainlock on the bottom right of their icons. Opening them by clicking makes Kate state the file does not exist. Opening the embedded terminal and opening a file with Kate (like with fish autocompletion) leads to Kate creating a new empty file with the same name. Neither vi or nano seem to render japanese characters correctly (but it might be because I didn't specifically install japanese fonts). Renaming any of those files using the default encoding allows the file to be opened by Kate, and after opening, the text inside shows up in proper japanese.