Японские шрифты в бизнес-приложениях: JIS2004, IVS и пользовательские символы

«Имя то же, а форма символа на экране и в печатной форме разная.» «После замены ПК символ, который отображался, стал □.» Бизнес-системы, которые обрабатывают японский текст, привлекают такие обращения.

Первое, что проверить: изменились ли данные символа или изменился только внешний вид тех же данных. Если чинить это как «кракозябры», не разделив два случая, вы входите в расследование не с той двери.

Статья начинается с двух обращений: 葛 в списке клиентов, который выглядит по-разному на экране и в печатной форме, и имя в документе для учреждения, которое после замены ПК больше не отображалось.

Ни одно из этих двух обращений не является кракозябрами из-за несовпадения кодировки. В первом данные не изменились ни на бит, сменился только внешний вид; во втором потерян пользовательский символ (EUDC), который существовал только на том ПК.

flowchart TB
    accTitle: Чем на деле являются два частых обращения
    accDescr: Обращение, что 葛 выглядит по-разному на экране и в форме, — случай, когда данные те же, а сменился только внешний вид; обращение, что после замены ПК символ стал □, — случай, когда потерян пользовательский символ, существовавший только на том ПК; оба отличаются от кракозябр из-за несовпадения кодировки
    c1["Обращение 1: на экране и в форме разная форма"] --> r1["Данные те же; сменился только вид"]
    c2["Обращение 2: после замены стал □"] --> r2["Потерян пользовательский символ только этого ПК"]
    r1 --> diff["Это не кракозябры из-за кодировки"]
    r2 --> diff

Рис. 1: Два обращения, которые часто называют кракозябрами, на деле не про несовпадение кодировки.

Разделите слой кодировки символов (данные) и слой шрифта (внешний вид) — и большинство проблем с японскими символами становится понятным. Статья рассчитана на разработчиков бизнес-систем и сотрудников ИТ и идёт по порядку от изоляции симптома через устройство JIS2004, IVS и пользовательских символов к принимаемому набору и проекту печатных форм и PDF.

Искажение при преобразовании Shift_JIS ↔ UTF-8 разобрано в уже опубликованных статьях, поэтому здесь речь о другом: коды туда и обратно проходят верно, а внешний вид или возможность отображения — нет.

1. Сначала выводы

«Какую последовательность байтов хранить» — вопрос проекта данных; «как это выглядит» — вопрос проекта шрифта. Когда решаете, как отвечать, разделите следующие три вещи.

Сначала подтвердите, те ли же данные

Кракозябры — проблема слоя данных: байтовая последовательность истолкована неверно. Напротив, одна и та же кодовая позиция Unicode может иметь другой глиф в другом шрифте. JIS2004 сменил эталонные глифы 168 символов, включая 葛, 辻 и 飴, и начиная с Vista в MS Gothic и MS Mincho Windows по умолчанию стоят глифы JIS2004.¹²

Не путайте задание глифа с переносом пользовательских символов

IVS — стандартное средство задать глиф как данные. Однако нужны поддерживающий шрифт и поддерживающее приложение, и в среде без них правильное поведение — игнорировать селектор и показать глиф базового символа по умолчанию. Поскольку то, что выглядит как один символ, может быть до четырёх кодовых единиц UTF-16, это влияет не только на отображение, но и на подсчёт символов и вырезку.³⁴

Пользовательские символы (EUDC) — отдельная тема: номер области частного использования не имеет смысла, общего для всего мира. Глиф в eudc.tte не уходит к другой стороне вместе с данными, поэтому миграция требует обследования и таблицы соответствия заменителям.⁵⁶

Запишите принимаемые символы и среду вывода в спецификацию

Система, которая обрабатывает личные имена, решает принимаемый набор и явно его заявляет. Там, где система обменивается данными с государством, следите и за стандартными символами административных процедур, которые строятся на унифицированных символах косэки и инфраструктуре символьной информации.⁷⁸⁹ Для печатных форм и PDF база — тот же шрифт, что на экране, проверка лицензии и внедрение шрифта. Для долгосрочного хранения рассмотрите PDF/A.¹⁰¹¹

Кроме того, не применяйте нормализацию NFKC к оригиналу личного имени без нужды. Замена полноширинных и полуширинных форм и символов совместимости стирает различия, которые нужно хранить.¹²

Выберите, куда читать, по симптому или цели

Чтобы понять картину целиком, читайте с главы 2 по порядку; чтобы разобрать симптом перед вами, начните с соответствующего раздела таблицы. Когда внедряете меру, в конце проверьте её влияние на другие слои в главе 9.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 14, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Думайте о данных и внешнем виде отдельно — кодовые позиции и глифы

Номер и нарисованная форма — разные вещи

В Unicode символ представлен числом, которое называют кодовой позицией. 葛 — это U+845B, и это число одно и то же на каждом ПК.

Как это число рисуется на экране или на бумаге, напротив, решает глиф, который держит шрифт. Нормально, что один и тот же U+845B отличается деталями формы между шрифтом A и шрифтом B.

Разделите слой расследования по симптому

С этими двумя слоями как предпосылкой симптомы, которые встречаете на местах, можно разделить так.

Как подсказку для разделения полезно помнить разницу между «�» и «□».

«�» — след неудачного преобразования. Как только заменили на U+FFFD (REPLACEMENT CHARACTER), исходный символ уже потерян. Разбирайте слой данных.

«□» в большинстве случаев — отображение «глиф не найден». Если данные ещё есть и шрифту просто не хватает глифа, смена шрифта может сделать его отображаемым. Разбирайте слой внешнего вида.

flowchart TB
    accTitle: Разделение симптома по � против □
    accDescr: Когда символ отображается неверно, � — след сбоя преобразования на слое данных, при котором исходный символ уже потерян, а □ значит только, что данные ещё есть, но у шрифта нет глифа, и смена шрифта может сделать его отображаемым
    symptom["Символ отображается неверно"] --> which{"Что видно?"}
    which -->|видно �| datalayer["Сбой слоя данных"]
    datalayer -.-> lost["След неудачного преобразования (исходный символ потерян)"]
    which -->|видно □| viewlayer["Сбой слоя внешнего вида"]
    viewlayer -.-> noglyph["Шрифту просто не хватает глифа"]
    noglyph --> fixable["Смена шрифта может сделать его отображаемым"]

Рис. 2: � сигналит о сбое слоя данных, □ — о сбое слоя внешнего вида, и точка входа расследования меняется соответственно.

Основы самих кодировок (CP932 и UTF-8, BOM, переводы строк) разобраны в «Введении в кодировки текста Windows — кракозябры при обмене с Linux» и «Кодировках текста и переводах строк в Windows — основы искажения текста и CRLF/LF». Дальше предмет — слой внешнего вида и проблемы на его границе.

3. От JIS90 к JIS2004 — глиф сменился, код остался тем же

Настоящая причина стоящего в начале «葛 выглядит по-разному на экране и в форме» в большинстве случаев находится здесь.

Что сменилось: глифы шрифта по умолчанию

Вслед за таблицей форм иероглифов вне списка дзёё (Hyogai Kanji Jitaihyo), которую Национальный совет по языку представил в 2000 году, пересмотр 2004 года JIS X 0213:2004 (обычно JIS2004) сменил эталонные глифы 168 иероглифов на стандартные печатные начертания, близкие к так называемым формам словаря Канси. 葛, 辻, 飴, 芦, 溢 и 餅 — типичные примеры.¹

Windows последовала этому и сделала глифы JIS2004 умолчанием в MS Gothic и MS Mincho (и в только что введённом Meiryo) начиная с Windows Vista. У текущего MS Gothic тоже глифы по умолчанию на базе JIS2004, а глифы эпохи JIS90 доступны через функцию OpenType jp90.²¹

flowchart TB
    accTitle: Как организованы глифы текущего MS Gothic
    accDescr: MS Gothic начиная с Vista имеет глифы JIS2004 по умолчанию, а глифы эпохи JIS90 доступны через функцию OpenType jp90
    msg["MS Gothic (начиная с Vista)"] --> def["Глифы по умолчанию: на базе JIS2004"]
    msg --> feat["Через функцию jp90"]
    feat --> old["Глифы эпохи JIS90"]

Рис. 3: Текущий MS Gothic по умолчанию использует глифы JIS2004 и может переключиться на глифы JIS90 функцией jp90.

Что не сменилось: кодовая позиция символа

Здесь важно, что сменился только шрифт; данные не изменились вовсе.

• Кодовая позиция 葛 — U+845B и на XP, и на Windows 11
• XP (глифы JIS90) показывает форму, в которой внутри 勹 упрощено до ヒ; начиная с Vista (глифы JIS2004) показывает форму, которая пишет внутри ещё и 人
• Поэтому отсканированный образ формы, напечатанной старой системой, и экран нового ПК расходятся в форме символа. Сравнение данных совпадает полностью

Один или два пункта у радикала синнё в 辻 и форма пищевого радикала в 飴 — того же рода. Не зная этой истории, расследование склонно идти не туда: «миграция испортила данные».

Порядок расследования: сравнить кодовые позиции до и после миграции → если совпадают, подозревать разницу глифов между шрифтами. Не заключайте, что данные испорчены, только потому что выглядит иначе.

flowchart TB
    accTitle: Та же кодовая позиция, другой глиф в зависимости от шрифта
    accDescr: Кодовая позиция U+845B символа 葛 остаётся той же на XP и на Windows 11, меняется только отображаемая форма между шрифтом с глифами JIS90 и шрифтом с глифами JIS2004, и сравнение данных совпадает полностью
    cp["Кодовая позиция U+845B для 葛"] --> f90["Шрифт с глифами JIS90 (XP)"]
    cp --> f04["Шрифт с глифами JIS2004 (начиная с Vista)"]
    f90 --> g90["Форма, в которой внутри 勹 упрощено до ヒ"]
    f04 --> g04["Стандартная печатная форма, которая пишет внутри 人"]
    g90 -.-> same["Сравнение данных совпадает полностью"]
    g04 -.-> same

Рис. 4: Сменился только шрифт; кодовая позиция U+845B остаётся той же в любой среде.

Заметьте: поскольку сам символ не сменился, оба глифа — «один и тот же символ». В личных именах, однако, человек или учреждение иногда настаивают на конкретной форме, и ответить на требование различить это «как данные» — работа следующей темы, IVS.

4. Селекторы вариантного начертания (IVS) — задать глиф как данные

Эта глава смотрит отдельно на механизм, который задаёт глиф, условия, при которых его можно отобразить, и влияние на реализацию.

IVS (Ideographic Variation Sequence) — механизм, который ставит сразу после иероглифа невидимую кодовую позицию, называемую «селектором вариантного начертания», чтобы задать вариант глифа как данные. Используемые селекторы — U+E0100 через U+E01EF (VS17 через VS256).³

Соответствие глифов решает регистрация в IVD

Какая последовательность «базовый символ + селектор» указывает на какой глиф, решает реестр IVD (Ideographic Variation Database), которым управляет Консорциум Unicode.

Основные коллекции такие.¹³

Например, документация Microsoft даёт U+845B в одиночку (葛) как форму, используемую в названии станции Ниси-Касай, и U+845B с последующим U+E0100 (VS17) как форму, используемую в названии города Кацураги в префектуре Нара. Тот же 葛, но данные могут сказать, какой глиф имеется в виду.³

flowchart TB
    accTitle: Пример различения одного и того же 葛 как данных через IVS
    accDescr: 葛 как U+845B в одиночку используется в названии станции Ниси-Касай, последовательность U+845B плюс VS17 — в названии города Кацураги, и какую последовательность на какой глиф указывает, решает реестр IVD
    seq1["U+845B в одиночку"] --> gl1["Глиф, используемый в названии станции Ниси-Касай"]
    seq2["U+845B + VS17"] --> gl2["Глиф, используемый в названии города Кацураги"]
    ivd["IVD (реестр)"] -.-> gl1
    ivd -.-> gl2

Рис. 5: Даже для одного и того же 葛 наличие или отсутствие селектора позволяет данным сказать, какой глиф имеется в виду.

4.1. Поведение в среде без поддержки

На стороне шрифта соответствие между IVS и глифом реализовано в таблице OpenType cmap (format 14).⁴ Когда есть и поддерживающий шрифт (например IPAmj Mincho), и поддерживающее приложение, появляется указанный глиф.

Когда их нет, указанный глиф не гарантирован. Разделите следующие два случая.

• Правильное поведение по спецификации: селектор игнорируется и показывается глиф базового символа по умолчанию (сам селектор невидим)
• Старые приложения и часть стеков отрисовки: селектор трактуется как независимый неизвестный символ, и показывается лишний □

Иначе говоря, IVS спроектирован так, что «даже при деградации базовый символ остаётся читаемым», но появится ли «всегда указанный глиф» зависит от принимающей среды.

Государственные системы учёта жителей и семейного реестра используют сочетание шрифта инфраструктуры символьной информации плюс IVS, но если обычная бизнес-система принимает это небрежно, глиф где-то теряется — на отображении, печати или нижестоящей системе.

flowchart TB
    accTitle: Как отображаются данные с IVS
    accDescr: Когда есть и поддерживающий шрифт, и поддерживающее приложение, отображается указанный глиф; когда их нет, селектор игнорируется и показывается глиф базового символа по умолчанию; в старых приложениях и части стеков отрисовки селектор трактуется как неизвестный символ и показывается лишний □
    ivs["Базовый символ + селектор вариантного начертания"] --> env{"Есть и поддерживающий шрифт, и приложение?"}
    env -->|Да| ok["Отображается указанный глиф"]
    env -->|Нет| ignore["Селектор игнорируется; показывается глиф по умолчанию"]
    env -->|Старые приложения или часть стеков отрисовки| tofu["Показывается лишний □"]
    ignore -.-> spec["Это правильное поведение по спецификации"]

Рис. 6: IVS остаётся читаемым как базовый символ даже при деградации, но появится ли указанный глиф, зависит от принимающей среды.

4.2. Оговорки реализации — «один символ» может быть до четырёх кодовых единиц

Селекторы IVS начиная с U+E0100 — кодовые позиции дополнительной плоскости, поэтому в UTF-16 они всегда суррогатная пара (две кодовые единицы). Если сам базовый символ — иероглиф дополнительной плоскости (например 𠮟 (U+20B9F), добавленный в JIS2004), база одна уже две кодовые единицы, и последовательность, которую пользователь воспринимает как «один символ», — до четырёх кодовых единиц в UTF-16 и до восьми байтов в UTF-8.

Подсчёт и вырезка: не разрывайте кажущийся символ

В C# у "葛󠄀" (葛 + VS17) string.Length == 3. Substring и нарезка фиксированной длины рискуют отделить базовый символ от селектора.

Проверяйте число символов и вырезайте подстроки в единицах графемы, API вроде StringInfo, а не в кодовых единицах.

Хранение: проверьте единицу длины столбца

nvarchar(n) в SQL Server измеряется в кодовых единицах UTF-16. Если принимаете IVS, планируйте длины столбцов БД в два-четыре раза больше кажущегося числа символов.

Поиск и сравнение: решите, различаются ли селекторы

Наличие или отсутствие селектора делает другую строку. Должен ли поиск «葛» попадать в «葛 + VS17» — это нужно решить как требование и реализовать.

flowchart TB
    accTitle: Один символ с IVS и кодовые единицы UTF-16
    accDescr: Последовательность базового символа и селектора вариантного начертания, которую пользователь воспринимает как один символ, имеет селектор, который всегда суррогатная пара, плюс ещё две кодовые единицы, если базовый символ — иероглиф дополнительной плоскости, итого до четырёх кодовых единиц в UTF-16
    one["Один символ, как воспринимает пользователь"] --> base["Базовый символ"]
    one --> vs["Селектор вариантного начертания"]
    base -.-> bnote["Две кодовые единицы, если это иероглиф дополнительной плоскости"]
    vs -.-> vnote["Всегда суррогатная пара (две кодовые единицы)"]
    base --> total["До четырёх кодовых единиц в UTF-16"]
    vs --> total
    total -.-> risk["Нарезка фиксированной длины рискует разорвать их"]

Рис. 7: Один символ с IVS может быть до четырёх кодовых единиц UTF-16, поэтому нарезка по кодовым единицам опасна.

5. Пользовательские символы (EUDC) — символы, которые отображаются только на том ПК

Пользовательские символы — механизм, которым пользователь назначает собственный глиф кодовой позиции в области частного использования Unicode (PUA: U+E000 через U+F8FF и другие диапазоны). Кодовая позиция области частного использования не имеет смысла, общего для всего мира; один и тот же U+E000 может быть назначен другому символу на каждом ПК и в каждой организации.⁵

Глиф живёт в шрифте пользовательских символов; в данных остаётся только номер

В Windows глиф создают в редакторе пользовательских символов (eudcedit.exe), и он сохраняется в файле шрифта eudc.tte.

Этот файл устанавливается как скрытый шрифт и связывается с каждым шрифтом через ключ реестра HKEY_CURRENT_USER\EUDC.⁶ В эпоху Shift_JIS (CP932) диапазон пользовательских символов был 0xF040 через 0xF9FC, и преобразование в Unicode отображает его в область частного использования.

Номер в данных не значит, что у другой стороны тот же глиф. Этот механизм порождает следующие проблемы.

• eudc.tte принадлежит тому ПК (тому пользователю) и не уходит к другой стороне вместе с данными
• Как только данные доходят до почты, PDF, веба или другой системы, символ превращается в □ или выглядит как чужой пользовательский символ на той стороне
• Если забыть перенести eudc.tte при миграции ОС или замене ПК, случается «символ, который отображался на старом ПК, больше не отображается»

Это настоящая причина второго обращения из начала.

flowchart TB
    accTitle: Почему пользовательские символы отображаются только на том ПК
    accDescr: Глиф, созданный в редакторе пользовательских символов, сохраняется в eudc.tte и связывается со шрифтами через реестр этого ПК, поэтому когда к почте, PDF или другой системе уходит только код области частного использования, он превращается в □ или выглядит как другой символ
    edit["Создать глиф в редакторе пользовательских символов"] --> tte["Сохранён в eudc.tte"]
    tte --> reg["Связан со шрифтами через реестр"]
    reg --> local["Отображается на том ПК"]
    tte -.-> stay["eudc.tte не уходит вместе с данными"]
    send["К другой стороне доходит только код области частного использования"] --> dest["Почта, PDF, другие системы"]
    dest --> broken["Превращается в □ или выглядит как другой символ"]

Рис. 8: Глиф живёт в eudc.tte, а в данных остаётся только номер области частного использования, поэтому пользовательские символы выглядят сломанными, как только покидают ПК.

5.1. Реалистичный ответ для системы, которая уже приняла пользовательские символы

Проблема — когда данные, унаследованные от устаревшей системы, уже содержат пользовательские символы. То, что мы рекомендуем на миграциях, — четырёхэтапная процедура: обследование → идентификация → замена → блокировка.

1. Обследование: собрать используемые номера и исходные глифы

Просканируйте базы и файлы регулярным выражением по области частного использования (U+E000 через U+F8FF) и инвентаризируйте используемые коды пользовательских символов и их количество. Соберите eudc.tte с ПК на каждой площадке и проверьте глифы.

2. Идентификация: построить таблицу соответствия заменителям

Для каждого пользовательского символа проверьте, можно ли его представить обычным символом Unicode, можно ли представить через IVS и есть ли соответствующий символ в инфраструктуре символьной информации (MJ), и постройте таблицу соответствия заменителям. На практике большинство случаев оказывается всего лишь старой формой, которую создали как пользовательский символ JIS.

3. Замена: заменить данные по таблице

Замените данные по таблице соответствия. Только когда соответствующего символа нет вовсе, оставьте символ как изображение или приложите примечание к данной записи.

4. Блокировка: не добавлять новые пользовательские символы

В новой системе отклоняйте ввод области частного использования при проверке и не создавайте новые пользовательские символы.

flowchart TB
    accTitle: Процедура миграции данных, которые содержат пользовательские символы
    accDescr: Инвентаризировать используемые пользовательские символы сканированием области частного использования и сбором eudc.tte, построить таблицу соответствия заменителям и заменить, а в новой системе отклонять ввод области частного использования при проверке и не создавать новые пользовательские символы
    st1["Обследование: просканировать область частного использования"] --> st2["Идентификация: построить таблицу соответствия заменителям"]
    st2 --> st3["Замена: заменить по таблице"]
    st3 --> st4["Блокировка: не создавать новые пользовательские символы"]
    st1 -.-> tte["Собрать eudc.tte с каждой площадки"]
    st2 -.-> nomap["Изображение или примечание только там, где соответствия нет"]

Рис. 9: Мигрируйте пользовательские символы в четыре этапа — обследование, идентификация, замена и блокировка — и не создавайте новые.

Направление то же на государственной стороне: заявленная политика — однозначно идентифицировать пользовательские символы, которые муниципалитеты создали самостоятельно (говорят, около двух миллионов символов по стране) по стандартным символам административных процедур, описанным ниже, и прекратить их использовать.⁹ «Не добавлять пользовательские символы; идентифицировать их по стандартизованному набору» становится устоявшимся шаблоном миграции и в государственном, и в частном секторе.

6. Государственная инфраструктура символов — от унифицированных символов косэки к стандартным символам административных процедур

Когда проектируете систему, которая обрабатывает личные имена, знание государственной инфраструктуры символов даёт материал для решения «насколько далеко принимать».

Сначала разделите имена и роли инфраструктур символов

Разделите обмен внутри государства и обмен с общим внешним миром

Для муниципальных основных систем (стандарт-совместимых систем) стандартная спецификация — двухуровневая схема: использовать стандартные символы административных процедур для обмена информацией об именах и подобном и обмениваться в пределах JIS X 0213:2012 с внешними системами без единых правил обмена, например смартфонами.⁹

Эта схема «держать широкий набор внутри и обмениваться снаружи в пределах, которые может отобразить обычная среда» сама по себе полезный ориентир и для частных систем.

flowchart TB
    accTitle: Двухуровневый обмен стандарт-совместимой системы
    accDescr: Муниципальная стандарт-совместимая система использует стандартные символы административных процедур для обмена информацией об именах и подобном и обменивается в пределах JIS X 0213:2012 с внешними системами вроде смартфонов, у которых нет единых правил обмена
    sys["Муниципальная стандарт-совместимая система"] --> renkei["Обмен информацией об именах и подобном"]
    sys --> gaibu["Обмен с внешними системами"]
    renkei --> mjp["Стандартные символы административных процедур"]
    gaibu --> jis["Диапазон JIS X 0213:2012"]
    gaibu -.-> sumaho["Контрагенты без правил, например смартфоны"]
    mjp -.-> naibu["Широкий набор держат внутри"]

Рис. 10: Двухуровневая схема: государственный обмен использует стандартные символы административных процедур, а внешний обмен без правил — JIS X 0213:2012.

Решите диапазон, который принимает ваша система

Как практическое руководство для обычной бизнес-системы рекомендуем следующее.

• Решите принимаемый набор и заявите его и в спецификации, и в проверке ввода. Например, «диапазон JIS X 0213:2012», «без области частного использования и комбинирующих символов» или «IVS не принимаем (или принимаем, с гарантией отображения только в среде IPAmj Mincho)»
• Не принимайте без ограничений. Проект «это Unicode, значит всё можно» сломается где-то на отображении, печати или интеграции
• Заранее решите, как обрабатываются символы вне диапазона. Правило подстановки альтернативной записи (новая форма или катакана) и формулировка, которой это объясняют человеку, — часть спецификации системы
• Там, где у нижестоящей стороны вроде госоргана или финансового учреждения есть правила набора, считайте их авторитетными и следуйте им

flowchart TB
    accTitle: Проектирование и эксплуатация принимаемого набора
    accDescr: Решите принимаемый набор и заявите его и в спецификации, и в проверке ввода, принимайте символы в диапазоне, а для символов вне диапазона заранее решите операцию, включая правило подстановки альтернативной записи и формулировку, которой это объясняют человеку
    decide["Решить принимаемый набор"] --> spec["Заявить в спецификации"]
    decide --> valid["Заявить в проверке ввода"]
    valid --> range{"В диапазоне?"}
    range -->|Да| ok["Принять"]
    range -->|Нет| alt["Подставить альтернативную запись"]
    alt -.-> word["Формулировка, которую объясняют человеку, тоже часть спецификации"]

Рис. 11: Заявите принимаемый набор и в спецификации, и в проверке ввода и решите также обработку символов вне диапазона.

7. Выбор и внедрение шрифтов — выровнять экран и печатную форму

Здесь порядок мысли: подтвердить, что шрифт есть в используемых средах → использовать тот же шрифт на экране и в форме → подтвердить лицензию и внедрить в PDF.

7.1. Характер стандартных шрифтов

Проверяйте используемые среды, а не только имя шрифта

Что важно в выборе — не предпочтение гарнитуры, а есть ли шрифт в каждой среде, задействованной в отображении, печати и генерации PDF.

Японские дополнительные шрифты на Windows 10/11 (BIZ UD и другие) могут быть не установлены в зависимости от конфигурации, а в конфигурации, которая генерирует PDF на стороне сервера, наличие шрифта на сервере влияет напрямую.

flowchart TB
    accTitle: Среды, которые проверять при выборе шрифта
    accDescr: При выборе шрифта важно не предпочтение гарнитуры, а есть ли шрифт в каждой среде, задействованной в отображении, печати и генерации PDF, и конфигурация дополнительных шрифтов и наличие шрифта на сервере влияют напрямую
    cand["Шрифт-кандидат"] --> exist["Есть в каждой среде?"]
    exist --> scr["Среда отображения"]
    exist --> prn["Среда печати"]
    exist --> srv["Сервер генерации PDF"]
    scr -.-> hojo["Дополнительные шрифты могут отсутствовать в зависимости от конфигурации"]
    srv -.-> eikyo["Наличие шрифта на сервере влияет напрямую"]

Рис. 12: Выбирайте шрифт не по предпочтению гарнитуры, а по тому, есть ли он в каждой среде отображения, печати и генерации PDF.

7.2. Основы проектирования форм — выровнять, затем внедрить

Используйте тот же шрифт на экране и в форме

Укажите тот же шрифт на экране и в форме. Если шрифты разные, те же данные могут выглядеть как другой глиф, и вы получите жалобу из начала. Конфигурацию вроде «Meiryo на экране, MS Mincho в форме» хотя бы проверьте на разницу глифов в 168 символах JIS2004.

Внедряйте в PDF после подтверждения лицензии

Внедряйте шрифт в PDF. Если нет, сторона просмотра рисует тем шрифтом, который есть под рукой, и меняются не только глифы, но и макет.

Можно ли внедрять, решает лицензия. Шрифт OpenType объявляет разрешения на внедрение в поле fsType (Installable, Restricted, Preview & Print, Editable, без subsetting и т. д.), и нельзя внедрять шрифт, чьё внедрение не разрешено.¹⁰ Для коммерческих шрифтов проверка договора обязательна.

Делайте subset embedding умолчанием. Если внедряете только глифы использованных символов, не нужно нести весь японский шрифт (несколько МБ до десятков МБ).

Рассмотрите PDF/A для долгосрочного хранения

Если нужно долгосрочное хранение, используйте PDF/A. PDF/A (ISO 19005) — стандарт, который делает ресурсы, нужные для отображения, самодостаточными внутри файла, и внедрение шрифта обязательно.¹¹ Это также самый надёжный способ предотвратить «открыли через десять лет — глифы сменились».

flowchart TB
    accTitle: Поток решения о внедрении шрифта
    accDescr: Перед внедрением шрифта в PDF проверьте лицензию внедрения в fsType, делайте subset embedding умолчанием, если разрешено, и рассмотрите PDF/A, где внедрение обязательно, если нужно долгосрочное хранение
    emb["Внедрить шрифт в PDF"] --> lic{"Внедрение разрешено fsType?"}
    lic -->|Разрешено| sub["Subset embedding — умолчание"]
    lic -->|Не разрешено| ng["Внедрять нельзя"]
    sub -.-> gly["Только глифы использованных символов"]
    sub -->|Требование долгосрочного хранения| pdfa["Рассмотреть PDF/A"]
    pdfa -.-> must["Внедрение шрифта обязательно"]

Рис. 13: Внедрение предполагает проверку лицензии fsType; subset embedding и PDF/A — база.

Как выбирать подход к реализации печати и вывода PDF, подробно разобрано в «Печати и PDF в Windows-приложениях».

8. Связывание шрифтов и fallback — явление «подмешивается другой шрифт»

Символ, для которого у указанного шрифта нет глифа, не оставляют пустым; поведение современных стеков отрисовки по умолчанию — нарисовать его другим шрифтом вместо этого.

В GDI это делает «связывание шрифтов», определённое в реестре (FontLink\SystemLink); в DirectWrite, WPF и браузерах — «font fallback».¹⁵

flowchart TB
    accTitle: Поток связывания шрифтов и fallback
    accDescr: Если у указанного шрифта есть глиф, он отображается как есть; если нет, рисуется связанным или запасным шрифтом; если глифа нет нигде, превращается в □, но данные обычно ещё целы
    disp["Отобразить символ"] --> has{"Есть глиф у указанного шрифта?"}
    has -->|Да| draw["Отображается указанным шрифтом"]
    has -->|Нет| fb{"Есть у связанного или запасного шрифта?"}
    fb -->|Да| alt["Рисуется другим шрифтом вместо этого"]
    alt -.-> mixed["Причина смешанного ощущения гарнитуры"]
    fb -->|Нет| tofu["Отображается □ (тофу)"]
    tofu -.-> alive["Данные обычно ещё целы"]

Рис. 14: □ — след неудавшегося fallback; удалось ли запасное рисование — развилка между «смешано» и «тофу».

Читайте результат запасного рисования по симптому

Зная этот механизм, можно объяснить следующие знакомые случаи.

• Ощущение гарнитуры различается между латиницей и японским: сначала указали латинский шрифт, поэтому только японская часть рисуется связанным или запасным японским шрифтом
• Только иероглифы в японском предложении принимают китайские глифы: fallback разрешился в китайский шрифт. Это легко случается на веб-страницах и в приложениях, которые не передают языковую информацию (атрибут lang или локаль) правильно
• Появляется тофу (□): ни у указанного, ни у запасного шрифта нет глифа. Иначе говоря, □ — «след неудавшегося fallback», и данные обычно ещё целы

Fallback не заменяет проектирование

Fallback — страховочная сетка; это не замена правильному выбору шрифта с самого начала.¹⁵

В бизнес-приложении здравая позиция — «основные пути отображения и печати полны одними спроектированными шрифтами, а fallback — страховка против неожиданных символов». Как думать о выборе шрифта в многоязычном UI, см. также «Локализации WinForms и WPF».

9. Чек-лист реализации для бизнес-приложений

Наконец, таблица ниже собирает пункты проверки на каждом слое, от ввода до интеграции. Не останавливайтесь на «отображается на экране»; проверяйте и хранение, печать и интеграцию.

Отделите хранение оригинала от обработки для поиска

Нормализация в особенности — ловушка, которая и есть тема этой статьи: процесс, применённый «из лучших побуждений», который сглаживает различия между вариантными символами и между полноширинными и полуширинными. Храните оригинал как есть; обрабатывайте копию — принцип.

Проблемы кодировки в интеграции CSV подробно разобраны в «CSV — не „просто текст“».

flowchart TB
    accTitle: Храните оригинал как есть и обрабатывайте копию
    accDescr: Храните введённую строку как оригинал ровно как ввели, применяйте нормализацию к копии, ограниченной применениями вроде генерации ключей поиска, и учтите, что применение NFKC к оригиналу стирает различия между вариантными символами и между полноширинными и полуширинными
    input["Введённая строка"] --> orig["Оригинал: хранится как введён"]
    input --> copy["Копия: нормализована для ограниченного применения"]
    copy -.-> use["Генерация ключей поиска и подобное"]
    orig -.-> ng["NFKC на оригинале сглаживает различия"]

Рис. 15: Ограничьте нормализацию конкретным применением и применяйте её к копии; храните оригинал как введён.

10. Итог

Расследование: разделите данные и внешний вид

• Сначала разделяйте проблемы символов на «слой данных (кодировка)» и «слой внешнего вида (шрифты)». � сигналит о сбое слоя данных, □ — о сбое слоя внешнего вида.
• JIS X 0213:2004 сменил эталонные глифы 168 символов, и Windows начиная с Vista по умолчанию использует глифы JIS2004. То, что 葛, 辻 и 飴 выглядят по-разному в разных средах, — история шрифтов, а не порча данных.

Проектирование: решите, как задаются глифы и что принимается

• Стандартное средство зафиксировать глиф в данных — IVS, но без поддерживающего шрифта и приложения он падает к глифу по умолчанию. Не забудьте влияние на реализацию: один символ может быть до четырёх кодовых единиц UTF-16.
• Пользовательские символы (EUDC) — актив, специфичный для того ПК, и не могут уйти вместе с данными. Реалистичный ответ — инвентаризировать их при миграции, заменить через таблицу соответствия обычным символам или IVS и прекратить создавать новые.
• Система, которая обрабатывает личные имена, решает принимаемый набор и заявляет его. Государство стандартизуется к стандартным символам административных процедур на фундаменте унифицированных символов косэки и инфраструктуры символьной информации, и системы, которые с ним обмениваются, должны следить за этим движением.

Реализация и вывод: защитите оригинал и выровняйте пути отображения

• Для форм и PDF база — «тот же шрифт, что на экране, подтвердить лицензию и внедрить». Для долгосрочного хранения рассмотрите PDF/A.
• Нормализация NFKC, нарезка по кодовым единицам и преобразование CP932 — три больших пункта, которые тихо ломают вариантные символы и пользовательские символы. Сделайте хранение оригинала и обработку в единицах графемы правилом.

В следующий раз, когда вам скажут «символ другой», начните с вопроса: кодовые позиции те же или разные? Если те же — проблема шрифта; если разные — проблема данных. Этот один ход не даёт войти в расследование не с той двери.

flowchart TB
    accTitle: Первый вопрос, который решает точку входа расследования
    accDescr: Когда говорят, что символ другой, сначала сравните, те ли же кодовые позиции или разные, и начните расследование как проблему шрифта, если они те же, и как проблему данных, если разные
    said["Сказали, что символ другой"] --> cmp{"Кодовые позиции те же?"}
    cmp -->|Те же| fontp["Проблема шрифта"]
    cmp -->|Разные| datap["Проблема данных"]

Рис. 16: Если кодовые позиции те же, начинайте расследование как проблему шрифта; если разные — как проблему данных.

Похожие статьи

• Кодировки текста в Windows: кракозябры при обмене с Linux
• Кодировки текста и переводы строк в Windows — основы искажения текста и CRLF/LF
• Печать и PDF в Windows-приложениях: PrintDocument, WPF и библиотеки отчётов
• Локализация WinForms и WPF: resx, спутниковые сборки, переключение культуры
• CSV — не «просто текст». Практика CSV в бизнес-приложениях на C# (кодировки, совместимость с Excel, защита от инъекций)
• Доступность приложений Windows: UI Automation и разумное приспособление

Смежные области консультирования

KomuraSoft LLC занимается проектированием и расследованием обработки символов в бизнес-системах. Мы работаем и со стороны кода, и со стороны шрифта: изолируем причину симптомов вроде «символ на экране и в форме разный» или «имя превратилось в □ после миграции», обследуем пользовательские символы и строим таблицы заменителей при миграции с устаревших систем, проектируем принимаемый набор для систем, которые обрабатывают личные имена, и ревьюируем конфигурацию внедрения шрифтов форм и PDF.

• Разработка Windows-приложений
• Повторное использование и миграция наследия
• Техническая консультация и ревью проекта
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему один и тот же иероглиф 葛 выглядит по-разному на разных ПК и в печатных формах?

Чаще это не кракозябры, а разные глифы шрифта. В JIS X 0213:2004 (JIS2004) эталонные глифы 168 иероглифов заменили на стандартные печатные начертания, и начиная с Windows Vista в MS Gothic, MS Mincho и других шрифтах по умолчанию стоят глифы JIS2004. 葛, 辻 и 飴 — типичные примеры: кодовая позиция Unicode (данные) та же, меняется только глиф шрифта (внешний вид). Сравнение данных совпадает; расхождение между образом формы эпохи XP и экраном нового ПК — штатное поведение. Если нужно совпадение и по начертанию, используйте один шрифт на экране и в форме либо задайте глиф селектором вариантного начертания.

Если включить селекторы вариантного начертания (IVS), закроет ли это все проблемы начертания в личных именах?

Нет. IVS ставит сразу после базового символа селектор начиная с U+E0100 и тем самым фиксирует глиф в данных. Указанный глиф появляется только когда есть и поддерживающий шрифт вроде IPAmj Mincho, и поддерживающее приложение. В среде без поддержки селектор игнорируется и показывается глиф базового символа по умолчанию — так и задумано; в части сред селектор ещё и вылезает как □. Кроме того, один символ с IVS занимает в UTF-16 до четырёх кодовых единиц, и это влияет на подсчёт символов, вырезку и длину столбцов БД. Перед внедрением проверьте охват: отображение, печать и нижестоящие системы.

Символ, зарегистрированный как пользовательский (EUDC), отобразится на другом ПК или в PDF?

Как правило, нет. Пользовательский символ — это глиф, который пользователь регистрирует в файл eudc.tte этого ПК на кодовой позиции области частного использования Unicode (начиная с U+E000). На другом ПК та же позиция не определена или указывает на другой глиф. Поэтому при передаче в почту, PDF или другую систему символ становится □ либо выглядит чужим. Если такие данные уже унаследованы, на миграции реалистично инвентаризировать вхождения области частного использования, построить таблицу соответствия обычным символам Unicode или селекторам вариантного начертания и заменить. В новой системе новые пользовательские символы создавать не стоит.

Насколько широкий набор символов в личных именах должна принимать бизнес-система?

Сначала решите принимаемый набор и зафиксируйте его в спецификации. В семейном реестре около 56 000 унифицированных символов косэки, и стандарт-совместимые государственные системы идут к стандартным символам административных процедур — расширению инфраструктуры символьной информации. Обычная бизнес-система не обязана принимать тот же уровень без ограничений. Реалистичный проект: диапазон вроде «в пределах JIS X 0213» или «селекторы вариантного начертания и область частного использования не принимаем», проверка на вводе и для значений вне диапазона — предупреждение или альтернативная запись. Следить за стандартными символами административных процедур и требованиями обмена на базе JIS X 0221 нужно тем системам, которые стыкуются с государственными или муниципальными.

Как сделать, чтобы печатная форма и PDF показывали те же символы, что и экран?

База — указать один и тот же шрифт на экране и в форме и внедрить шрифт в PDF. Если шрифты разные, те же данные могут сменить глиф; если на просматривающем ПК шрифта нет, рисуется запасной, и внешний вид разъезжается. Можно ли внедрять, задаёт лицензия шрифта (OpenType fsType); не оставляйте это библиотеке отчётов, проверьте сами. Внедрение только использованных символов (subset) ещё и держит размер файла. Если нужно долгосрочное хранение, рассмотрите PDF/A: там внедрение шрифта обязательно.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.