# Japanese characters in filenames



## i716 (Mar 12, 2017)

In my attempt to setup a file server I have encountered another problem: 
https://forums.freebsd.org/threads/60083/
All files that contain Japanese characters in their name are displayed as xxxxx.odt, xxxxx.doc, xxxxxx.pdf etc. I am not using X11 but it should be possible for the console to properly display the filenames. 

What can be done to solve the problem?


----------



## ShelLuser (Mar 12, 2017)

Which FreeBSD version do you use, also, how did you set up the console? The only way you're going to make this work is by using a graphical console, which can be set up using a specific console driver such as vt(4) or the older syscons(4).

For example, I could imagine using something like this in /boot/loader.conf:


```
kern.vty=vt
hw.vga.textmode=0
kern.vt.fb.default_mode="1024x768"
```
This will enable the graphical mode, including Unicode UTF-8 support, which should be all you need for Kanji.


----------



## i716 (Mar 12, 2017)

I am using 11 RELEASE and I have already set the vt options you mentioned above. Unfortunately, all non-Latin characters are displayed as question marks (kana, kanji and full width latin)

They are however displayed properly if accessed via samba share from Linux/Windows and Android. So the file names are still intact. 

It should also be mentioned that vidcontrol -i mode offers nothing in the list…

This was tested under Virtualbox and as a physical install on a Dell workstation which has both Intel graphics and a dedicated nvidia quadro card installed. But that should not be the problem since Arch works fine on this setup, even with the proprietary driver which also under Linux does not support KMS yet. 
When all testing and setup is done, the BSD will be installed on a seperate server anyways which will not need a dedicated graphics card.


----------



## scottro (Mar 12, 2017)

Without knowing your exact needs, this may be a waste of time, but if you are going to be accessing the server by ssh sessions from a workstation (which sounds as if it may be the case, as you mentioned it being installed on a separate machine), if that workstation can read Japanese from say, urxvt, ssh-ing into the BSD machine may show the filenames correctly.  I haven't tested this from FreeBSD to FreeBSD, but sshing from a FreeBSD machine, using X and urxvt enables me to properly read Japanese filenames on a remote CentOS-7 machine.


----------



## ShelLuser (Mar 12, 2017)

i716 said:


> I am using 11 RELEASE and I have already set the vt options you mentioned above.


Apart from what scottro said above also keep in mind that RELEASE is a developer snapshot. 'Bleeding edge' even, therefore there's no guarantee that anything will actually work as expected. RELENG (10.3 or 11.0) is what you should go for instead.


----------



## scottro (Mar 12, 2017)

By the way, when you say Arch works, are you using some sort of frame buffer?  I know that (at least last time I checked), you need fcitx-fbterm or similar to input Japanese in console.  As for reading it, these days, almost all my work is done from X using urxvt, and as mentioned, I can view Japanese (and input it as well) from an X session running urxvt.   Sometimes, I have to play around with some environment variables, but for my use cases (which aren't necessarily yours), that method works for me.
Actually, now that I think of it, don't most Linux systems use framebuffer for console?  I did find, using Arch without doing any extra configuration, that if I ssh into that CentOS box I mentioned earlier, from console, I am unable to read Japanese, it just shows me solid squares.  
I may be  misunderstanding what you're doing though. However, it sounds as if you mean that in Arch, without X, you were able to do ls or whatever in console, and read Japanese characters without further configuration. In my case, I wasn't able to do that without using X.  (The alternative would be setting up fcitx-fbterm or something else that does the same thing.)


----------



## i716 (Mar 12, 2017)

scottro

Thanks for your advice. I will try to use ssh next weekend, if it works, that would be a solution to my problem.

Regarding my Arch installation: It's already a few years old so I have made numerous changes to it over the time.
Only thing I remember right now sitting in a train is that Arch is configured with GRUB parameters for a proper screen resolution and the the splash screen thing (Plymouth). I usually boot straight into X for work, I don't know if Japanese input works on the console say in run level 3. But it can definitely display it correctly.

Text input in X is done via the fcitx IM (which also works if sshed in from a debian machine)


----------



## scottro (Mar 13, 2017)

Thanks for updating.  I'm _guessing_ that somewhere along the way you added something for it to be able to display properly in console (but all I did to test was copy over a file with a Japanese name, then do ls while in console.)

Hopefully, the ssh solution will work for you.


----------



## i716 (Mar 13, 2017)

scottro

This has not much to do with the actual problem, but since I just got home and am right in front of my desktop, I thought I'd post the HOOKS and GRUB config I use in Arch.


```
HOOKS="base udev plymouth autodetect modconf block filesystems keyboard keymap plymouth-encrypt lvm2 resume fsck"
```

And here are the grub parameters:


```
linux    /vmlinuz-linux-lts root=/dev/mapper/main-root rw  quiet splash cryptdevice=/dev/sda5:main resume=/dev/mapper/main-swap lang=en locale=en_US.UTF-8 nomodeset
```

It seems like I have to appologize since you were right. Kana/Kanji are NOT displayed correctly when booted into runlevel 3. Instead of a question mark I get filled squared boxes...


----------



## scottro (Mar 13, 2017)

Thank  you for taking the trouble to check and updating.  Have I spammed my page on this thread yet?  (Too lazy to scroll up). 

I cover using frame buffer to display (and input) Japanese in console at http://srobb.net/jpninpt.html  towards the end. (There's a small table of contents and it's the last one, fcitx-fbterm. )


----------



## i716 (Mar 14, 2017)

scottro

Thanks for the information regarding fcitx-fbterm. I will definitely give it a try!

Just some feedback on the BSD thing: If the server is accessed via SSH, I can type Japanese and all file names are displayed as they should. I think this is an acceptable solution for me since the server gets accessed only via SSH directly. Samba and DLNA servers already display names correctly, so everything's good.


----------



## scottro (Mar 14, 2017)

Great!  Glad to hear it.  The fcitx-fbterm is probably Linux only at this point.


----------



## nggroup247 (Mar 19, 2017)

i716 said:


> In my attempt to setup a file server I have encountered another problem:
> All files that contain Japanese characters in their name are displayed as xxxxx.odt, xxxxx.doc, xxxxxx.pdf etc. I am not using X11 but it should be possible for the console to properly display the filenames.
> 
> What can be done to solve the problem?


i think u must setup japanese language


----------



## jeymon (Mar 20, 2017)

Got same issue on FreeBSD 11.0-RELEASE-p1; easy to reproduce

$ cat ~/toto
touch "指輪物語.tst"

$ ls ~/*.tst
/home/jym/????????????.tst

$ ls -1 ~/*.tst > /tmp/ls
$ cat /tmp/ls
指輪物語.tst

This issue seems to be related only to ls command.


----------



## jeymon (Mar 20, 2017)

Solved: $ export LANG="${LANG:-en_US.UTF-8}"
$ ls *.tst
指輪物語.tst


----------

