runidn(1) [suse man page]
RUNIDN(1) General Commands Manual RUNIDN(1) NAME
runidn - A script to allow applications to use internationalized domain names. SYNOPSIS
runidn [-e local-codeset] program-name [args..] DESCRIPTION
runidn enables applications to use internationalized domain names without recompilation. Just add ``runidn'' before the application-name, and the application can handle non-ASCII domain names. For example, you can do: % runidn telnet non-ASCII-hostname Before using runidn, you should set up properties related to internationalized DNS by configuring idnkit's configuration file idn.conf. See idn.conf(5) which describes the configuration. OPTION
The following option is available: -e local-codeset Specify the application's local codeset. If the option is not specified, runidn guesses the codeset from the current locale. See the ``NOTE'' section for more details about local codeset. IMPLEMENTATION
runidn is a small shell script that sets up an environment variable called ``LD_PRELOAD'', so that an application dynamically links a shared library ``libidnkitres'' before any other shared libraries. The library ``libidnkitres'' provides a special version of resolver functions which implement features for handling internationalized domain names. runidn replaces the following functions with the special version: gethostbyname gethostbyname2 gethostbyaddr gethostbyname_r gethostbyname2_r gethostbyaddr_r getipnodebyname getipnodebyaddr freehostent getaddrinfo freeaddrinfo getnameinfo By overriding them in the standard libraries with the special version provided by ``libidnkitres'', runidn enables applications to use internationalized domain names. o These API functions accept non-ASCII domain names encoded in the local codeset that the application is using. Also the result from these APIs may contain non-ASCII domain names. o The normalization and codeset conversion between application's local codeset and the codeset used in DNS protocol data are handled automatically, so users/applications need not worry about them. Properties of internationalized DNS (such as the normalization or the codeset used on DNS protocol data) can be configured with the idnkit's configuration file (idn.conf). See idn.conf(5) for details. NOTE
Unless -e option is specified, runidn tries to guess the application's local codeset from the application's current locale. However, some- times it cannot guess the codeset correctly, for example if the application does not set the locale appropriately by calling `setlocale()'. In that case, you can explicitly specify the local codeset by setting an environment variable ``IDN_LOCAL_CODESET''. See the section ``LOCAL CODESET'' in idn.conf(5) for details. The idea of using ``LD_PRELOAD'' to replace some functions in the standard library was taken from ``runsocks'' script distributed as part of SOCKS5 reference implementation. BUGS
There are many cases where runidn does not work. Your system must support ``LD_PRELOAD'' mechanism in the first place. Due to security reasons, ``LD_PRELOAD'' mechanism is disabled for setuid programs in any sane systems. So runidn does not work for setuid programs such as ping or rsh. If your application uses a function other than the ones runidn supports for name resolution, you lose. SEE ALSO
idn.conf(5), runsocks(1) April 6, 2001 RUNIDN(1)
Check Out this Related Man Page
idn.conf(5) File Formats Manual idn.conf(5) NAME
idn.conf, .idnrc, idnalias.conf - configuration files for idnkit library SYNOPSIS
/etc/idn.conf ~/.idnrc /etc/idnalias.conf DESCRIPTION
idn.conf and .idnrc are configuration files for idnkit library which is a toolkit for handling internationalized domain names. idnkit library tries to load the user's configuration file ~/.idnrc first, and then tries the system configutation file /etc/idn.conf. Note that idnkit library loads either, not both. To use internationalized domain names in DNS or other protocols, they must be converted to an appropriate format before further processing. In idnkit, this conversion process is comprised of the following tasks. 1. Convert the given domain name in application's local codeset to Unicode, and vice versa. 2. Map certain characters in the name to period character so that they are treated as the domain name delimiter (delimiter mapping). 3. Map certain characters in the name to other characters or chracter sequences, according to a mapping rule determined by its top level domain (TLD). 4. Perform NAMEPREP, which is a starndard name preparation process for internationalized domain names. This process is composed of the tree steps called mapping, normalization, prohibited character checking and bidirectional string checking. 5. Convert the nameprepped name to IDN encoding, which is the standard encoding for internationalized domain names (also known as ASCII- compatible encoding, ACE), and vice versa. The configuration file specifies the parameters for these tasks, such as: - the encoding of internationalized domain names (IDN encoding). - NAMEPREP schemes. SYNTAX
The configuration file is a simple text files, and each line in the file (other than comment lines, which begin with ``#'', and empty lines) forms an entry of the following format: keyword value.. IDN-ENCODING ENTRY IDN encoding entry specifies the encoding name (codeset name) which is used as the encoding of internationalized domain names. The syntax of this entry is: idn-encoding encoding encoding is the encoding name to be used, and any of the following names can be specified. o ``Punycode'' o ``UTF-8'' o Codeset names which iconv_open() library function accepts. Please consult iconv() documentation for the available codesets. o Any alias names for the above, defined by the alias file. (See section ``ENCODING-ALIAS-FILE'') The standard encoding was determined as Punycode. NAMEPREP ENTRY
Nameprep entry specifies the version of NAMEPREP, which is a specification of ``canonicalization'' process of internationalized domain name before it is converted to the IDN encoding. The syntax of this entry is: nameprep version version is the version name of NAMEPREP specification, and currently the following versions can be specified. o ``RFC3491'' This version refers to RFC3491 ``rfc-3491.txt''. The NAMEPREP process consists of the following 4 subprocesses. 1. mapping, which maps certain characters in a name to other characters, possibly none. 2. normalization, which replaces character variants in a name to a unique one. 3. prohibited character checking, which detects invalid characters in a name. 4. unassigned codepoint checking, which also invalid codepoints in a name. 5. bidirectional string checking, which detecs invalid string. LOCAL-MAP ENTRY This entry specifies localized mapping phase before NAMEPREP takes place. Different mapping rules can be specified for each TLD (top-level domain). For example, you can have one mapping for ``.tw'' domain, and another for ``.jp'' domain. The syntax of this entry is: local-map tld scheme [scheme..] tld specifies the TLD to which the mapping rule is to be applied, and scheme specifies the mapping scheme, and currently available schemes are: RFC3491 Specify mapping defined by RFC3491. filemap:pathname Specify mapping defined by the file pathname. See ``MAPFILE FORMAT'' for the format of this file. There are two special tlds for specifying the mapping rule for local domain names (domain names without any dots in them), and the default mapping rule. If tld is ``-'', it matches domain names which do not contain any dots. If tld is ``.'', it matches any domain names which don't match to any other mapping rules specified by ``local-map'' entries. MAPFILE FORMAT
A mapfile defines a set of character mapping rules. It can define unconditional one-character to N-character-sequence (N can be 0, 1 or more) mappings. A mapfile is a simple text file, and each line specifies a single mapping. Each line is of the form: src-codepoint; mapped-codepoint-seq; src-codepoint indicates source character of the mapping, and must be a Unicode codepoint value in hexadecimal string. mapped-codepoint-seq is a sequence of characters which is the outcome of the mapping, and must be a (possibly empty) list of Unicode codepoint values in hexa- decimal string, separated by spaces. Lines which begin with ``#'' are treated as comments and ignored. A sample mapfile is shown below. # map "A" to "a" 0041; 0061; # map "#" to nothing 0023; ; # map "@" to "at" 0040; 0061 0074; LOCAL CODESET
idn.conf or ~/.idnrc doesn't have an entry to specify the local codeset, since it is determined from the application's current locale information. So each application can use different local codeset. Although idnkit tries hard to find out the local codeset, sometimes it fails. For example, there are applications which use non-ASCII codeset but work in C locale. In this case, you can specify the application's local codeset by an environment variable ``IDN_LOCAL_CODE- SET''. Just set the codeset name (or its alias name) to the variable, and idnkit will use the codeset as the local one, regardless of the locale setting. ENCODING-ALIAS-FILE Encoding alias file specifies codeset name aliases. It is located on /etc/idnalias.conf and always loaded automatically as idn.conf and .idnrc. The aliases in this file can be used just as the real names. The alias file is a simple text file, consisting of lines of the form: alias-name name alias-name is the alias name to be defined, and name is the real name or another alias name. SAMPLE CONFIGURATION
The following shows a sample configuration file. # # a sample configuration. # # Use Punycode as the IDN encoding. idn-encoding Punycode # Use RFC3491 as NAMEPREP. nameprep RFC3491 # Perform Japanese-specific mapping for .jp domain. # assuming /usr/local/lib/idnkit/jp-map contains the mapping. local-map .jp filemap:/usr/local/lib/idnkit/jp-map FILES
/etc/idn.conf ~/.idnrc /etc/idnalias.conf /etc/idn.conf.sample - sample configuration with comments /etc/idnalias.conf.sample - sample alias file SEE ALSO
iconv(3) Mar 8, 2002 idn.conf(5)