- Article Type: General
- Product: Aleph
- Product Version: 20
What character conversion should be used to upload data into Z30 when data contains diacritic characters, e.g. "a?o"?
The input file is being generated from an XSLT stylesheet, so should already be in UTF. When no conversion is specified, the data shifts one byte to the right.
We processed the item records as follows:
1. p_manage_18: load Z30-2 fields into bib record
2. p_manage_50: build item records
3. p_manage_70: find ADM record numbers
4. use XSLT to build Z30 record (1805 characters)
5. p_file_06: update existing item (Z30) records (with no Character Conversion)
When we look at these items loaded by p_file_06, in util f/4 or SQL, we see the diacritics properly, but when we look at them in the GUI or the Web they display as a blank or as a square. For instance, "a?o" appears as "ano" and "d?c" appears as "d c".
It *should* be just the opposite: when a diacritic is properly encoded in Unicode, it will display as "garbage" in UTIL-F-4 or SQL.
As described in the attached document, we transferred these records to the ./www_f_eng/icon/ directory and looked at them with the Web. We found that, with the default Encoding - Unicode, they had the defect described above, but when we switched to "Western European (Windows)" [in Internet Explorer] or "Western (Windows-1252)" [Firefox], they displayed properly. This showed that the input file was not in UTF-8. When the process was corrected so that the file *was* in UTF-8 and the file was processed by p_file_06 with no character conversion, the diacritics displayed.
Note: After this, there was a problem with the data following the diacritic (in *all* the following fields) being shifted one character to the right. As a result, the site simply left the z30_description blank in the p_file_06 input file for the serial items with HOL records with 853 fields. The correct_z30_b program populates the z30_description in such cases. (See KB 16384-26833).
- Article last edited: 10/8/2013