2. Charmap Files
Prev Chapter 10. Field Structure and Character Sets  Next

2. Charmap Files

The character map files are used to define the word tokenization and character normalization performed before inserting text into the inverse indexes. Zebra ships with the predefined character map files tab/*.chr. Users are allowed to add and/or modify maps according to their needs.

Table 10.1. Character maps predefined in Zebra

File nameIntended typeDescription
numeric.chr:nNumeric digit tokenization and normalization map. All characters not in the set -{0-9}., will be suppressed. Note that floating point numbers are processed fine, but scientific exponential numbers are trashed.
scan.chr:w or :pWord tokenization char map for Scandinavian languages. This one resembles the generic word tokenization character map tab/string.chr, the main differences are sorting of the special characters üzĉäĝöċ and equivalence maps according to Scandinavian language rules.
string.chr:w or :pGeneral word tokenization and normalization character map, mostly useful for English texts. Use this to derive your own language tokenization and normalization derivatives.
urx.chr:uURL parsing and tokenization character map.
@:0Do-nothing character map used for literal binary indexing. There is no existing file associated to it, and there is no normalization or tokenization performed at all.

The contents of the character map files are structured as follows:

encoding encoding-name

This directive must be at the very beginning of the file, and it specifies the character encoding used in the entire file. If omitted, the encoding ISO-8859-1 is assumed.

For example, one of the test files found at test/rusmarc/tab/string.chr contains the following encoding directive: 

         encoding koi8-r

and the test file test/charmap/string.utf8.chr is encoded in UTF-8: 

         encoding utf-8

lowercase value-set

This directive introduces the basic value set of the field type. The format is an ordered list (without spaces) of the characters which may occur in "words" of the given type. The order of the entries in the list determines the sort order of the index. In addition to single characters, the following combinations are legal:

  • Backslashes may be used to introduce three-digit octal, or two-digit hex representations of single characters (preceded by x). In addition, the combinations \\, \\r, \\n, \\t, \\s (space — remember that real space-characters may not occur in the value definition), and \\ are recognized, with their usual interpretation.

  • Curly braces {} may be used to enclose ranges of single characters (possibly using the escape convention described in the preceding point), e.g., {a-z} to introduce the standard range of ASCII characters. Note that the interpretation of such a range depends on the concrete representation in your local, physical character set.

  • parentheses () may be used to enclose multi-byte characters - e.g., diacritics or special national combinations (e.g., Spanish "ll"). When found in the input stream (or a search term), these characters are viewed and sorted as a single character, with a sorting value depending on the position of the group in the value statement.

For example, scan.chr contains the following lowercase normalization and sorting order: 

         lowercase {0-9}{a-y}üzĉäĝöċ

uppercase value-set

This directive introduces the upper-case equivalences to the value set (if any). The number and order of the entries in the list should be the same as in the lowercase directive.

For example, scan.chr contains the following uppercase equivalent: 

         uppercase {0-9}{A-Y}ÜZĈÄĜÖĊ

space value-set

This directive introduces the character which separate words in the input stream. Depending on the completeness mode of the field in question, these characters either terminate an index entry, or delimit individual "words" in the input stream. The order of the elements is not significant — otherwise the representation is the same as for the uppercase and lowercase directives.

For example, scan.chr contains the following space instruction: 

         space {\001-\040}!"#$%&'\()*+,-./:;<=>?@\[\\]^_`\{|}~

map value-set target

This directive introduces a mapping between each of the members of the value-set on the left to the character on the right. The character on the right must occur in the value set (the lowercase directive) of the character set, but it may be a parenthesis-enclosed multi-octet character. This directive may be used to map diacritics to their base characters, or to map HTML-style character-representations to their natural form, etc. The map directive can also be used to ignore leading articles in searching and/or sorting, and to perform other special transformations.

For example, scan.chr contains the following map instructions among others, to make sure that HTML entity encoded Danish special characters are mapped to the equivalent Latin-1 characters: 

         map (&aelig;)      ĉ
         map (&oslash;)     ĝ
         map (&aring;)      ċ

In addition to specifying sort orders, space (blank) handling, and upper/lowercase folding, you can also use the character map files to make Zebra ignore leading articles in sorting records, or when doing complete field searching.

This is done using the map directive in the character map file. In a nutshell, what you do is map certain sequences of characters, when they occur in the beginning of a field, to a space. Assuming that the character "@" is defined as a space character in your file, you can do: 

	 map (^The\s) @
	 map (^the\s) @

The effect of these directives is to map either 'the' or 'The', followed by a space character, to a space. The hat ^ character denotes beginning-of-field only when complete-subfield indexing or sort indexing is taking place; otherwise, it is treated just as any other character.

Because the default.idx file can be used to associate different character maps with different indexing types -- and you can create additional indexing types, should the need arise -- it is possible to specify that leading articles should be ignored either in sorting, in complete-field searching, or both.

If you ignore certain prefixes in sorting, then these will be eliminated from the index, and sorting will take place as if they weren't there. However, if you set the system up to ignore certain prefixes in searching, then these are deleted both from the indexes and from query terms, when the client specifies complete-field searching. This has the effect that a search for 'the science journal' and 'science journal' would both produce the same results.

equivalent value-set

This directive introduces equivalence classes of characters and/or strings for sorting purposes only. It resembles the map directive, but does not affect search and retrieval indexing, but only sorting order under present requests.

For example, scan.chr contains the following equivalent sorting instructions, which can be uncommented: 

         # equivalent ĉä(ae)
         # equivalent ĝö(oe)
         # equivalent ċ(aa)
         # equivalent uü

Prev Up Next
Chapter 10. Field Structure and Character Sets  Home 3. ICU Chain Files