Понимание терминов - кодировки символов, шрифты, глифы

Question

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

Кодировка символов -> Набор правил, которые сообщают ОС, как хранить символы. Например, ISO8859-1, MSWIN1252, UTF-8, UCS-2, UTF-16. Эти правила также называются кодовыми страницами / наборами символов, которые отображают отдельные символы в числа. Очевидно, Unicode обрабатывает это немного иначе, чем другие. т. е. вместо прямого сопоставления числа (кодовой точки) с глифом, он отображает кодовую точку на абстрактный «символ», который может быть представлен различными глифами. [http://www.joelonsoftware.com/articles/Unicode.html]

Fonts -> Это реализация кодировки символов. Это файлы разных форматов (True Type, Open Type, Post Script), которые содержат сопоставление для каждого символа в кодировке число.

Символы -> Это визуальное представление символов, хранящихся в файлах шрифтов.

И исходя из вышеизложенного, у меня есть следующие вопросы,

1) Чтобы ОС понимала кодировку, она должна быть установлена ​​отдельно? Или достаточно установить шрифт, который поддерживает кодировку? Можно ли использовать аналогию протокола, скажем, TCP, используемого в сети, с кодировкой, поскольку это просто набор правил. (конечно же, возникает вопрос: как ОС понимает эти сетевые протоколы, когда я их не устанавливаю :-p)

2) Будет ли шрифт всегда иметь полную реализацию кодовой страницы или только ее часть? Есть ли инструмент, который я могу использовать, чтобы увидеть каждый символ в шрифте (файл .TTF?) [Средство просмотра шрифтов Windows показывает, как выглядит стиль шрифта, но не дает информацию о списке символов в файле шрифта]

3) Поддерживает ли файл шрифтов несколько кодировок? Есть ли способ узнать, какую кодировку поддерживает шрифт?

Я прошу прощения за то, что задал слишком много вопросов, но я некоторое время думал об этом, и я не мог найти сайт, который был бы достаточно прост для моего понимания. Любая помощь / ссылки для понимания этого материала будет приветствоваться. Заранее спасибо.

Answer 1

Очевидно, Unicode обрабатывает это немного иначе, чем другие. то есть., вместо прямого преобразования числа (кодовой точки) в глиф, оно отображает кодовую точку на абстрактный «символ», который может быть представлены разными глифами.

В модели кодирования символов Unicode существует 4 уровня:

• Репертуар абстрактных символов (ACR) & mdash; Набор символов для кодирования.
• Набор кодированных символов (CCS) & mdash; Соотношение один-к-одному из символов в целое число кодовые точки .
• Форма кодировки символов (CEF) & mdash; Преобразование из кодовых точек в последовательность кодовых единиц фиксированной ширины .
• Схема кодирования символов (CES) & mdash; Отображение из кодовых единиц в сериализованную последовательность байтов.

Например, символ & # x1d11e; представлена ​​кодовой точкой U + 1D11E в Unicode CCS, двумя кодовыми единицами D834 DD1E в UTF-16 CEF и четырьмя байтами 34 D8 1E DD в UTF-16LE CES.

В большинстве более старых кодировок, таких как US-ASCII, CEF и CES тривиальны: каждый символ непосредственно представлен одним байтом, представляющим его код ASCII.

1) Чтобы ОС понимала кодировку, должна ли она быть установлена отдельно?.

ОС не имеет для понимания кодировки. Вы можете свободно использовать стороннюю библиотеку кодирования, такую ​​как ICU или GNU libiconv , для преобразования между вашей кодировкой и собственной кодировкой ОС на уровне приложения.

2) Будет ли шрифт всегда иметь полную реализацию кодовой страницы или только ее часть?.

В дни 7-битной (128-символьной) и 8-битной (256-символьной) кодировки было обычным делом включать шрифты для всей кодовой страницы. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * [10] * * * * *

* * * * * * * * * * * * * * * * * * * * сегодня все шрифты включают в себя все 100 000+ назначенных символов.

Answer 2

Если вы хотите узнать больше, конечно, я могу указать вам некоторые ресурсы:

Юникод, системы письма и т. Д.

Лучшим источником информации, вероятно, была бы эта книга Юкка :

Объяснение Unicode

Если вы перейдете по ссылке, вы также найдете следующие книги:

CJKV Обработка информации - подробно рассказывает о китайском, японском, корейском и вьетнамском, но мне кажется, что это довольно трудно читать.

Шрифты и кодировки - лично я не читал эту книгу, поэтому не могу сказать вам, хорошая она или нет.Кажется, по теме.

Интернационализация

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

Разработка международного программного обеспечения - этоможет быть 8 лет, но это все еще стоит каждого цента, который вы собираетесь потратить на это.Возможно, примеры программирования относятся к Windows (C ++ и .Net), но знания i18n и L10n действительно есть.Мой коллега однажды сказал, что это спасло ему около 2 лет обучения.Насколько я могу судить, он не преувеличивал.

Вас могут заинтересовать некоторые блоги или веб-сайты на эту тему:

• Разбираться во всем - блог Майкла Каплана, часто о поддержке i18n на платформе Windows
• Глобальный дизайн - Джон Юнкер активно публикует кусочки знаний i18n на этом сайте
• Интернационализация (I18n), Локализация (L10n), Стандарты и развлечения - также известный как i18nguy, веб-сайт, где вы можете найти больше ссылок, учебных пособий и прочего.

Интернационализация Java

Боюсь, что я не знаю о многих современных ресурсах по этой теме (то есть общедоступных).Единственный известный мне ресурс - След интернационализации Java .К сожалению, он довольно неполный.

Интернационализация JavaScript

Если вы разрабатываете веб-приложения, вам, вероятно, нужно также что-то связанное с i18n в js.К сожалению, поддержка довольно слабая, но есть несколько библиотек, которые помогают справиться с проблемой.Наиболее примечательными примерами могут быть Dojo Toolkit и Globalize .
Предыдущий вариант немного тяжел, хотя и поддерживает многие аспекты i18n, последний легок, но, к сожалению, многие вещи отсутствуют,Если вы решите использовать Globalize, вас может заинтересовать последняя книга Юкки:

Выход на глобальный уровень с JavaScript & Globalize.js - я читал это и насколькоЯ могу сказать, это здорово.Он не охватывает темы, которые вы изначально просили, но все же стоит прочитать, даже для практических примеров использования Globalize.

Answer 3

Я предоставлю вам короткие ответы на ваши вопросы.

1. Как правило, не ОС поддерживает кодировку, а приложения. Кодировки используются для преобразования потока байтов в списки символов. Например, в C # чтение строки UTF-8 автоматически сделает ее UTF-16, если вы скажете, что она должна обрабатывать ее как строку.
   Независимо от того, какую кодировку вы используете, C # просто будет использовать UTF-16 для внутреннего использования, и когда вы захотите, например, напечатать строку из кодировки foreign , он сначала преобразует ее в UTF-16, а затем ищет вверх соответствующие символы в таблицах символов (шрифты) и показывает глифы.
2. Я не помню, чтобы когда-либо видел полный шрифт. У меня нет большого опыта работы со шрифтами, поэтому я не могу дать вам ответ на этот вопрос.
3. Ответ на этот вопрос находится в # 1, но краткое резюме: шрифты, как правило, не зависят от кодировки, это означает, что до тех пор, пока система может преобразовывать входную кодировку в кодировку шрифта, у вас все будет в порядке.

Бонусный ответ: « как ОС понимает сетевые протоколы, которых она не знает? »: опять-таки, не ОС обрабатывает их, а приложение. Пока ОС знает, куда перенаправлять трафик (какое приложение), ей действительно не нужно заботиться о протоколе. Обычно необходимо устанавливать низкоуровневые протоколы, чтобы ОС знала, куда отправлять данные.

Этот ответ основан на моем понимании кодировок, которые могут быть неправильными. Поправьте меня, если это так!