After updating my distribution with Xfce 4.14, I am unable to copy and paste some characters into xfce4-terminal. For example, I can paste "test" but not "test α".
This is highly frustrating. I would prefer if the unknown character was replaced with a question mark, or anything really. Is there a way around this?
This was answered on SuperUser. Paraphrasing that answer:
Is the locale blank? It must be set to xxx.UTF-8 for the terminals to support non-ASCII characters. To enable Unicode support,
Add a line to /etc/locale.gen en_US.UTF-8 UTF-8
Run locale-gen
Add LANG=en_US.UTF-8 to /etc/locale.conf
Log out and log in again
The following must be set in xfce4-terminal:
preferences -> advanced -> default character encoding = UTF-8
The LANG environment variable in the shell does not matter, for example mine is set to LANG=en_US, but it's still working.
Is it possible to display chinese characters in command prompt? if so what are the settings.
If you need to read simplified Chinese (GBK) which is code page 936
Enter the following command in the dos prompt
chcp 936
I guess it's some settings in CMD
the default CMD doesn't support the unicode characters(including all other languages than English)
I don't know how to do it
But you can search about it "make CMD support unicode"
This question already has answers here:
How to use unicode characters in Windows command line?
(19 answers)
Closed 6 years ago.
I've tried to display UTF-8 in the win7 cmd. Currently, I'm using the standard font because as I see with the mysql.exe, it works fine with the characters I'm working with (currently the german umlauts "ßäöüÄÖÜ"). Also, with another font, the same characters appear.
But the output of my PHP script displays garbage, e.g. 'ß' for 'ß'. When I pipe the output into a file and open it up with Notepad++, it says the encoding is UTF-8. In php.ini I set UTF-8 as the encoding as well as in the connection to the mySQL database, and in the database itself UTF-8, too.
In CMD I tried so far to set the code page to 65001, but nothing changes.
edit: my PHP script is saved as UTF-8 as well
It seems with latin1, my desired characters can be displayed too and actually it works. But there has to be a way to do it in UTF-8? I can't convert everything to latin1
This question has been already answered in Unicode characters in Windows command line - how?
You missed one step -> you need to use Lucida console fonts in addition to executing chcp 65001 from cmd console.
I'm trying to print out some Unicode characters:
# encoding: utf-8
puts "ử ậ ắ ặ ố ồ"
If I run it through Powershell, this is what I get:
If I run it through cmd, this is what I get:
If I run it in Eclipse (with Aptana Studio 3 plugin), this is what I get:
Is it a problem with my system/software or is it Ruby's problem? How can I get it to work?
It works on Ideone though: http://ideone.com/PdycKH
Ruby supports it no problem, and setting the formatting at the top of the file is the way to go.
The issue is the display via the command line window. You need to use both a font and character page that supports Unicode display.
See this question regarding doing this in the Windows command line.
About the chcp command
I figured it out:
For cmd and Powershell, I have to change the font (I changed to Consolas)
In Eclipse, I have to change the encoding: go to Run/Run configurations, select the Common tab, change the Encoding to Other: UTF-8
I'm having trouble getting tmux to display lines for borders. They are being created with x and q. It's a debian squeeze server and the locale is set to en_US UTF8. I also tried adding
# instructs tmux to expect UTF-8 sequences
setw -g utf8 on
set -g status-utf8 on
lines to .tmux.conf. Nothing seems to work. I'm not sure if it's a locale issue or not. It displays correctly on other servers, but not the debian. I appreciate any tips you could offer! Thanks...
I had the same problem with PuTTY and Windows 8 when connecting to tmux running on a Debian Squeeze machine. Even when setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) I didn't get the correct line drawing.
Setting the Remote character set to "Use font encoding" did the trick for me.
There is some mismatch between your terminal emulator and the terminfo database entry being used by tmux (the one named by the TERM environment variable when you start/attach to a tmux server).
Per the VT100 User Guide, Table 3-9: Special Graphics Characters, when the “special graphics set” is selected, x is used to draw the “Vertical bar” and q is used to draw “Horizontal line - Scan 5”.
Under terminfo, the VT100 special graphics characters are available as a part of the Alternate Character Set functionality; see the “Line Graphics” section of the terminfo(5) man page.
Probably (on your Debian server) the effective terminfo database entry indicates that ACS is available, but your terminal emulator is not actually responding to the specified control sequences.
The tmux CHANGES file indicates that some terminal emulators (e.g. Putty) do not respect the ACS control sequences when they are in UTF-8 mode. Thus, tmux 1.4 has a change that makes it always use UTF-8 characters instead of ACS sequences when the attaching client specifies that it can handle UTF-8 (i.e. when attaching, -u was given or UTF-8 is present in LC_ALL, LC_CTYPE or LANG; the utf8 window option is about what tmux should expect from the programs it runs, not what it can send to the attached client).
Debian “squeeze” only includes tmux 1.3, so your tmux probably does not have the “prefer UTF-8 line drawing” feature (unless it pulls from a backports source).
If you can not fix your terminal emulator nor upgrade to at least tmux 1.4, then you might be able to use tmux’s terminal-overrides option to unset the ACS-related capabilities so that tmux will fall back to ASCII line drawing. In your .tmux.conf (on the Debian system):
set-option -ga terminal-overrides ',*:enacs#:smacs#:rmacs#:acsc#'
Try setting the character set to "UTF-8" and "Use Unicode line drawing code points" under Window -> Translation in your putty settings.
I had the same problem with Putty when launching tmux on Linux 12.04 machine. Even setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) didn't solve the problem.
Launching tmux with -u option did the trick (tmux -u)
If you have Putty 0.73 or higher open settings, expand Window category, then select Translation. Check 'Enable VT100 line drawing even in UTF-8 mode':
I ran thru the gamut of suggestions including:
confirming locale and UTF-8 setting in PuTTY
exporting NCURSES_NO_UT8_ACS=1
manually trying various fonts and PuTTY translation selections
Above did not work. Dialog displays showed qqqq... and xxxx with various corner characters.
Changing all dialog calls to include --ascii-lines was an option but it would involve a lot of script changes.
Best recommendation was to change the Remote Character Set to Use font encoding.
PuTTY Change Settings --> Window --> Translation --> Remote Character Set --> Use font encoding
Left all other PuTTY settings default.
I changed the setting in Putty for terminal to Latin-1 and that seemed to fix the problem.
If you are using KiTTY there is a check box under Windows -> Translation tab, that is called "Allow ACS line drawing in UTF". It needs to be checked:
For me the issue was I forgot to make a locale.conf file when I setup this Arch Linux box. Below line fixed the issue, substitute your own language. A reboot was not required for me.
echo "LANG=en_US.UTF-8" > /etc/locale.conf
under windows/ putty the font you use has to have the characters for it to display
set translation "UTF-8" and "Use Unicode line drawing code points" and font to "courier-new" and most of those problems go away
It seems the font choice is a confusing factor here, to wit:
Lucida sans doesn't display UTF-8 line drawing, only - + | (pipe)
substitution
Courier New Bold does horizontal lines but |
substitution for vertical
Courier New Normal does 'em all.