Содержание:

 

0.Обоснование

1.Историческая справка

2.Сравнительный анализ

3.План решения

 

 

0. Обоснование

 

Математика Хангыля с точки зрения программирования, вычислительных наук и комбинаторики является решением алгоритмической задачи хангыля. Как сделать так, чтобы комбинации из 33 элементов хангыля(Древней письменности,созданной инженерами прошлого) собирались линейно согласно чётким правилам и целоисчислительной логике, так как более сложные варианты являются маловероятными с учетом места и времени зарождения технологии. Ответ однозначный, что да это возможно, все элементы могут быть переведены в конкретные уникальные числовые индексы, каждый слог представляет собой уникальную сумму индексов, также все правила переведены в числовые диапазоны, а каждый элемент равен сам себе в независимости от позиции в иерархии.

С точки зрения бизнеса и разработки мы получаем переход от таблицы из 11200 уникальных элементов, их связь носит чисто сортировочный характер, что привело к необходимости перепроверок и таблиц соответствия, к уникальным 33 атомам с рендерингом шрифтов и систем при помощи HarfBuzz или похожей системы, которая ранее успешно справлялась и стала стандартом склеивания элементов для Арабского и Хинди. HarfBuzz уже может склеивать буквы хангыля, но с точки зрения кода это отдельные элементы, поэтому систематического распространения не получила.

Однако математика дает обоснование для перехода к полному отказу от карты комбинаций хангыля. Если точная постановка и правила элементов известны и включены математически, расчет слога происходит алгоритмически , нет необходимости хранить карты и базы.
Краткое описание подхода:

Hangul Mathematics Formula
L1 + L2 + L3(ㅗ|ㅜ|ㅣ) + L4×20 + L5×20(ㄹ|ㄴ|ㅅ)
Равенство букв самим себе и функциям является основой метода
ㄱ(초성)=ㄱ(종성)=ㄱ(ㄺ,ㄳ) | ㅗ+ㅏ=ㅘ
33 числовых тега ровно столько в Хангыле(сㅔ,ㅖ,ㅐ,ㅒ) без необходимости перепроверять

Полная Карта Хангыля и её формула
(19 자음 + 초성 빈 공간)*((14 모음 + 중성 빈 공간) +7 모음 합((ㅘㅙㅝㅞ…))*((16 자음 + 종성 빈 공간+3(ㄸ, ㅃ, ㅉ)) + 11 자음 합(ㅄㄳㄵㄶㅀ…)) = 13 640 요소

Элемент всегда идентичен
Принцип для всех букв: ㄱ(초성)=ㄱ(종성)=ㄱ(ㄺ,ㄳ)

Методология
гласные<=21 согласные>=22 Это обязательное условие

Взаимосвязь
В основе всех вычислений лежит одна формула и её пути-диапазоны

Отсутствие исключений
Пути диапазоны описывают все функции и связь букв в слоге

1. Историческая справка

История Хангыля это история изобретения, созданного инженерами, прошедшего через ограничение функционала и комбинаторных возможностей в условиях зарождения нового вызова того времени, появления печатных машинок, а затем не получившего должного и качественного перехода в цифровой мир из-за того, что не были привлечены специалисты по комбинаторике, которые на тот момент уже были(Пажитнов(создатель Тетриса, комбинаторная сборка элементов на основе чистой математики), Ван Юнминь(Создатель уникального логического цифрового подхода к иероглифике Wubi, который используется до сих пор), японские разработчики ранних консолей и пк, качественно решавших вопросы ПО, геймдизайна и языковых поддержек для разных языков в условиях ограниченного железа).

Подробная хронология от выхода в свет до наших дней:

1443 год: математический фундамент

Создатели хангыля, ученые эпохи короля Седжона, заложили в основу алфавита принцип, который сегодня назвали бы инженерным. В трактате «Хунмин Чоным» (훈민정음) дословно написано: 종성부용초성 «Конечный звук снова использует начальную согласную». Это означало, что одна и та же буква, например ㄱ, является одной и той же сущностью независимо от того, стоит ли она в начале слога, в конце или в составе двойного падчима, то же самое касается гласных, они сочетаются между собой, но не изменяются в своей сути. Алфавит изначально проектировался как комбинаторная система: минимальный набор атомарных элементов, способных породить все возможные слоги по четким геометрическим правилам. Никакого разделения на «начальные» и «конечные», «одинарные» и «двойные»версии одной буквы не предусматривалось - это противоречило бы самой инженерной логике хангыля.

1933 год: первый компромисс - механические машинки

В 1933 году Корейское лингвистическое общество приняло «Унифицированные правила орфографии хангыля» (한글 맞춤법 통일안). Этот документ, созданный для стандартизации письменности в эпоху механических печатных машинок, ввел первое серьезное отступление от изначального принципа 종성부용초성. Было административно закреплено, что согласные ㄸ, ㅃ, ㅉ не могут использоваться в качестве конечных согласных (падчимов). Это решение не имело под собой ни фонетической, ни математической основы - оно было продиктовано исключительно ограничениями механических печатных машинок, для которых изготовление отдельных литер для редко используемых слогов было экономически нецелесообразно. Математический принцип был принесен в жертву удобству технологии того времени.

1987 год: роковая развилка - стандарт KS C 5601

К середине 1980-х годов перед Южной Кореей встала задача цифровизации национального алфавита. Был собран комитет для разработки национального стандарта кодирования KS C 5601. В него вошли государственные чиновники, инженеры из крупных корпораций(прежде всего Samsung, GoldStar/LG, Daewoo) и производители компьютеров, такие как TriGem Computer (Sambo). Перед ними стоял выбор между двумя подходами:

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

Иероглифический (готовые слоги): закодировать каждый возможный слог как отдельный символ. Был предельно прост для реализации, но очень убыточен и сложен для последующих действий, а также лишает Хангыль его простоты.

Инженеры TriGem и других производителей, основывая решение на ограничениях памяти и производительности, выбрали второй путь, так как он был ближе к печатным машинкам, на которые во многом ориентировались производители первых компьютеров. В стандарт были зашиты 2 350 готовых слогов, отобранных по частотности. Все остальные возможные слоги были просто проигнорированы. Буква ㄱ в начале слога и ㄱ в конце слога стали разными кодовыми точками. Принцип 종성부용초성 не был учтен при разработке. Также важно отметить, что проблема не была нерешаемой даже в 80-х, так как Пажитнов решил проблему Тетриса в те же годы и на куда более слабом оборудовании при помощи математики и комбинаторики.

1993 год: консервация ошибки - стандарт Unicode

Когда в начале 1990-х годов Консорциум Unicode приступил к созданию единого мирового стандарта, он столкнулся с уже существующей экосистемой данных в кодировке KS C 5601 (известной как EUC-KR). Южная Корея выдвинула жесткое требование: обеспечить полную обратную совместимость (round-trip compatibility) с уже имеющимися массивами данных.

Консорциумом был выбран компромисс, который на тот момент казался мудрым и исчерпывающим: в Unicode 1.1 (1993 г.) были включены оба подхода. Был создан блок Hangul Syllables из 11 172 готовых слогов (для совместимости со старыми данными) и блоки Hangul Jamo с отдельными буквами (для теоретической возможности динамической сборки), однако последний метод не используется и не имеет полноценных инструментов для работы до сих пор спустя более чем три десятилетия. Также это решение породило двойное представление одного и того же текста (NFC и NFD), где одно Syllables наиболее топорное и низкокачественное оказалось доминирующим по сравнению с базой готовых графем, которыми нужно было научиться правильно пользоваться и вывести закономерности.

2026 год: Абсолютный технологический тупик.

Отсутствие поддержки Jamo, 0 настоящих и полноценных Jamo based API, поддержек и репозиториев, все только на 11 172 готовых слогов. Это как если бы вместо арабских букв в системе содержались все варианты сочетания букв, то есть все системы имеют архитектурный баг, а в итоге все борются с симптомами(Далее мы рассмотрим этот аспект подробно в главе 2. Сравнительный анализ). В рамках эксперимента были проведены проверки работоспособности и отображения Jamo based, для 100% верификации был выбран старый хангыль, который в настоящее время не используется и не может стать слогом Syllable при помощи normalized(это методика меняющая нативное сочетание букв на слог), для умеренной проверки был выбран обычный слог из списка, но также без normalized, оба были созданы с помощью HTML(font-family: "Noto Sans CJK KR", "Malgun Gothic", sans-serif;) из Jamo(графем), по сути своей является симуляцией, графемы идут отдельно и для системы являются тремя разными символами. Итог:
Microsoft:

Visual Studio Insiders 2026 Win UI 3 C++ нулевая поддержка, что старого хангыля, что обычного (без normalized), даже не может отобразить слог. Эксперимент остановлен по причине отсутствия инструментария для разработчиков.
Файловый поиск и отображение: Слоги со Старым хангылем отображаются, но не ищет, новый автоматически в любой системе заменяется на слог из базы. То есть формат склеенных слогов из букв для экосистемы Microsoft нормален и возможен, но не является рабочим.

Android:

Только отображение старых слогов, без возможности выделения и копирования. Обычный слог автоматически проходит через normalized и становится слогом из списка. Эксперимент в Android Studio  принято решение не начинать из-за отсутствия поддержки технологии.

IOS/macOS:

Старый хангыль даже не отображается, только графемы и то не все. Обычный слог автоматически проходит через normalized и становится слогом из списка. Эксперимент в Xcode принято решение не начинать из-за отсутствия поддержки технологии.

Резюме

Проект SAMSEGI -  это возвращение к той развилке, которую индустрия проскочила в 1987 году. Это восстановление в цифровой среде изначального принципа 종성부용초성, который был записан в «Хунмин Чоным» почти 600 лет назад. Примеры, которые сделаны для демонстрации технологии используют маппинг(карту 13640 элементов) из-за архитектурной невозможности сделать иной пример, но фактически это 33 атома, вполне конкретных числовых тега, которые используются для получения сумм при помощи диапазонов и сумм, а не за счет перепроверок, поэтому карта как таковая технологии не требуется.

2. Сравнительный анализ

В этом разделе будет конкретный разбор IT-решений для разных языков по конкретным языкам.
Однако помимо прямого сравнения вводится новая переменная Мультипликатор костылей, показатель оценивает, сколько уникальных, специфичных для языка внешних надстроек, патчей и обходных путей требуется для обеспечения базовой функциональности. Чем их больше, тем ниже балл.

Главный критерий: «Закрытость вопроса». Чем больше свежих публикаций, патентов, баг-репортов и активных обсуждений на GitHub и форумах разработчиков, тем ниже балл. Английский (10) - идеал, где всё решено.

Итоговая таблица



Детальное обоснование (по данным поиска):

1. Мультипликатор костылей

Корейский (1/10): Абсолютный лидер по количеству «костылей». Новые патенты продолжают регистрироваться в 2024-2025 гг. (Samsung, KEPCO, Naver). Существуют специальные библиотеки (libhangul), которые, однако, имеют вариации и адаптации под разные системы и при этом не являются стандартом, а общепринятым доступным решением. Двойное представление (NFC/NFD) и легаси EUC-KR требуют постоянных «танцев с бубном».

Арабский (4/10): Требует целого набора инструментов для работы: arabic_reshaper для правильного отображения, python-bidi для двунаправленного текста, специальные токенизаторы и обязательную поддержку CTL/RTL везде.

Хинди (5/10): Нуждается в специальных шрифтах с поддержкой сложных лигатур (деванагари), в особой обработке графемных кластеров в движках рендеринга и адаптированных NLP-инструментах.

Китайский (5/10): Требует отдельных библиотек для сегментации слов и специфических токенизаторов для поиска (ICU/триграммы).

Вьетнамский (8/10): После принятия Unicode проблема почти исчезла. Остались лишь единичные инструменты вроде Unikey.

Английский (10/10): Ноль костылей.

2. Системы ввода (IME)

Здесь корейский язык демонстрирует катастрофическое отставание.

Корейский (2/10): Это самый проблемный сектор. Баг-трекеры переполнены: claude-code (#12528, #59426), warp (#6891), OpenCode, Ghostty - везде открыты десятки багов, связанных с непрерывной композицией слога.

Арабский (6/10): Требует ручных доработок в VS Code terminal, Matplotlib и других средах из-за RTL/Arabic shaping. Проблема известна, но ее решение упирается в сложность реализации, а не в архитектурный дефект.

Хинди (7/10): В основном стабилен, но есть специфические баги рендеринга составных символов (matras) в отдельных библиотеках вроде PyMuPDF.

Китайский (7/10): Пиньинь стабилен, но ввод редких иероглифов все еще требует улучшений.

Вьетнамский (8/10): Редкие баги в терминалах, не связанные напрямую с языком.

Английский (10/10): Эталон эффективности.

3. LLM-токенизация и стоимость API

Самый горячий сектор для многих языков, кроме английского.

Корейский (3/10): Token fertility ~2.36x от английского. Эта проблема активно исследуется ("Korean Penalty", 2024), появляются десятки патентов.

Арабский (4/10): Ситуация хуже, чем у корейского. "Налог на токены" достигает 230% (token tax x3.3). Создаются специальные инструменты вроде Tokenizer Lab.

Хинди (5/10): Стандартные токенизаторы неэффективны из-за сложных conjuncts. Регулярно выходят новые работы (WWHO-архитектура).

Китайский (7/10): Область активных исследований, но прорывных проблем меньше.

Вьетнамский (9/10): Диакритика немного увеличивает расход токенов, но это не является системной проблемой.

Английский (10/10): Эталон эффективности.

4. Поиск (FTS, Regexp, SQLite)

Корейский (4/10): Двойное представление (NFC/NFD) ломает поиск. Баг-репорты в SQLite FTS (issue #4, 2026) подтверждают, что проблема актуальна.

Арабский (6/10): Требует обработки диакритики и специальных символов, но основные решения известны.

Хинди (6/10): Аналогично арабскому, требует понимания графемных кластеров.

Китайский (7/10): Основная проблема - сегментация слов. Решается с помощью ICU.

Вьетнамский (9/10): Проблем нет.

Английский (10/10): Эталон эффективности.

5. Встраиваемые системы и IoT

Корейский (4/10): Хранение 11,172 готовых слогов переполняет память, а также требует таблиц соответствия или иных внешних, если нужна работа с данными. Обсуждения этой проблемы активны на форумах вроде SEGGER.

Арабский (5/10): Обязательная поддержка RTL/CTL на маломощных устройствах - сложная задача.

Хинди (6/10): Сложные лигатуры требуют больше памяти, чем латиница.

Китайский (6/10): Требует хранения тысяч иероглифов.

Вьетнамский (9/10): Латиница + диакритика, проблем мало.

Английский (10/10): 26 букв в килобайтах памяти.

6. Электронная коммерция

Корейский (5/10): Сложности с вводом на локальных платформах (Naver, Coupang) и иностранными названиями ведут к брошенным корзинам. Это отдельная статья расходов на UX.

Арабский (6/10): Локализация RTL - устоявшийся, но более сложный процесс.

Хинди (6/10): Проблемы решаются в рамках общей многоязычной поддержки Индии.

Китайский (7/10): Адаптация под локальные платформы отлажена.

Вьетнамский (8/10): Локализация стабильна.

Английский (10/10): Глобальный стандарт без проблем.

Вывод
Таблица наглядно показывает, что корейский язык (3.2) находится в наихудшем положении не из-за изначальной сложности, а из-за архитектурного дефекта. Его отставание особенно заметно в критически важных сегодня секторах LLM (3/10) и IME (2/10), а также по мультипликатору костылей (1/10).

Конкретные ссылки:

Английский (English) - Эталон (10)
По всем секторам ссылок на нерешенные проблемы практически нет. Всё работает.

LLM-токенизация: Специфических проблем нет.

Поиск: Специфических проблем нет.

IME: Не требуется.

IoT: Шрифт из 26 букв, проблемы отсутствуют.

E-commerce: Глобальный стандарт.

Мультипликатор костылей: 0 внешних надстроек. Оценка: 10.

Вьетнамский (Tiếng Việt) - Вопрос закрыт (8.6)

LLM-токенизация (9): Единичные исследования диакритики.

Поиск (9): Проблем нет с 2003 года (стандарт TCVN 6909:2001).

IME (8): Редкие баги в CLI-средах (не специфичны для языка).

IoT (9): Латиница + диакритика, проблем нет.

E-commerce (8): Локализация стабильна.

Мультипликатор костылей: Unikey (стабилен). Оценка: 8.

Китайский (中文) - Объективная сложность (6.8)

LLM-токенизация (7):

Jieba (Python): https://github.com/fxsjy/jieba

PKUSeg: https://github.com/lancopku/pkuseg-python

Поиск (7):

SQLite FTS3/4/5 + ICU: https://sqlite.org/fts5.html

IME (7):

Wubi (Pinyin): https://github.com/rust-wubi/wubi

IoT (6):

Noto CJK: https://github.com/notofonts/noto-cjk

E-commerce (7): Адаптация под локальные платформы отлажена.

Мультипликатор костылей: Jieba, PKUSeg, Wubi, ICU. Оценка: 5.
Хинди (हिन्दी) - Визуальная сложность (6.0)

LLM-токенизация (5):

WWHO Architecture (2024): https://arxiv.org/abs/2410.04281

Devanagari Tokenizer Issue (Hugging Face): https://huggingface.co/ai4bharat/indic-bert/issues/8

Поиск (6): Графемные кластеры.

IME (7):

PyMuPDF (matra bug): https://github.com/pymupdf/PyMuPDF/issues/2350

IoT (6):

Noto Devanagari: https://github.com/notofonts/devanagari

E-commerce (6): Многоязычная поддержка.

Мультипликатор костылей: Indic-BERT, Noto Devanagari, PyMuPDF. Оценка: 5.

Арабский (العربية) - Письменность «второго уровня» (5.4)
 
LLM-токенизация (4):

Tokenizer Lab (2025): https://tokenizerlab.com/arabic

Arabic Token Tax (230%): https://blog.premai.io/arabic-nlp/

Поиск (6): Диакритика и left half-ring.

IME (6):

VS Code Terminal RTL: https://github.com/microsoft/vscode/issues/147358

Matplotlib Arabic: https://matplotlib.org/stable/users/explain/text/rendering.html

IoT (5):

Embedded RTL (SEGGER): https://forum.segger.com/index.php/Thread/9063-Arabic-TTF-rendering/

E-commerce (6): RTL-локализация.

Мультипликатор костылей: arabic_reshaper, python-bidi. Оценка: 4.

Корейский (한국어) - Архитектурный сбой (3.6)

LLM-токенизация (3):

Korean Token Penalty (2024): https://arxiv.org/abs/2405.09137

TianPan Research (2026): https://tianpan.co

Поиск (4):

SQLite FTS5 CJK (2026): https://github.com/arjunkmrm/recall/issues/4

IME (2):

Warp Terminal: https://github.com/warpdotdev/warp/issues/6891

Claude Code #12528: https://github.com/anthropics/claude-code/issues/12528

Claude Code #59426: https://github.com/anthropics/claude-code/issues/59426

Claude Code #18291: https://github.com/anthropics/claude-code/issues/18291

Ghostty: https://github.com/ghostty-org/ghostty/issues/5404

OpenCode: https://github.com/anthropics/opencode/issues/303

Gemini CLI: https://github.com/google-gemini/gemini-cli/issues/1479

BossTerm: https://github.com/steveasi/bossterm/issues/87

libhangul: https://github.com/libhangul/libhangul

IoT (4):

SEGGER Korean TTF: https://forum.segger.com/index.php/Thread/9063-Arabic-TTF-rendering/

E-commerce (5):

SIR KCP Encoding (2025): https://sir.kr/bbs/board.php?bo_table=yc5_plugin&wr_id=515

EUC-KR Issue (2024): https://sir.kr/bbs/board.php?bo_table=yc_issue&wr_id=789

Мультипликатор костылей: libhangul, EUC-KR патчи, IME-фиксы. Оценка: 1.

 

 

 

3.План решения

Установленные факты

Проблема цифрового представления хангыля имеет более глубокий характер, чем предполагалось. Тридцатилетние усилия индустрии были направлены на борьбу с симптомами, а не с первопричиной, которая заключается в архитектурном дефекте, заложенном в стандарт Unicode 1993 года. Этот дефект породил фрагментированную систему из 11 200+ элементов, требующую постоянных проверок и внешних костылей.

Экспериментально подтверждено, что механизм динамической сборки слогов из отдельных графем физически присутствует в современных операционных системах (DirectWrite в Windows, HarfBuzz в Android и браузерах). Он способен корректно отображать как современные, так и старые слоги, не вошедшие в Unicode. Однако этот механизм действует вслепую, создавая лишь визуальную иллюзию целостного символа и не формируя полноценную структурную единицу для поиска, анализа и обработки данных, а также не обрабатывая должным образом графемы.

Проект SAMSEGI восполняет этот критический пробел, предоставляя недостающую математическую карту. Модель из 33 числовых тегов и формулы L1+L2+L3+L4×20+L5×20 наделяет механизм сборки точной, вычисляемой адресацией, впервые превращая визуальную иллюзию в строгую инженерную реальность, где каждый слог получает уникальный математический индекс.

Распределение зон ответственности

Гарантированный результат от внедрения SAMSEGI

Математическая модель SAMSEGI сама по себе, без каких-либо изменений в существующем унаследованном коде, устраняет фундаментальный архитектурный дефект. Её внедрение обеспечивает:

Повышение Мультипликатора костылей с 1 до 8. Этот показатель достигает уровня вьетнамского языка, где проблема цифровой стандартизации была успешно решена.

Замену 11 200+ элементов. Вся обработка сводится к 33 тегам и формулам,
что радикально снижает издержки на хранение, проверку и передачу данных.

Математический индекс для каждого слога. Этот индекс пригоден для поиска, сортировки и анализа, не требуя при этом потери исходных атомов. Метод универсален и применим к любому слогу, включая те, что отсутствуют в современном стандарте Unicode.

Направления для дальнейшего развития

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

На уровне операционных систем: замена «слепой» адресации в движках рендеринга (DirectWrite, CoreText) на вычислимую формулу SAMSEGI.

На уровне шрифтов: переход от 11 172 готовых слогов к 33 атомарным глифам. Это сократит размер шрифтов в сотни раз и полностью устранит проблему повреждённых или отсутствующих символов.

На уровне систем ввода (IME): отказ от непрерывной композиции слога в пользу его мгновенного вычисления, что ликвидирует целый класс багов в терминалах, IDE и любых полях ввода.

На уровне поиска и NLP: отказ от тяжеловесных таблиц соответствия (ICU, триграммы) и переход на прямой доступ к математическим тегам L1–L5.

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

Экономический эффект

Прямая экономия: снижение показателя token fertility в 2 раза, отказ от хранения 11 172 готовых слогов в шрифтах, устранение дублирующей инфраструктуры (EUC‑KR, ICU) и связанных с ней накладных расходов.

Стратегическая выгода: корейский язык перестаёт быть «цифровым исключением» и достигает эффективности вьетнамского, а в перспективе - приближается к показателям английского.

Новые рынки: открываются возможности для массового внедрения хангыля в нишевых и быстрорастущих сегментах, таких как Интернет вещей, встраиваемые системы и AI-сервисы, которые ранее были заблокированы из-за дороговизны обработки.

Заключение

Математика является более фундаментальным и универсальным языком для IT-систем, чем любой естественный язык. SAMSEGI не предлагает улучшение существующего механизма - проект восстанавливает изначальную математическую гармонию хангыля, заложенную Седжоном, но утраченную в цепочке технологических компромиссов. Предлагаемое решение является не очередным «патчем», а фундаментом для новой технологической эры корейского языка. Создан не инструмент для устранения симптомов, а основа для построения принципиально иной, математически выверенной архитектуры.

По любым вопросам свяжитесь по почте:
info@samsegi.com