Japanese characters in filenames

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:

Code: 
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.
 
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.
 
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.
 
i716 said:
I am using 11 RELEASE and I have already set the vt options you mentioned above.
Click to expand...
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.
 
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.)
 
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)
 
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.
 
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.

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

And here are the grub parameters:

Code: 
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...
 
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. )
 
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.
 
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.
 
You must log in or register to reply here.
Back
Top