Цель настоящей работы – определить соглашения в формате RUSMARC, необходимые для передачи данных, использующих Universal Character Set (UCS-2) (ISO 10646) или UNICODE.
При этом мы имеем в виду две основные задачи:

• Кодирование символов UNICODE в записях RUSMARC;
• Способ идентификации того, что запись – в UNICODE.

Несколько слов о схемах кодирования.
Естественно, имеются в виду схемы кодирования, которые имеют отношение к поставленным задачам.

ISO 10646 Предполагает два варианта:
1-ый: 31 бит на символ, называемый UCS-4.
2-ой: 16 бит на символ (UCS-2).
Соответственно, они позволяют кодировать разное количество символов.
При этом следует отметить, что 665535 величин, которые могут быть представлены в UCS-2, достаточно, чтобы охватить большинство символов, используемых в современных языках.

Другая концепция ISO 10646 – UCS Transformation Format (UTF).
UTF – это альтернативное представление UCS-4 и UCS-2.
При использовании ISO 2709 UTF необходим, чтобы передавать данные UNICODE без искажения и без потерь. Особенностью UTF является то, что не все символы требуют одинакового количества бит.

UTF-16. Представляет UCS-символ как последовательность одного или более 16-битных наборов.

UTF-8. Производит надежную передачу данных в 8-битном окружении, таком, например, как INTERNET. Символ UCS представляется в виде одного или более октетов. При этом ASCII-символы требуют одного октета. Друге – двух или трех.

UTF-7. Обеспечивает поддержку 7-битных протоколов передачи данных, таких, как например, MIME, тоже выражает символ октетами, но требует соблюдения более строгих правил, чем в UTF-8.

Стандартный способ кодирования. Это способ кодирования при помощи стандартных, (имеются в виду ISO-стандарты, такие как, например, ISO 646 ) семибитных таблиц кодирования символов. В форматах UNIMARC и RUSMARC, в позициях 26-29 поля 100 указываются две используемые таблицы символов. Для указания символов, выходящих за рамки основных таблиц, в записи UNIMARC или RUSMARC применяются специальные переключатели таблиц, позволяющие перейти к двум дополнительным наборам символов, которые, в этом случае, указываются в позициях 30-33 поля 100.
В формате USMARC до недавнего времени молчаливо предполагалось, что существует только один набор символов, который может использоваться в MARC-записи – это ASCII-символы.
Однако экспансия формата потребовала появления в нем поля 066, где могут указываться дополнительные наборы символов. Это – одно из тех нововведений, которые превратили формат USMARC в MARC21.

1.Методы кодирования символов UNICODE в MARC-форматах.

Достигнуто соглашение по поводу того, что UTF-8 предпочтительный метод кодирования для записей MARC21 в настоящее время. UTF-8 наиболее широко поддерживается существующими базами данных и коммуникационным программным обеспечением. Можно с уверенностью сказать, что отличных решений не будет принято ни для формата UNIMARC, ни для формата RUSMARC.

2. Единая форма кодирования

Есть единодушное согласие относительно того, что только один способ кодирования должен использоваться в одной MARC-записи. Т. е. одна запись должна кодироваться либо полностью в ССК, либо полностью в UNICODE. Если это UNICODE, то это должен быть UTF-8, или, в отдельных случаях, UTF-16.

Считается необходимым принять такие же рекомендации и в отношении файла передаваемых записей. Т.е. все записи в передаваемом файле должны использовать один и тот же способ кодирования.

3. Escape-последовательности и переключатели.

Единая форма кодирования, в частности, означает, что esc-последовательности стандарта ISO 2092 не допускаются, если используется UNICODE. То же нужно сказать и о переключателях, определенных в рамках формата. Если запись конвертируется из UNICODE в ССК, esc-последовательности и переключатели должны вводиться там, где это необходимо.

4. Комбинированные символы. (символы с диакритикой)

В MARC форматах принимается, что в записи, составленной в кодировке UNICODE модификация символа следует за базовым символом, а не наоборот, как было принято в форматах. Иначе говоря, это положение принимается так, как оно определено в ISO 10646.

5. Расчет позиций и длин символов.

Запись MARC включает в себя несколько элементов фиксированной длины и позиционно определяемых. Z39.2-1994, ISO 2709 и любой из MARC-форматов используют позицию символа как единицу измерения для такого рода данных, полагая, что позиция символа есть октет. То есть имеется подразумеваемый эквивалент между позицией символа и самим символом (за исключением многобайтных символов в CJK-наборе). В MARC-форматах каждый октет рассматривается как позиция символа при подсчете. Такой же принцип рекомендуется для UTF-8. Каждый ASCII-символ, закодированный в UTF-8, всегда будет представлять собой один октет, по определению.

5.1. Теги полей, коды подполей, (поз. 11 маркера), длины элементов справочника (поз. Маркера 20-23).

Теги полей и коды подполей в MARC-форматах обозначаются графическими символами ASCII и, таким образом, - имеют один октет на символ в UTF-8. То же касается позиций маркера 20-23.

5.2. Длина индикатора (поз. 12 маркера), статус записи (поз. 5 маркера) тип записи (поз. маркера 6).

То же.

5.3. Позиции маркера 7-9, 17-19.

Ряд кодов в позициях маркера (7-9; 17-19) зависят от конкретного назначения формата (формат для библиографических данных, для авторитетных данных, холдинг-формат и т.д. ) и не определяются единым образом для всех MARC-форматов в целом.
С учетом возможности использования UTF-8, коды в этих позициях должны быть определены как ASCII-символы с тем, чтобы Маркер в UTF-8 всегда содержал 24 октета.

5.4. Базовый адрес данных (маркер 12-16), длина записи (маркер 0-4), длина справочника и стартовая позиция символов.

Все вышеназванные элементы представляются ASCII-символами и занимают поэтому по одному октету на символ в UTF-8.
Таким образом, получаем, что базовый адрес данных UTF-8 будет иметь одно значение независимо от того, ведется ли подсчет в символах или в октетах. Однако величина длины записи (маркер 0-4), длина поля (справочник) и стартовая позиция символов – зависят от того, как ведется подсчет, в октетах или в символах. Все эти элементы используются программами обработки, передачи или разбора данных. Обработка записей в UTF-8 будет проще, если эти две длины отражают количество октетов (а не символов).

Измерение длин в октетах означает, что емкости поля и записи в UTF-8 и ССК будут различаться. Например, поле в ССК может содержать 9999 символов, а поле в UTF-8 может содержать только 9999 октетов, что может означать меньшее количество символов, если они не ASCII.
Для UTF-8 в стандарте z39.2-1994 п. 4.3.1.2. определена техника, которая делает возможным использование полей, более длинных, чем 9999 и некоторые системы, действительно поддерживают это. Однако нет способа приспособить запись с несколькими такими полями, общая длина которой превышает 99 999 октетов.
Таким образом, ограничения на емкость записи могут создать проблему при конвертации из ССК в UTF-8, однако, вряд ли нужно считать это обстоятельство критичным для принятия или неприятия октета в качестве единицы измерения.

5.5 Символ-заполнитель.

Символ-заполнитель и пробел, используемые в полях фиксированной длины, являются ASCII-символами и, поэтому, не создают проблем при использовании UTF-8.

5.6. Поля с позиционно определяемыми элементами.

Для форматов UNIMARC и RUSMARC – это ряд полей блока 1--.
Содержание таких полей должно быть ограничено ASCII-символами, с тем, чтобы и в UTF-8 получалось по одному октету на символ.

5.7. Начало и конец не сортируемых символов (≠NSB≠, ≠NSE≠)

Коды ≠NSB≠ и ≠NSE≠ не принадлежат базовой латинской таблице и имеют значения, соответственно, 88h и 89h в ISO/Latin-1 (8859/1), или 0x88h и 0x89h в ISO 10646.
В обоих стандартах эти значения отведены под управляющие коды. В UTF-8 каждое из этих значений выражается двумя байтами С288h и C289h. Однако, эти коды используются только в полях переменной длины и, следовательно, не внесут ошибок в запись UTF-8.

6. Идентификация записи в UNICODE

Напомним, что форматы UNIMARC и RUSMARC содержат указание на используемую кодировку в поз. 26-33 поля 100. UNICODE указывается значением 50 в поз. 26-27 и пробелами в 28-33 позициях. Поскольку в UTF-8 коды, используемые в этих позициях, - по-прежнему однобайтные и сохраняют свое значение, задача идентификации записи однозначно решаема и не вызывает дополнительных сложностей.

В формате MARC21 признана необходимость знать кодировку записи, прежде чем пытаться ее прочесть. Поэтому идентификация потребовалась вне самой записи. С этой целью используется поз. 9 маркера записи “а” - UNICODE и пробел – USM94.