Using UTF-8 with Gentoo(st)
时间:2006-04-09 来源:rwen2012
Thomas Martin Author
Alexander Simonov Contributor
Shyam Mani Editor
Updated March 19, 2006
1. Character Encodings
Computers do not understand text themselves. Instead, every character is represented by a number. Traditionally, each set of numbers used to represent alphabets and characters (known as a coding system, encoding or character set) was limited in size due to limitations in computer hardware.
The History of Character Encodings
The most common (or at least the most widely accepted) character set is ASCII (American Standard Code for Information Interchange). It is widely held that ASCII is the most successful software standard ever. Modern ASCII was standardised in 1986 (ANSI X3.4, RFC 20, ISO/IEC 646:1991, ECMA-6) by the American National Standards Institute.
ASCII is strictly seven-bit, meaning that it uses bit patterns representable with seven binary digits, which provides a range of 0 to 127 in decimal. These include 32 non-visible control characters, most between 0 and 31, with the final control character, DEL or delete at 127. Characters 32 to 126 are visible characters: a space, punctuation marks, Latin letters and numbers.
The eighth bit in ASCII was originally used as a parity bit for error checking. If this is not desired, it is left as 0. This means that, with ASCII, each character is represented by a single byte.
Although ASCII was enough for communication in modern English, in other European languages that include accented characters, things were not so easy. The ISO 8859 standards were developed to meet these needs. They were backwards compatible with ASCII, but instead of leaving the eighth bit blank, they used it to allow another 127 characters in each encoding. ISO 8859's limitations soon came to light, and there are currently 15 variants of the ISO 8859 standard (8859-1 through to 8859-15). Outside of the ASCII-compatible byte range of these character sets, there is often conflict between the letters represented by each byte. To complicate interoperability between character encodings further, Windows-1252 is used in some versions of Microsoft Windows instead for Western European languages. This is a superset of ISO 8859-1, however it is different in several ways. These sets do all retain ASCII compatibility, however.
The necessary development of completely different single-byte encodings for non-Latin alphabets, such as EUC (Extended Unix Coding) which is used for Japanese and Korean (and to a lesser extent Chinese) created more confusion, while other operating systems still used different character sets for the same languages, for example, Shift-JIS and ISO-2022-JP. Users wishing to view cyrillic glyphs had to choose between KOI8-R for Russian and Bulgarian or KOI8-U for Ukrainian, as well as all the other cyrillic encodings such as the unsuccessful ISO 8859-5, and the common Windows-1251 set. All of these character sets broke most compatibility with ASCII (although KOI8 encodings place cyrillic characters in Latin order, so in case the eighth bit is stripped, text is still decipherable on an ASCII terminal through case-reversed transliteration.)
This has led to confusion, and also to an almost total inability for multilingual communication, especially across different alphabets. Enter Unicode.
Unicode throws away the traditional single-byte limit of character sets. It uses 17 "planes" of 65,536 code points to describe a maximum of 1,114,112 characters. As the first plane, aka. "Basic Multilingual Plane" or BMP, contains almost everything you will ever use, many have made the wrong assumption that Unicode was a 16-bit character set.
Unicode has been mapped in many different ways, but the two most common are UTF (Unicode Transformation Format) and UCS (Universal Character Set). A number after UTF indicates the number of bits in one unit, while the number after UCS indicates the number of bytes. UTF-8 has become the most widespread means for the interchange of Unicode text as a result of its eight-bit clean nature, and it is the subject of this document.
UTF-8 is a variable-length character encoding, which in this instance means that it uses 1 to 4 bytes per symbol. So, the first UTF-8 byte is used for encoding ASCII, giving the character set full backwards compatibility with ASCII. UTF-8 means that ASCII and Latin characters are interchangeable with little increase in the size of the data, because only the first bit is used. Users of Eastern alphabets such as Japanese, who have been assigned a higher byte range are unhappy, as this results in as much as a 50% redundancy in their data.
UTF-8 allows you to work in a standards-compliant and internationally accepted multilingual environment, with a comparatively low data redundancy. UTF-8 is the preferred way for transmitting non-ASCII characters over the Internet, through Email, IRC or almost any other medium. Despite this, many people regard UTF-8 in online communication as abusive. It is always best to be aware of the attitude towards UTF-8 in a specific channel, mailing list or Usenet group before using non-ASCII UTF-8.
2. Setting up UTF-8 with Gentoo Linux
Finding or Creating UTF-8 Locales
Now that you understand the principles behind Unicode, you're ready to start using UTF-8 with your system.
The preliminary requirement for UTF-8 is to have a version of glibc installed that has national language support. The recommend means to do this is the /etc/locales.build file in combination with the userlocales USE flag. It is beyond the scope of this document to explain the usage of this file though, luckily, the usage of this file is well documented in the comments within it. It is also explained in the Gentoo Localisation Guide.
Next, we'll need to decide whether a UTF-8 locale is already available for our language, or whether we need to create one.
Code Listing 2.1: Checking for an existing UTF-8 locale |
(Replace "en_GB" with your desired locale setting) # locale -a | grep 'en_GB' en_GB en_GB.UTF-8 |
From the output of this command line, we need to take the result with a suffix similar to .UTF-8. If there is no result with a suffix similar to .UTF-8, we need to create a UTF-8 compatible locale.
Note: Only execute the following code listing if you do not have a UTF-8 locale available for your language. |
Code Listing 2.2: Creating a UTF-8 locale |
(Replace "en_GB" with your desired locale setting) # localedef -i en_GB -f UTF-8 en_GB.UTF-8 |
Another way to include a UTF-8 locale is to add it to the /etc/locales.build file and rebuild glibc with the userlocales USE flag set.
Code Listing 2.3: Line in /etc/locales.build |
en_GB.UTF-8/UTF-8 |
There is one environment variable that needs to be set in order to use our new UTF-8 locales: LC_ALL (this variable overrides the LANG setting as well). There are also many different ways to set it; some people prefer to only have a UTF-8 environment for a specific user, in which case they set them in their ~/.profile (if you use /bin/sh), ~/.bash_profile or ~/.bashrc (if you use /bin/bash).
Others prefer to set the locale globally. One specific circumstance where the author particularly recommends doing this is when /etc/init.d/xdm is in use, because this init script starts the display manager and desktop before any of the aforementioned shell startup files are sourced, and so before any of the variables are in the environment.
Setting the locale globally should be done using /etc/env.d/02locale. The file should look something like the following:
Code Listing 2.4: Demonstration /etc/env.d/02locale |
(As always, change "en_GB.UTF-8" to your locale) LC_ALL="en_GB.UTF-8"
|
Next, the environment must be updated with the change.
Code Listing 2.5: Updating the environment |
# env-update >>> Regenerating /etc/ld.so.cache... * Caching service dependencies ... # source /etc/profile |
Now, run locale with no arguments to see if we have the correct variables in our environment:
Code Listing 2.6: Checking if our new locale is in the environment |
# locale LANG= LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL=en_GB.UTF-8
|
That's everything. You are now using UTF-8 locales, and the next hurdle is the configuration of the applications you use from day to day.
3. Application Support
When Unicode first started gaining momentum in the software world, multibyte character sets were not well suited to languages like C, in which many of the day-to-day programs people use are written. Even today, some programs are not able to handle UTF-8 properly. Fortunately, most are!
There are several NLS options in the Linux kernel configuration menu, but it is important to not become confused! For the most part, the only thing you need to do is to build UTF-8 NLS support into your kernel, and change the default NLS option to utf8.
Code Listing 3.1: Kernel configuration steps for UTF-8 NLS |
File Systems --> Native Language Support --> (utf8) Default NLS Option <*> NLS UTF8 (Also <*> other character sets that are in use in your FAT filesystems or Joilet CD-ROMs.)
|
If you plan on mounting NTFS partitions, you may need to specify an nls= option with mount. If you plan on mounting FAT partitions, you many need to specify a codepage= option with mount. Optionally, you can also set a default codepage for FAT in the kernel configuration. Note that the codepage option with mount will override the kernel settings.
Code Listing 3.2: FAT settings in kernel configuration |
File Systems --> DOS/FAT/NT Filesystems --> (437) Default codepage for fat |
You should avoid setting Default iocharset for fat to UTF-8, as it is not recommended. Instead, you may want to pass the option utf8=true when mounting your FAT partitions. For further information, see man mount and the kernel documentation at /usr/src/linux/Documentation/filesystems/vfat.txt.
For changing the encoding of filenames, app-text/convmv can be used.
Code Listing 3.3: Example usage of convmv |
# emerge --ask app-text/convmv (Command format) # convmv -f <current-encoding> -t utf-8 <filename> (Substitute iso-8859-1 with the charset you are converting from) # convmv -f iso-8859-1 -t utf-8 filename |
For changing the contents of files, use the iconv utility, bundled with glibc:
Code Listing 3.4: Example usage of iconv |
(substitute iso-8859-1 with the charset you are converting from) (Check the output is sane) # iconv -f iso-8859-1 -t utf-8 filename (Convert a file, you must create another file) # iconv -f iso-8859-1 -t utf-8 filename > newfile |
app-text/recode can also be used for this purpose.
Important: You need >=sys-apps/baselayout-1.11.9 for Unicode on the console. |
To enable UTF-8 on the console, you should edit /etc/rc.conf and set UNICODE="yes", and also read the comments in that file -- it is important to have a font that has a good range of characters if you plan on making the most of Unicode.
The KEYMAP variable, set in /etc/conf.d/keymaps, should have a Unicode keymap specified.
Code Listing 3.5: Example /etc/conf.d/keymaps snippet |
(Change "uk" to your local layout) KEYMAP="uk"
|
Note: Ignore any mention of Slang in this section if you do not have it installed or do not use it. |
It is wise to add unicode to your global USE flags in /etc/make.conf, and then to remerge sys-libs/ncurses and sys-libs/slang if appropriate. Portage will do this automatically when you update your system:
Code Listing 3.6: Updating your system |
# emerge --update --deep --newuse world
|
We also need to rebuild packages that link to these, now the USE changes have been applied. The tool we use (revdep-rebuild) is part of the gentoolkit package.
Code Listing 3.7: Rebuilding of programs that link to ncurses or slang |
# revdep-rebuild --soname libncurses.so.5 # revdep-rebuild --soname libslang.so.1 |
All of the major desktop environments have full Unicode support, and will require no further setup than what has already been covered in this guide. This is because the underlying graphical toolkits (Qt or GTK+2) are UTF-8 aware. Subsequently, all applications running on top of these toolkits should be UTF-8-aware out of the box.
The exceptions to this rule come in Xlib and GTK+1. GTK+1 requires a iso-10646-1 FontSpec in the ~/.gtkrc, for example -misc-fixed-*-*-*-*-*-*-*-*-*-*-iso10646-1. Also, applications using Xlib or Xaw will need to be given a similar FontSpec, otherwise they will not work.
Note: If you have a version of the gnome1 control center around, use that instead. Pick any iso10646-1 font from there. |
Code Listing 3.8: Example ~/.gtkrc (for GTK+1) that defines a Unicode compatible font |
style "user-font" { fontset="-misc-fixed-*-*-*-*-*-*-*-*-*-*-iso10646-1" } widget_class "*" style "user-font" |
If an application has support for both a Qt and GTK+2 GUI, the GTK+2 GUI will generally give better results with Unicode.
Important: x11-base/xorg-x11 has far better support for Unicode than XFree86 and is highly recommended. |
TrueType fonts have support for Unicode, and most of the fonts that ship with Xorg have impressive character support, although, obviously, not every single glyph available in Unicode has been created for that font. To build fonts (including the Bitstream Vera set) with support for East Asian letters with X, make sure you have the cjk USE flag set. Many other applications utilise this flag, so it may be worthwhile to add it as a permanent USE flag.
Also, several font packages in Portage are Unicode aware.
Code Listing 3.9: Optional: Install some more Unicode-aware fonts |
# emerge terminus-font intlfonts freefonts cronyx-fonts corefonts
|
Window Managers and Terminal Emulators
Window managers not built on GTK or Qt generally have very good Unicode support, as they often use the Xft library for handling fonts. If your window manager does not use Xft for fonts, you can still use the FontSpec mentioned in the previous section as a Unicode font.
Terminal emulators that use Xft and support Unicode are harder to come by. Aside from Konsole and gnome-terminal, the best options in Portage are x11-terms/rxvt-unicode, xfce-extra/terminal, gnustep-apps/terminal, x11-terms/mlterm, or plain x11-terms/xterm when built with the unicode USE flag and invoked as uxterm. app-misc/screen supports UTF-8 too, when invoked as screen -U or the following is put into the ~/.screenrc:
Code Listing 3.10: ~/.screenrc for UTF-8 |
defutf8 on |
Vim provides full UTF-8 support, and also has builtin detection of UTF-8 files. For further information in Vim, use :help mbyte.txt.
Emacs 22.x and higher has full UTF-8 support as well. Xemacs 22.x does not support combining characters yet.
Lower versions of Emacs and/or Xemacs might require you to install app-emacs/mule-ucs and/or app-xemacs/mule-ucs and add the following code to your ~/.emacs to have support for CJK languages in UTF-8:
Code Listing 3.11: Emacs CJK UTF-8 support |
(require 'un-define) (require 'jisx0213) (set-language-environment "Japanese") (set-default-coding-systems 'utf-8) (set-terminal-coding-system 'utf-8) |
Nano has provided full UTF-8 support since version 1.3.6.
Currently, bash provides full Unicode support through the GNU readline library. Z Shell users are in a somewhat worse position -- no parts of the shell have Unicode support, although there is a concerted effort to add multibyte character set support underway at the moment.
The C shell, tcsh and ksh do not provide UTF-8 support at all.
Irssi has complete UTF-8 support, although it does require a user to set an option.
Code Listing 3.12: Enabling UTF-8 in Irssi |
/set term_charset UTF-8 |
For channels where non-ASCII characters are often exchanged in non-UTF-8 charsets, the /recode command may be used to convert the characters. Type /help recode for more information.
The Mutt mail user agent has very good Unicode support. To use UTF-8 with Mutt, you don't need to put anything in your configuration files. Mutt will work under unicode enviroment without modification if all your configuration files (signature included) are UTF-8 encoded.
Note: You may still see '?' in mail you read with Mutt. This is a result of people using a mail client which does not indicate the used charset. You can't do much about this than to ask them to configure their client correctly. |
Further information is available from the Mutt Wiki.
We all use a lot of more or less along with the | to be able to correctly see the output of a command, like for example dmesg | less. While more only needs the shell to be UTF-8 aware, less needs an environment variabl