Кодировка 16 битная: Персональный сайт преподавателя информатики

Содержание

Персональный сайт преподавателя информатики — Задача 2.1

Система задач на кодирование текстовой информации.

В задачах данного типа используются следующие понятия: кодирование, код, кодовая таблица (таблица кодировки). В задачах могут быть использованы следующие таблицы кодировки ASCII, Unicode, ISO, DOS, MAC, КОИ-8.

Решение задач на кодирование текстовой информации.

Задача 1. Текст, состоящий из 142 символов, закодирован с помощью таблицы кодировок Unicode. Определите количество информации (в битах) содержащейся в тексте.

Решение. Воспользуемся формулой: I= K×i, где I- количество информации, K- количество символов в тексте, i – информационный вес одного символа.

В таблице кодировок Unicode, для хранения каждого символа используется 2 байта. В тесте 142 символа, следовательно, I= 142×2=284байта.

Переводим из одной единицы измерения в другую, так как 1байт=8бит, то 284байт×8бит= 2272 бит.

Ответ. Информационный объем текста 2272бит.

Задача2. Сообщение из 118 символов было записано в 8-битной кодировке Windows-1251, после вставки в текстовый редактор сообщение было перекодировано в 16-битный код Unicode. На какое количество информации увеличилось количество памяти, занимаемое сообщением?

Решение. В кодировке Windows-1251, для хранения одного символа используется 8 бит, вычислим количество информации в сообщение. I= K×i, следовательно I=118×1=118байт.

В кодировке Unicode, для хранения одного символа используется 16 бит, тогда количество информации в сообщение будет равно: I=118×2=236байт.

В задачи стоит вопрос, на какое количество информации увеличилось количество памяти, для этого необходимо найти разность полученных объемов. 236-118=118байт.

Ответ: на 118 байт увеличилось количество памяти занятое сообщением.

Задача3. Автоматическое устройство осуществило перекодировку информационного сообщения на русском языке, первоначально записанного в 16-битном коде Unicode, в 8-битную кодировку КОИ-8. При этом количество информации уменьшилось на 480бит. Какова длина сообщения в символах?

Решение. Обозначим количество символов в сообщении через х.

Составим уравнение: количество бит, которое было первоначально, минус количество бит после перекодировки равно 480 бит.

16х-8х=480,

8х=480,

х=480/8,

х=60 символов.

Ответ: сообщение содержит 60 символов.

Задача4. С помощью последовательности десятичных кодов 99 111 109 112 117 116 101 114 закодировано слово computer. Какая последовательность десятичных кодов будет соответствовать этому же слову, записанному прописными буквами?

Решение. Таблица кодировок сначала содержит прописные буквы в алфавитном порядке, а затем строчные. Так как разница между десятичным кодом строчной буквы латинского алфавита и десятичным кодом соответствующей прописной буквы равна 32, то десятичный код прописной буквы С равен 99-32=67.

Аналогичным образом находятся остальные десятичные коды. 111-32=79, 109-32=77, 112-32=80, 117-32=85, 116-32=84, 101-32=69, 114-32=82.

Последовательность десятичных кодов слова COMPUTER составляет 67 79 77 80 85 84 69 82.

Ответ. 67 79 77 80 85 84 69 82.

Задача5. Для кодирования букв А, Б, В, Г решили использовать двухразрядные последовательные числа (от 00 до 11 соответственно). Какая получиться последовательность, если таким способом закодировать последовательность символов ВАБВГАБГ и записать результат шестнадцатеричным кодом?

Решение. Для записи текстовой информации необязательно использовать стандартные 8-битные и 16-битные кодовые таблицы. Если количество различных символов в сообщении мало, можно использовать особые, короткие, коды для записи каждого символа. Последовательность нулей и единиц, которыми кодируются символы сообщения, называются кодовыми словами. Если вероятность появления каждого символа сообщения одинакова, то символы кодируют кодовыми словами одинаковой длины. Составим таблицу кодовых слов. Для этого выпишем кодовое слово для каждой буквы.

Закодируем данную последовательность ВАБВГАБГ символов, для этого выпишем коды букв в том же порядке, что и буквы исходного сообщения, согласно этой таблицы.

1000011011000111

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

1000|0110|1100|0111

8 | 6 | C | 7

Ответ: 86С7.

Задача 6. Для 5 букв латинского алфавита заданы их двоичные коды для некоторых букв из двух бит, для некоторых из трех. Эти коды представлены в таблице:

Определите, какой набор букв закодирован двоичной строкой 0110100011000.

Решение. Так как код записывается начиная с младшего разряда, то необходимо разбить двоичную строку, начиная справа: 0110|100|011|000. При этом видно, что последние три буквы будут C, E, A. Кода 0110 нет, тогда его можно разбить код из двух бит: 01|10, следовательно, 01-В, 10-D. Итак, двоичной строкой 0110100011000 закодирован следующий набор букв BDCEA.

Ответ: двоичной строкой закодирован набор букв BDCEA.

Задачи для самостоятельного решения

разрядные и 16разрядные коды символов.

Работа добавлена на сайт samzan.ru: 2016-03-13

Представление текстовой информации в компьютере.

Текстовая информация, как и любая другая, хранится в памяти компьютера в двоичном виде. Для этого каждому символу ставится в соответствие некоторое неотрицательное число, называемое кодом символа, и это число записывается в память ЭВМ в двоичном виде. Конкретное соответствие между символами и их кодами называется системой кодировки.

В современных ЭВМ, в зависимости от типа операционной системы и конкретных прикладных программ, используются 8-разрядные и 16-разрядные коды символов.

Использование 8-разрядных кодов позволяет закодировать 256 различных знаков, этого вполне достаточно для представления многих символов, используемых на практике. При такой кодировке для кода символа достаточно выделить в памяти один байт.

В персональных компьютерах обычно используется система кодировки ASCII (American Standard Code for Information Interchange американский стандартный код для обмена информации). Он введен в 1963 г. и ставит в соответствие каждому символу семиразрядный двоичный код. Легко определить, что в коде ASCII можно представить 128 символов.

В системе ASCII закреплены две таблицы кодирования базовая и расширенная. Базовая таблица закрепляет значения кодов от 0 до 127, а расширенная относится к символам с номерами от 128 до 255.

Первые 32 кода базовой таблицы, начиная с нулевого, отданы производителям аппаратных средств. Начиная с 32 по 127 код размещены коды символов английского алфавита, знаков препинания, арифметических действий и некоторых вспомогательных символов. Например, 32 — код пробела; 48-57 коды цифр 0..9; 65-90 коды заглавных латинских букв A-Z; 97-122 коды строчных латинских букв a-z.

Расширенная таблица, как правило содержат коды символов русского языка и в качестве расширенной части выступают кодировочные таблицы Windows 1251, КОИ-8, ISO, DOS и др.

Кодировка символов русского языка, известная как кодировка Windows-1251, была введена “извне” — компанией Microsoft, но, учитывая широкое распространение операционных систем и других продуктов этой компании в России, она глубоко закрепилась и нашла широкое распространение.

Другая распространённая кодировка носит название КОИ-8 (код обмена информацией, восьмизначный) её происхождение относится к временам действия Совета Экономической Взаимопомощи государств Восточной Европы.

Международный стандарт, в котором предусмотрена кодировка символов русского языка, носит названия ISO (International Standard Organization Международный институт стандартизации).

Универсальная система кодирования текстовых данных

По причине ограниченности набора кодов (256)возникла система, основанная на 16-разрядном кодировании символов, получила название универсальной UNICODE. Шестнадцать разрядов позволяют обеспечить уникальные коды для 65 536 различных символов этого поля вполне достаточно для размещения в одной таблице символов большинства языков планеты. Сегодня это самая распространенная текстовая кодировочная система.

Пример. Объем сообщения, содержащего 2048 символов, составил 1/512 часть Мбайта. Определить мощность алфавита.

Решение.
I = 1/512 * 1024 * 1024 * 8 = 16384 бит. — перевели в биты информационный объем сообщения.
а = I / К = 16384 /1024 =16 бит — приходится на один символ алфавита.
216 = 65536 символов — мощность использованного алфавита.
Именно такой алфавит используется в кодировке Unicode, который должен стать международным стандартом для представления символьной информации в компьютере.

Пример 1. Автоматическое устройство осуществило перекодировку информационного сообщения на русском языке, первоначально записанного в 16-битном коде Unicode, в 8-битную кодировку КОИ-8. При этом информационное сообщение уменьшилось на 480 бит. Какова длина сообщения в символах?

Если обозначим количество символов через k, то при 16-битной кодировке объем сообщения составит 16k бит. Если его перекодировать в 8-битный код, его объем станет 8k бит. Таким образом, сообщение уменьшилось на 16k 8k = 8k = 480 бит. Следовательно, k = 60 символов.

Пример 2. Считая, что каждый символ кодируется 16-ю битами, оцените информационный объем в битах следующей фразы в кодировке Unicode:

Истина только одна

Текст содержит 20 символов. Если один символ кодируется 16 битами, то в сообщении 2016=320 бит информации.

Пример 3. В таблице ниже представлена часть кодовой таблицы ASCII:

Символ	1	5	A	B	Q	a	b
Десятичный код	49	53	65	66	81	97	98
Шестнадцатеричный код	31	35	41	42	51	61	62

Каков шестнадцатеричный код символа «q»?

Так как в кодовой таблице ASCII все заглавные латинские буквы A-Z расположены по алфавиту. Следовательно, разница кодов букв «q» и «a» равна разнице кодов букв «Q» и «A», то есть, 5116 4116=1016. Тогда шестнадцатеричный код символа «q» равен коду буквы «a» плюс 1016. Следовательно, имеем 6116 + 1016=7116.

Задания

Что Такое Unicode, Utf-8, Utf-16?

Зачем нужен Юникод?

В (не слишком) ранние дни все, что существовало, было ASCII. Это было нормально, так как все, что когда-либо понадобилось, было несколько контрольных символов, знаков препинания, цифр и букв, подобных тем, которые приведены в этом предложении. К сожалению, сегодня странный мир глобальных коммуникаций и социальных сетей не был предвиден, и не слишком необычно видеть английский, العربية, 汉语, עִבְרִית, ελληνικά и ភាសាខ្មែរ в том же документе (надеюсь, что я не сломал старые браузеры).

Но ради аргумента, скажем, Joe Average — разработчик программного обеспечения. Он настаивает на том, что ему понадобится только английский, и как таковой хочет использовать только ASCII. Это может быть хорошо для пользователя Joe, но это плохо для Joe разработчика программного обеспечения. Примерно половина мира использует нелатинские символы, и использование ASCII, возможно, не учитывает этих людей, и, кроме того, он закрывает свое программное обеспечение для большой и растущей экономики.

Следовательно, требуется набор символов, включающий все языки. Так появился Unicode. Он присваивает каждому символу уникальный номер, называемый кодовой точкой. Одним из преимуществ Unicode над другими возможными наборами является то, что первые 256 кодовых точек идентичны ISO-8859-1, а значит, и ASCII. Кроме того, подавляющее большинство обычно используемых символов могут быть представлены только двумя байтами в области, называемой Базовая многоязычная плоскость (BMP). Теперь для доступа к этому набору символов требуется кодировка символов, и, как будет задан вопрос, я сосредоточусь на UTF-8 и UTF-16.

Вопросы памяти

Итак, сколько байтов дает доступ к тем, какие символы в этих кодировках?

UTF-8:

UTF-16:

Теперь стоит упомянуть, что персонажи, не входящие в BMP, включают древние сценарии, математические символы, музыкальные символы и реже китайский/японский/корейский (CJK) символов.

Если вы будете работать в основном с ASCII-символами, то UTF-8, безусловно, будет более эффективным с точки зрения памяти. Однако, если вы работаете в основном с неевропейскими сценариями, использование UTF-8 может быть в 1,5 раза меньше памяти, чем UTF-16. При работе с большими объемами текста, например большими веб-страницами или длинными текстовыми документами, это может повлиять на производительность.

Основы кодирования

Примечание. Если вы знаете, как кодируются UTF-8 и UTF-16, перейдите к следующему разделу для практических приложений.

UTF-8:

1

UTF-16:

суррогатные пары

знак байта

Как видно, UTF-8 и UTF-16 нигде не совместимы друг с другом. Поэтому, если вы делаете ввод-вывод, убедитесь, что знаете, какую кодировку вы используете! Более подробную информацию об этих кодировках см. В разделе Часто задаваемые вопросы UTF.

Практические соображения программирования

Типы данных символов и строк:Как они кодируются на языке программирования? Если они являются необработанными байтами, то в минуту, когда вы пытаетесь вывести символы, отличные от ASCII, вы можете столкнуться с несколькими проблемами. Кроме того, даже если тип символа основан на UTF, это не означает, что строки являются правильными UTF. Они могут разрешать байтовые последовательности, которые являются незаконными. Как правило, вам придется использовать библиотеку, поддерживающую UTF, такую как ICU для C, С++ и Java. В любом случае, если вы хотите ввести/вывести что-то, отличное от кодировки по умолчанию, вам сначала придется преобразовать его.

Рекомендуемые/стандартные/доминирующие кодировки: При выборе варианта использования UTF обычно лучше следовать рекомендуемым стандартам для среды, в которой вы работаете. Например, UTF-8 доминирующей в Интернете, а с HTML5 это рекомендуемая кодировка. И наоборот, среда .NET и Java основана на типе символов UTF-16. Смутно (и неправильно) часто ссылаются на «кодировку Unicode», которая обычно относится к доминирующей кодировке UTF в данной среде.

Поддержка библиотеки: Какие кодировки используются библиотеками, которые вы используете? Поддерживают ли они угловые случаи? Поскольку необходимость является матерью изобретений, библиотеки UTF-8 обычно поддерживают 4-байтовые символы, так как часто могут встречаться символы 1, 2 и даже 3 байта. Однако не все предполагаемые библиотеки UTF-16 правильно поддерживают суррогатные пары, поскольку они встречаются очень редко.

Counting characters: There exist combining characters in Unicode. For example the code point U+006E (n), and U+0303 (a combining tilde) forms ñ, but the code point U+00F1 forms ñ. They should look identical, but a simple counting algorithm will return 2 for the first example, 1 for the latter. This isn’t necessarily wrong, but may not be the desired outcome either.

Comparing for equality: A, А, and Α look the same, but they’re Latin, Cyrillic, and Greek respectively. You also have cases like C and Ⅽ, one is a letter, the other a Roman numeral. In addition, we have the combining characters to consider as well. For more info see Duplicate characters in Unicode.

Суррогатные пары: Они появляются достаточно часто на SO, поэтому я просто приведу несколько примеров ссылок:

Другие:

Как работает FC-AL | Журнал сетевых решений/LAN

Основные протоколы физического уровня Fibre Channel.

Часто название протокола доступа к среде передачи в соответствующей конфигурации — «петля с арбитражем доступа» (Fibre Channel Arbitrated Loop, FC-AL) — используют в качестве эквивалента названия технологии Fibre Channel. Однако, по иронии судьбы, получивший такую известность протокол не входил в первоначальный вариант стандарта и лишь впоследствии был принят в качестве дополнения к нему.

Ниже мы рассмотрим основные процедуры, протоколы и технологии уровня передачи FC-1 и сигнального уровня FC-2 и, в частности, непосредственно сам арбитраж доступа.

КОДИРОВАНИЕ 8B/10B

Рисунок 1. Преобразование 8В/10В.

Уровень FC-1 определяет протокол передачи, в том числе правила кодирования и декодирования, специальные символы и контроль ошибок. В соответствии со схемой кодирования 8B/10B блоки данных из 8 бит преобразуются в блоки данных из 10 бит. Эта схема была изначально разработана компанией IBM для ESCON и позволяет, в частности, обеспечить баланс напряжения постоянного тока.

Некодированная информация разбивается на блоки по 8 бит: A, B, C, D, E, F, G, H, плюс контрольная переменная Z (см. Рисунок 1). Последняя может принимать значение D в случае обычных символов данных (D-типа) или K в случае специальных символов (K-типа). Эта информация преобразуется в соответствии с правилами 8B/10B в так называемый передаваемый символ (Transmission Character) из 10 бит: a, b, c, d, e, i, f, g, h, j. Правила, в частности, предусматривают, что передаваемый символ D-типа должен содержать не менее четырех нулей и единиц, причем число идущих подряд нулей или единиц не должно быть больше четырех. Каждый имеющий смысл передаваемый символ имеет свое обозначение Zxx.y в соответствии со следующим соглашением: Z — контрольная переменная; xx — десятичное значение двоичного числа, составленного из битов E, D, C, B и A, а y — десятичное значение двоичного числа, составленного из битов H, G, F. Так, например, передаваемый символ для специального (т. е. К-типа) байта 10111100 обозначается как K28.5. Иногда он называется также запятой (comma).

Каждый байт данных или специальный символ имеет два (возможно, одинаковых) передаваемых кода, т. е. каждый передаваемый символ имеет два представления, в частности K28.5 может быть представлен и как десятибитовая последовательность 0011111010, и как 1100000101. Какое из двух возможных представлений будет выбрано для передачи, зависит от значения «текущего дисбаланса» (Running Disparity, RD). Двоичный параметр RD вычисляется на основании баланса 0 и 1 в подблоках передаваемого символа. 1 соответствует сигналу с большей оптической мощностью (для оптических каналов) или сигналу с большим напряжением на контакте +, чем на контакте — (в случае медных линий). Текущий дисбаланс вычисляется после первых шести битов каждого передаваемого символа и затем после последних четырех его битов. Дисбаланс может быть положительным (больше единиц, чем нулей) или отрицательным (больше нулей, чем единиц). Такая схема призвана обеспечить равенство нулей и единиц с течением времени.

Всевозможных 10-битовых комбинаций больше, чем реально используется для представления 256 обычных символов. Таким образом, при получении 10-битовой последовательности битов, не соответствующей ни D-типу, ни K-типу, получатель сигнализирует об ошибке кодирования. Кроме того, как отправитель, так и получатель вычисляют новое значение текущего дисбаланса. Если полученный символ имеет отличное от ожидаемого значение дисбаланса (которое получатель определяет на основании предыдущего значения), то получатель сигнализирует об ошибке дисбаланса. Такой подход позволяет реализовать контроль ошибок. Вообще же, вероятность возникновения ошибки при передаче данных составляет ничтожную величину 10-12.

АРБИТРАЖ ДОСТУПА

В отличие от двух других топологий Fibre Channel, в случае петли с арбитражем доступа входящие в нее устройства вынуждены конкурировать друг с другом за доступ к среде передачи. Право передачи предоставляется тому из них, кто выиграет процедуру арбитража. Арбитраж осуществляется следующим образом.

При наличии данных для передачи устройство должно вначале получить контроль над петлей. Для этого оно передает кодовое слово — примитив арбитража ARBx (Arbitrate Primitive Signal), где x соответствует физическому адресу (Arbitrated Loop Physical Address, AL_PA). Если примитив ARBx возвращается обратно, то устройство получает контроль над петлей, после чего оно может передать адресату примитив открытия соединения (Open Primitive Signal, OPN). После этого два устройства взаимодействуют фактически напрямую. Все остальные устройства между ними служат лишь пассивными повторителями передаваемых данных.

Если же доступ к петле хотят получить одновременно несколько устройств, то тогда они сравнивают содержащийся в примитиве ARB адрес со своими собственными. Если участвующее в арбитраже устройство имеет больший адрес, то оно передает полученный примитив дальше без изменений; если же оно имеет меньший адрес, то полученный примитив изымается из обращения, и это устройство передает примитив со своим адресом. Таким образом, арбитраж выигрывает устройство с наименьшим адресом. Получившее контроль над петлей устройство может сохранять его неограниченно долго. Правда, стандарт предусматривает алгоритм обеспечения справедливого доступа (Access Fairness Algorithm), в соответствии с которым устройство не имеет права повторно участвовать в арбитраже, пока всем остальным устройствам не будет предоставлена возможность установить контроль над петлей. К сожалению, реализация этого алгоритма не является обязательной.

ИНИЦИАЛИЗАЦИЯ ПЕТЛИ

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

Адрес AL_PA записывается в младший байт трехбайтного идентификатора адреса (Native Address Identifier, S_ID для отправителя и D_ID для получателя). Однако, в целях соблюдения баланса нулей и единиц, адрес AL_PA может в действительности принимать только 127 разных значений. В случае, если петля связывает более 127 устройств, некоторым из них адреса не достанется, и они будут переведены в пассивный режим (Nonparticipating Mode). В этом режиме устройство только повторяет передаваемые по петле слова. Если петля является автономной, т. е. не подключена к коммутатору, то первые два байта идентификатора остаются пустыми.

Процедура инициализации петли состоит из трех этапов и начинается с передачи примитива инициализации петли (Loop Initialization Primitive, LIP). При включении питания порт передает LIP и тем самым инициирует передачу этого примитива всеми остальными портами. Далее устройства в петле должны выбрать главного (master) для контроля за процессом выбора адресов. Когда петля подключена к коммутатору, главным назначается порт коммутатора; в противном случае главным выбирается порт с наименьшим именем (Port_Name). Наконец, порты выбирают себе адреса в соответствии со следующими приоритетами: назначенный коммутатором, используемый при предыдущей инициализации, запрограммированный производителем, свободный из оставшихся. В конце выбранный главным порт передает примитив CLS о завершении процедуры инициализации.

АДРЕСАЦИЯ

В отличие от многих других технологий локальных сетей, где используется фиксированный MAC-адрес длиной 6 байт, Fibre Channel использует динамически назначаемые при регистрации адреса — так называемые адресные идентификаторы. Адреса в диапазоне от FFFFF0 до FFFFFE (здесь и далее в этом разделе в шестнадцатеричном представлении) закреплены за определенными адресатами — коммутирующей структурой (Fabric), сервером многоадресной рассылки (Multicast Server) и т. д. Адрес FFFFFF зарезервирован для широковещательной рассылки. Адреса назначаются при регистрации в коммутирующей структуре. До регистрации идентификатор адреса не определен и равен 000000.

Как было описано в предыдущем разделе, устройства в петле используют однобайтные физические адреса AL_PA. После завершения инициализации петли и получения адресов AL_PA общедоступные порты типа NL_Port предпринимают попытку зарегистрироваться в коммутирующей структуре, в частности, для получения адресного идентификатора. При этом обычно адрес AL_PA оставляется без изменений и помещает в младший из трех байт адресного идентификатора.

Однако, чтобы инициализация и регистрация вообще были возможны, т. е. чтобы можно было назначить адресные идентификаторы, порты необходимо каким-то образом идентифицировать. Это достигается за счет использования фиксированных именных идентификаторов (Name_Identifier). Именные идентификаторы служат для идентификации портов (Port_Name), узлов (Node_Name) и коммутаторов (Fabric_Name).

КОНТРОЛЬ ПОТОКОВ

Применяемый на уровне FC-2 контроль потоков позволяет согласовать скорость отправки кадров с возможностями коммутирующей структуры и конечных устройств-получателей по их обработке. Лежащая в основе идея достаточно проста: устройство может передавать кадры, только когда другое устройство готово их принять.

В соответствии с правилами Fibre Channel, при установлении соединения между ними устройства должны пройти взаимную регистрацию (login). Одним из результатов регистрации является открытие кредитов. Кредит — это количество кадров, которое отправитель может передать без получения подтверждения об их обработке. Fibre Channel использует два типа контроля потоков: межбуферный (buffer-to-buffer) и сквозной (end-to-end). Какой из механизмов применяется в каждом конкретном случае, зависит от сервисного класса (о сервисных классах см. статью «Fibre Channel» в предыдущем номере LAN). Сквозной контроль потоков используется в случае Класса 1, а межбуферный контроль потоков — для Класса 3; в случае Класса 2 применяются оба типа контроля потоков.

Межбуферный контроль потоков осуществляется по обоим концам прямого канала между узловым портом N_Port и коммутирующим портом F_Port или между двумя узловыми портами N_Port в двухточечной конфигурации. Порты с обеих сторон канала обмениваются друг с другом значениями числа кадров BB_Credit, которые каждый из них готов принять. Например, порт A готов принять X кадров, а порт B — Y кадров. Таким образом, BB_Credit для порта A устанавливается равным Y, а для порта B он будет равным X. Эти значения кредитов остаются неизменными на протяжении всего срока регистрации.

Каждый порт ведет учет числа отправленных им кадров, подтверждение о принятии которых не было получено. Первоначальное значение этого счетчика BB_Credit_CNT устанавливается равным 0 и с каждым отправленным кадром увеличивается на 1. При получении примитива о готовности получателя к приему (Receiver_Ready Primitive Signal, R_RDY) значение счетчика уменьшается на 1. Сигнал R_RDY означает, что получатель обработал кадр, освободил место в буфере и готов к приему следующего кадра. При достижении BB_Credit_CNT значения, равного BB_Credit, передача приостанавливается до получения R_RDY.

Процедура сквозного контроля во многом аналогична вышеописанной, за одним существенным исключением: скорость обмена согласуется двумя конечными устройствами. Как и в предыдущем случае, два взаимодействующих устройства согласуют во время регистрации размер буферов приема EE_Credit. При передаче каждого кадра значение счетчика EE_Credit_CNT увеличивается на 1. При получении кадра с подтверждением (ACK Link Control) значение счетчика уменьшается на указанную в подтверждении величину (кадры ACK позволяют подтвердить получение очередного кадра, нескольких кадров или всей последовательности кадров).

СИНТАКСИЧЕСКАЯ СТРУКТУРА

Вся информация в Fibre Channel передается блоками по четыре передаваемых символа. Эти блоки называются передаваемыми словами (Transmission Word). Начинающиеся с символа K28.5 слова являются служебными (Ordered Set). Сигнальный протокол определяет три типа служебных слов.

Ограничители начала и конца кадра (Start-Of-Frame, SOF и End-Of-Frame, EOF) определяют границы кадра. Отдельные примитивы (Primitive Signal) Idle и Receiver Ready сигнализируют, соответственно, о состоянии готовности порта к приему/передаче и о наличии места в буфере для приема последующих кадров. Последовательности примитивов (Primitive Sequence) Not Operational (NOS), Link Reset (LR) и т. п. представляют собой повторяющиеся служебные слова (не менее 3 раз подряд) и сигнализируют о специфическом состоянии порта.

Риcунок 2. Структура кадра и заголовка кадра Fibre Channel.

В свою очередь, при передаче слова (за исключением примитивов) объединяются в кадры (см. Рисунок 2). Кадр начинается с ограничителя начала кадра SOF. За ним следует заголовок кадра длиной в шесть слов, где, в частности, указывается адреса получателя и отправителя. Основное содержимое кадра представляет полезная нагрузка (в принципе, она может и отсутствовать). Поле полезной нагрузки может также содержать вспомогательный заголовок. Завершается кадр контрольной последовательностью CRC и еще одним служебным словом EOF. Таким образом, длина кадра варьируется от 9 слов (36 10-битных байт) до 537 слов (2148 байт) при максимальной полезной нагрузке. Именно кадрами оперирует коммутирующая структура.

Каждый кадр может содержать самодостаточную информацию (например, команду SCSI) или же разбитую для удобства передачи часть целостного информационного массива (например, файла). Такой логически составляющий единое целое блок данных называется последовательностью (Sequence), или, в традиционной терминологии, пакетом. Каждая последовательность идентифицируется с помощью идентификатора Seq_ID в заголовке кадра, а положение кадра в последовательности — с помощью его порядкового номера Seq_Cnt. Таким образом, получатель способен восстановить правильную последовательность кадров, даже если они прибудут в ином порядке по сравнению с тем, в каком были отправлены.

Взаимодействие между приложениями происходит в контексте обмена или сеанса (exchange) между инициатором (originator) и реципиентом (responder). При передаче первого кадра инициатор присваивает данному диалогу номер OX_ID, этот идентификатор затем будет указываться во всех передаваемых реципиентом кадрах в качестве Exchange_ID. В свою очередь, в первом ответном кадре реципиент указывает номер RX_ID, который он присвоил данному обмену, этот идентификатор также будет затем указываться во всех передаваемых инициатором кадрах. Таким образом, и получатель, и отправитель могут однозначно определить, какому именно высокоуровневому протоколу или приложению им следует передать полученные данные.

НА ВСЕ СЛУЧАИ

Технология Fibre Channel находит себе многочисленные применения, в том числе в кластерах и сетях устройств хранения (Storage Area Network, SAN). Основные области применения Fibre Channel мы рассмотрим в следующем номере.

Дмитрий Ганьжа — ответственный редактор LAN. С ним можно связаться по адресу: [email protected].

Поделитесь материалом с коллегами и друзьями

Реферат utf-16

скачать

Реферат на тему:

UTF-16 (англ. Unicode Transformation Format) в информатике — один из способов кодирования символов из Unicode в виде последовательности 16-битных слов. Символы с кодами 0x0000..0xD7FF и 0xE000..0xFFFF представляются одним 16-битным словом, а символы с кодами 0x10000—0x10FFFF — в виде последовательности двух 16-битных слов. Количество символов, представляемых двумя 16-битными словами равно (2²⁰). Для представления символов с кодами 0x10000—0x10FFFF используется матрица перекодировки. Первое слово из двух переданных лежит в диапазоне 0xD800–0xDBFF, а второе — 0xDC00—0xDFFF. Именно этот диапазон значений не может встречаться среди символов, передаваемых с помощью одного 16-битного слова, так что расшифровка кодировки всегда однозначна. Ясно, что имеется как раз 2¹⁰ * 2¹⁰ = 2²⁰ таких комбинаций.

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

Впрочем, в подавляющем большинстве случаев текст в UTF-16 является просто последовательностью символов из UCS-2 (BMP), т.к. символы Unicode после кода 0x10000 используются крайне редко.

История появления

Первая версия Юникода (1991 г.) представляла собой 16-битную кодировку с фиксированной шириной символа; общее число разных символов было 2¹⁶ (65 536). Во второй версии Юникода (1996 г.) было решено значительно расширить кодовую область; для сохранения совместимости с теми системами, где уже был реализован 16-битный Юникод, и была создана UTF-16. Область 0xD800—0xDFFF, отведённая для суррогатных пар, ранее принадлежала к области «символов для частного использования».

Поскольку в UTF-16 можно отобразить 2²⁰+2¹⁶ — 2048 (1 112 064) символов, то это число и было выбрано в качестве новой величины кодового пространства Юникода.

Порядок байт

Один символ кодировки UTF-16 представлен последовательностью двух байтов. Который из двух идёт впереди, старший или младший, зависит от порядка байтов. Систему, совместимую с процессорами x86, называют little endian, а с процессорами m68k и SPARC — big endian.

Для определения порядка байтов используется метка порядка байтов (англ. Byte order mark). В начале текста записывается код U+FEFF. При считывании, если вместо U+FEFF считалось U+FFFE, значит порядок байтов обратный, поскольку символа с кодом и U+FFFE в Юникоде нет. Так как в кодировке UTF-8 не используются значения 0xFE и 0xFF, можно использовать метку порядка байтов как признак, позволяющий различать UTF-16 и UTF-8.

UTF-16LE и UTF-16ВE

Предусмотрена также возможность внешнего указания порядка байтов — для этого кодировка должна быть описана как UTF-16LE или UTF-16ВE (little-endian / big-endian), а не просто UTF-16. В этом случае метка порядка байтов (U+FEFF) не нужна.

UTF-16 в ОС Windows

В API Win32, распространённом в современных версиях операционной системы Microsoft Windows, имеется два способа представления текста: в форме традиционных 8-битных кодовых страниц и в виде UTF-16.

В файловых системах NTFS, а также FAT с поддержкой длинных имён, имена файлов записываются в UTF-16LE.

UTF-16 в сотовой связи

Именно эта кодировка используется для передачи текстовых сообщений, написанных кирилическими символами в сотовых сетях. Это объясняет уменьшение длины сообщения при переходе с использования только латинских букв на кирилические со 140 символов в сообщении до 70.

RFC 3629 | UTF-8, формат преобразования ISO 10646

Аннотация

ISO/IEC 10646-1 определяет большой набор символов, называемый универсальным набором символов (UCS), который охватывает большинство систем письменности мира. Однако первоначально предложенные кодировки UCS были несовместимы со многими современными приложениями и протоколами, и это привело к разработке UTF-8, объекта этой заметки. UTF-8 обладает характеристиками сохранения полного диапазона US-ASCII, обеспечивая совместимость с файловыми системами, синтаксическими анализаторами и другим программным обеспечением, которые полагаются на значения US-ASCII, но прозрачны для других значений. Эта памятка устаревает и заменяет RFC 2279.

Скачать оригинальный документ на английском языке RFC 3629 PDF

1. Введение
2. Условные обозначения
3. Определение UTF-8
4. Синтаксис байтовых последовательностей UTF-8
5. Версии стандартов
6. Порядок следования байтов (BOM)
7. Примеры
8. Регистрация MIME
9. Соображения IANA
10. Вопросы безопасности
11. Благодарности
12. Отличия от RFC 2279
13. Нормативные документы
14. Информационные ссылки
15. URI
16. Заявление об интеллектуальной собственности
17. Адрес автора
18. Полная информация об авторских правах

Статус этой заметки

Этот документ определяет протокол отслеживания стандартов Интернета для интернет-сообщества и запрашивает обсуждение и предложения по улучшению. Пожалуйста, обратитесь к текущей редакции «Официальных стандартов протокола Интернета» (STD 1) для ознакомления с состоянием стандартизации и статусом этого протокола. Распространение этой заметки не ограничено.

Уведомление об авторских правах

1. Введение

ISO/IEC 10646 [ISO.10646] определяет большой набор символов, называемый универсальным набором символов (UCS), который охватывает большинство мировых систем письма. Тот же набор символов определяется стандартом Unicode [UNICODE], который дополнительно определяет свойства символов и другие детали приложения, представляющие большой интерес для разработчиков. До настоящего времени изменения в Юникоде, а также изменения и дополнения в ИСО / МЭК 10646 отслеживали друг друга, так что репертуары символов и назначения кодовых точек оставались синхронизированными. Соответствующие комитеты по стандартизации обязались поддерживать этот очень полезный синхронизм.

ИСО / МЭК 10646 и Unicode определяют несколько форм кодирования их общего репертуара: UTF-8, UCS-2, UTF-16, UCS-4 и UTF-32. В форме кодирования каждый символ представлен как одна или несколько единиц кодирования. Все стандартные формы кодирования UCS, кроме UTF-8, имеют единицу кодирования, превышающую один октет, что затрудняет их использование во многих современных приложениях и протоколах, которые принимают 8 или даже 7-битные символы.

UTF-8, объект этой заметки, имеет одно-октетный блок кодирования. Он использует все биты октета, но обладает качеством сохранения полного диапазона US-ASCII [US-ASCII]: символы US-ASCII кодируются в одном октете, имеющем нормальное значение US-ASCII, и любой октет с таким значением может означать только символ США-ASCII и ничего больше.

UTF-8 кодирует символы UCS как переменное количество октетов, где количество октетов и значение каждого из них зависят от целочисленного значения, назначенного символу в ISO / IEC 10646 (номер символа, или кодовая позиция, кодовая точка или скалярное значение Unicode). Эта форма кодирования имеет следующие характеристики (все значения указаны в шестнадцатеричном формате):

Символьные числа от U+0000 до U+007F (репертуар US-ASCII) соответствуют октетам от 00 до 7F (7-битные значения US-ASCII). Прямым следствием является то, что простая строка ASCII также является допустимой строкой UTF-8.
Значения октетов US-ASCII не появляются иначе в потоке символов в кодировке UTF-8. Это обеспечивает совместимость с файловыми системами или другим программным обеспечением (например, функцией printf () в библиотеках C), которые анализируют на основе значений US-ASCII, но прозрачны для других значений.
Обратное преобразование легко между UTF-8 и другими формами кодирования.
Первый октет много-октетной последовательности указывает количество октетов в последовательности.
Значения октетов C0, C1, F5-FF никогда не появляются.
Границы символов легко найти из любого места в потоке октетов.
Лексикографическая сортировка байтового значения строк UTF-8 такая же, как если бы они были упорядочены по символьным номерам. Конечно, это представляет ограниченный интерес, так как порядок сортировки, основанный на числах символов, почти никогда не является культурно действительным.
Алгоритм быстрого поиска Бойера-Мура можно использовать с данными UTF-8.
Строки UTF-8 могут быть достаточно надежно распознаны как таковые с помощью простого алгоритма, то есть вероятность того, что строка символов в любой другой кодировке появится в качестве действительного UTF-8, мала и уменьшается с увеличением длины строки.

UTF-8 был разработан в сентябре 1992 года Кеном Томпсоном (Ken Thompson), руководствуясь критериями проектирования, указанными Робом Пайком (Rob Pike), с целью определения формата преобразования UCS, который можно использовать в операционной системе Plan9 без прерывания работы. Дизайн Томпсона был изменен посредством стандартизации X / Open Joint Internationalization Group XOJIG (см. [FSS_UTF]), носящей имена FSS-UTF (вариант FSS / UTF), UTF-2 и, наконец, UTF-8.

2. Условные обозначения

Ключевые слова «ОБЯЗАН», «НЕ ОБЯЗАН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «ВОЗМОЖЕН» и «ДОПОЛНИТЕЛЬНО» в этом документе интерпретироваться как описано в [RFC2119].

Символы UCS обозначаются обозначением U+HHHH, где HHHH — строка из 4–6 шестнадцатеричных цифр, представляющих номер символа в ИСО / МЭК 10646.

3. Определение UTF-8

UTF-8 определяется стандартом Unicode [UNICODE]. Описания и формулы также можно найти в Приложении D к ISO / IEC 10646-1 [ISO.10646]

В UTF-8 символы из диапазона U+0000..U+10FFFF (доступный диапазон UTF-16) кодируются с использованием последовательностей от 1 до 4 октетов. Единственный октет «последовательности» из одного имеет бит высшего порядка, установленный в 0, остальные 7 бит используются для кодирования номера символа. В последовательности из n октетов, n> 1, исходный октет имеет n битов старшего порядка, установленных на 1, за которыми следует бит, установленный на 0. Остальные биты этого октета содержат биты из числа символов быть закодированным. Все последующие октеты имеют бит высшего порядка, установленный на 1, и следующий бит, установленный на 0, оставляя по 6 бит в каждом, чтобы содержать биты из символа, подлежащего кодированию.

Таблица ниже суммирует формат этих различных типов октетов. Буква «x» указывает биты, доступные для кодирования битов номера символа.

Таблица сумм различных типов октетов

Кодирование символа в UTF-8 происходит следующим образом:

Определите количество октетов, необходимое из номера символа и первого столбца таблицы выше. Важно отметить, что строки таблицы являются взаимоисключающими, то есть существует только один допустимый способ кодирования данного символа.
Подготовьте старшие биты октетов согласно второму столбцу таблицы.
Заполните биты, помеченные символом x, из битов номера символа, выраженного в двоичном формате. Начните с помещения бита младшего разряда номера символа в позицию младшего разряда последнего октета последовательности, затем поместите следующий бит старшего порядка номера символа в следующую позицию старшего порядка этого октета и т. д.. Когда биты x последнего октета заполнены, переходите к следующему последнему октету, затем к предыдущему и т. Д., Пока не будут заполнены все биты x.

Определение UTF-8 запрещает кодирование номеров символов между U+D800 и U+DFFF, которые зарезервированы для использования с формой кодирования UTF-16 (в качестве суррогатных пар) и не представляют непосредственно символы. При кодировании в UTF-8 из данных UTF-16 необходимо сначала декодировать данные UTF-16 для получения номеров символов, которые затем кодируются в UTF-8, как описано выше. Это отличается от CESU-8 [CESU-8], который представляет собой UTF-8-подобную кодировку, которая не предназначена для использования в Интернете. CESU-8 работает аналогично UTF-8, но кодирует значения кода UTF-16 (16-разрядные величины) вместо номера символа (кодовая точка). Это приводит к разным результатам для чисел выше 0xFFFF; кодировка этих символов CESU-8 НЕ является допустимой UTF-8.

Декодирование символа UTF-8 происходит следующим образом:

Инициализируйте двоичное число со всеми битами, установленными в 0. Может потребоваться до 21 бита.
Определите, какие биты кодируют номер символа, исходя из количества октетов в последовательности и второго столбца таблицы выше (биты отмечены значком x).
Распределите биты из последовательности в двоичное число, сначала младшие биты из последнего октета последовательности и продолжайте влево, пока не останется ни одного x бит. Двоичное число теперь равно номеру символа.

Реализации вышеописанного алгоритма декодирования ДОЛЖНЫ защищать от декодирования недопустимых последовательностей. Например, наивная реализация может декодировать слишком длинную последовательность C0 80 UTF-8 в символ U + 0000 или суррогатную пару ED A1 8C ED BE B4 в U+233B4. Декодирование недопустимых последовательностей может иметь последствия для безопасности или вызывать другие проблемы. См. Вопросы безопасности (раздел 10) ниже.

4. Синтаксис байтовых последовательностей UTF-8

Для удобства разработчиков, использующих ABNF, здесь дано определение UTF-8 в синтаксисе ABNF.

Строка UTF-8 — это последовательность октетов, представляющая последовательность символов UCS. Последовательность октетов действительна для UTF-8, только если она соответствует следующему синтаксису, который получен из правил для кодирования UTF-8 и выражен в ABNF из [RFC2234].

UTF8-octets = *( UTF8-char )
UTF8-char = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1 = %x00-7F
UTF8-2 = %xC2-DF UTF8-tail

UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) / %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF

ПРИМЕЧАНИЕ. — Официальное определение UTF-8 содержится в [UNICODE]. Считается, что эта грамматика описывает то же самое, что описывает Unicode, но не претендует на авторитетность. Разработчикам настоятельно рекомендуется полагаться на авторитетный источник, а не на эту ABNF.

5. Версии стандартов

ИСО / МЭК 10646 время от времени обновляется публикацией поправок и дополнительных частей; аналогично, новые версии стандарта Unicode публикуются с течением времени. Каждая новая версия устаревает и заменяет предыдущую, но реализации и, что более важно, данные не обновляются мгновенно.

В целом, изменения сводятся к добавлению новых символов, что не создает особых проблем со старыми данными. В 1996 году поправка 5 к изданию 1993 года ISO / IEC 10646 и Unicode 2.0 переместила и расширила корейский блок хангыль, сделав тем самым все предыдущие данные, содержащие символы хангыль, недопустимыми в новой версии. Unicode 2.0 имеет такое же отличие от Unicode 1.1. Оправданием для разрешения такого несовместимого изменения было то, что не было крупных реализаций и не было значительного количества данных, содержащих хангыль. Инцидент был назван «корейским беспорядком», и соответствующие комитеты обязались никогда и никогда не вносить такое несовместимое изменение (см. Политику консорциума Unicode [1]).

Новые версии и, в частности, любые несовместимые изменения, имеют последствия в отношении меток кодировки MIME, которые будут обсуждаться при регистрации в MIME (раздел 8).

6. Порядок следования байтов (BOM)

Символ UCS U + FEFF «ZERO WIDTH NO-BREAK SPACE» также неофициально известен как «BYTE ORDER MARK» (сокращенно «BOM»). Этот символ может использоваться как подлинный «НУЛЕВОЙ ПРОБЕЛ ZERO WIDTH» в тексте, но имя спецификации указывает на второе возможное использование символа: для добавления символа U+FEFF к потоку символов UCS в качестве «подписи» ». Приемник такого сериализованного потока может затем использовать начальный символ в качестве подсказки о том, что поток состоит из символов UCS, а также для распознавания, какое кодирование UCS задействовано, и, с кодировками, имеющими многооктетный блок кодирования, в качестве способа распознавания порядок сериализации октетов. UTF-8, имеющий однооктетный блок кодирования, эта последняя функция бесполезна, и спецификация всегда будет отображаться как последовательность октетов EF BB BF.

Важно понимать, что символ U+FEFF, появляющийся в любой позиции, отличной от начала потока, ДОЛЖЕН интерпретироваться с семантикой для неразрывного пробела нулевой ширины и НЕ ДОЛЖЕН интерпретироваться как сигнатура. Когда интерпретируется как подпись, стандарт Unicode предполагает, что начальный символ U+FEFF может быть удален перед обработкой текста. Такое удаление необходимо в некоторых случаях (например, при объединении двух строк, потому что в противном случае результирующая строка может содержать непреднамеренное «НУЛЕВОЙ ПРОБЕЛ ЗУРА» в точке соединения), но может повлиять на внешний процесс на другом уровне (например, в виде цифровой подписи или числа символов), которая зависит от наличия всех символов в потоке. Поэтому РЕКОМЕНДУЕТСЯ избегать удаления начального U+FEFF, интерпретируемого как подпись без веской причины, игнорировать его вместо удаления, когда это необходимо (например, для отображения), и удалять его только тогда, когда это действительно необходимо.

U+FEFF в первой позиции потока МОЖЕТ интерпретироваться как неразрывный пробел нулевой ширины и не всегда является сигнатурой. В попытке уменьшить эту неопределенность, Unicode 3.2 добавляет новый символ, U+2060 «WORD JOINER», с точно такой же семантикой и использованием, что и U+FEFF, за исключением функции подписи, и настоятельно рекомендует использовать ее исключительно для выражения word- присоединяющаяся семантика. В конце концов, следуя этой рекомендации, можно с уверенностью сказать, что любой начальный U+FEFF является подписью, а не предполагаемым «нулевым пространством без разрывов».

Между тем, к сожалению, неопределенность сохраняется и может повлиять на интернет-протоколы. Спецификации протокола МОГУТ ограничивать использование U + FEFF в качестве сигнатуры, чтобы уменьшить или устранить потенциальные вредные последствия этой неопределенности. В интересах установления баланса между преимуществами (уменьшение неопределенности) и недостатками (потеря функции сигнатуры) таких ограничений полезно выделить несколько случаев:

Протоколу СЛЕДУЕТ запрещать использование U+FEFF в качестве подписи для тех текстовых элементов протокола, которые протокол обязывает всегда быть UTF-8, причем функция подписи в этих случаях полностью бесполезна.
Протоколу СЛЕДУЕТ также запретить использование U+FEFF в качестве сигнатуры для тех элементов текстового протокола, для которых протокол предоставляет механизмы идентификации кодировки символов, когда ожидается, что реализации протокола будут в состоянии всегда использовать механизмы должным образом. Это будет иметь место, когда элементы протокола поддерживаются под строгим контролем реализации от времени их создания до времени их (должным образом маркированных) передачи.
Протоколу НЕ СЛЕДУЕТ запрещать использование U+FEFF в качестве сигнатуры для тех элементов текстового протокола, для которых протокол не обеспечивает механизмы идентификации кодировки символов, когда запрет будет неосуществимым или когда ожидается, что реализации протокола не будут в состоянии всегда использовать механизмы должным образом. Последние два случая могут возникать с более крупными протокольными элементами, такими как объекты MIME, особенно когда реализации протокола будут получать такие объекты из файловых систем, из протоколов, которые не имеют механизмов идентификации кодирования для полезных нагрузок (таких как FTP) или из других протоколы, которые не гарантируют правильную идентификацию кодировки символов (например, HTTP).

Когда протокол запрещает использование U+FEFF в качестве сигнатуры для определенного элемента протокола, то любой начальный U+FEFF в этом элементе протокола ДОЛЖЕН интерпретироваться как «НУЛЕВОЙ ПРОБЕЛ ЗУРА». Когда протокол НЕ запрещает использование U+FEFF в качестве сигнатуры для определенного элемента протокола, тогда реализации ДОЛЖНЫ быть готовы обработать сигнатуру в этом элементе и реагировать соответствующим образом: используя сигнатуру для идентификации кодировки символов по мере необходимости и удаления или игнорирования подпись при необходимости.

7. Примеры

Последовательность символов U+0041 U+2262 U+0391 U+002E «A<NOT IDENTICAL TO><ALPHA> (A <НЕ ИДЕНТИЧНО ДЛЯ> <ALPHA>).» кодируется в UTF-8 следующим образом:

—+———-+——+—
41 E2 89 A2 CE 91 2E
—+———-+——+—

Последовательность символов U+D55C U+AD6D U+C5B4 (корейский «hangugeo», что означает «корейский язык») кодируется в UTF-8 следующим образом:

————+————+———
ED 95 9C EA B5 AD EC 96 B4
————+————+———

Последовательность символов U+65E5 U+672C U+8A9E (японское «nihongo», что означает «японский язык») кодируется в UTF-8 следующим образом:

———-+————+———-
E6 97 A5 E6 9C AC E8 AA 9E
———-+————+———-

Символ U+233B4 (китайский символ, означающий «пень дерева — stump of tree»), которому предшествует спецификация UTF-8, кодируется в UTF-8 следующим образом:

————+—————
EF BB BF F0 A3 8E B4
————+—————

8. Регистрация MIME

Эта памятка служит основой для регистрации параметра кодировки MIME для UTF-8, в соответствии с [RFC2978]. Значение параметра charset — «UTF-8». Эта строка обозначает типы мультимедиа, содержащие текст, состоящий из символов из репертуара ИСО / МЭК 10646, включая все поправки, по крайней мере, до поправки 5 издания 1993 года (корейский блок), закодированные в последовательность октетов с использованием схемы кодирования, описанной выше. UTF-8 подходит для использования в типах контента MIME с типом верхнего уровня text.

Следует отметить, что метка «UTF-8» не содержит идентификацию версии, что в целом относится к ИСО / МЭК 10646. Это сделано намеренно, обоснование таково:

Метка кодировки MIME предназначена для предоставления только той информации, которая необходима для интерпретации последовательности байтов, полученных на проводе, в последовательность символов, не более того (см. [RFC2045], раздел 2.2). Пока стандарт набора символов не изменяется несовместимо, номера версий не имеют смысла, потому что человек ничего не получает, узнав из тега, что могут быть получены новые назначенные символы, о которых он не знает. Сам тег ничего не рассказывает о новых персонажах, которые все равно будут получены.

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

Теперь «корейский беспорядок» (поправка 5 к ISO / IEC 10646) является несовместимым изменением, в принципе противоречащим уместности независимой от версии метки кодировки MIME, как описано выше. Но проблема совместимости может появиться только с данными, содержащими корейские символы хангыль, закодированные в соответствии с Unicode 1.1 (или эквивалентно ISO / IEC 10646 до исправления 5), и, возможно, таких данных не о чем беспокоиться, это и есть причина, по которой произошло несовместимое изменение. считается приемлемым.

Таким образом, на практике гарантируется независимая от версии метка, при условии, что метка понимается как относящаяся ко всем версиям после Поправки 5, и при условии, что на самом деле не происходит несовместимых изменений. Если в более поздней версии ISO / IEC 10646 произойдут несовместимые изменения, метка кодировки MIME, определенная здесь, будет оставаться в соответствии с предыдущей версией до тех пор, пока IETF не примет иного решения.

9. Соображения IANA

Запись для UTF-8 в реестре кодировок IANA была обновлена, чтобы указывать на эту заметку.

10. Вопросы безопасности

Разработчики UTF-8 должны учитывать аспекты безопасности того, как они обрабатывают недопустимые последовательности UTF-8. Возможно, что в некоторых обстоятельствах злоумышленник сможет использовать неосторожный синтаксический анализатор UTF-8, отправив ему последовательность октетов, которая не разрешена синтаксисом UTF-8.

Особенно тонкая форма этой атаки может быть выполнена против синтаксического анализатора, который выполняет критические для безопасности проверки достоверности по отношению к форме своего ввода в кодировке UTF-8, но интерпретирует некоторые недопустимые последовательности октетов как символы. Например, синтаксический анализатор может запретить символ NUL при кодировании как однооктетную последовательность 00, но ошибочно разрешить недопустимую двухоктетную последовательность C0 80 и интерпретировать его как символ NUL. Другим примером может быть синтаксический анализатор, который запрещает последовательность октетов 2F 2E 2E 2F («/../»), но разрешает недопустимую последовательность октетов 2F C0 AE 2E 2F. Этот последний эксплойт фактически использовался на широко распространенных вирус-атакующих веб-серверах в 2001 году; Таким образом, угроза безопасности очень реальна.

Другая проблема безопасности возникает при кодировании в UTF-8: описание UTF-8 в стандарте ISO / IEC 10646 позволяет кодировать номера символов до U+7FFFFFFF, получая последовательности длиной до 6 байтов. Следовательно, существует риск переполнения буфера, если диапазон числовых значений не ограничен явно U+10FFFF или если размер буфера не учитывает возможность 5- и 6-байтовых последовательностей.

На безопасность также может влиять характеристика нескольких кодировок символов, включая UTF-8: «одно и то же» (насколько может судить пользователь) может быть представлено несколькими различными последовательностями символов. Например, e с острым акцентом может быть представлен предварительно составленным символом U + 00E9 E ACUTE или канонически эквивалентной последовательностью U + 0065 U + 0301 (E + COMBINING ACUTE). Даже несмотря на то, что UTF-8 предоставляет одну последовательность байтов для каждой последовательности символов, наличие нескольких последовательностей символов для «одной и той же вещи» может иметь последствия для безопасности всякий раз, когда участвуют сопоставление строк, индексация, поиск, сортировка, сопоставление и выбор регулярных выражений. Примером может служить сопоставление строк идентификатора, появляющегося в учетных данных и в записях списка управления доступом. Эта проблема поддается решениям, основанным на формах нормализации Unicode, см. [UAX15].

11. Благодарности

Следующие участники участвовали в составлении и обсуждении этого меморандума: Джеймс Э. Агенброуд, Харальд Альвестранд, Андриес Брауэр, Марк Дэвис, Мартин Дж. Дюрст, Патрик Фальтстром, Нед Фрид, Дэвид Голдсмит, Тони Хансен, Эдвин Ф. Харт, Пол Хоффман, Дэвид Хопвуд, Саймон Йозефссон, Кент Карлссон, Дэн Кон, Маркус Кун, Майкл Кунг, Ален ЛаБонте, Ира Макдональд, Алексей Мельников, Мурата Макото, Джон Гардинер Майерс, Крис Ньюман, Дэн Оскарссон, Роузбх Пурнадер, Мюррей Сарджент, Маркус Шерер Келд Симонсен, Арнольд Винклер, Кеннет Уистлер и Миша Вольф.

12. Отличия от RFC 2279

Ограничен диапазон символов до 0000-10FFFF (доступный диапазон UTF-16).
Сделал Unicode источником нормативного определения UTF-8, сохранив ISO / IEC 10646 в качестве ссылки для символов.
Выровнял терминологию. UTF-8 теперь описывается в терминах формы кодирования номера символа. UCS-2 и UCS-4 почти исчезли.
Превратил примечание, предупреждающее против декодирования недопустимых последовательностей в норматив, НЕ ДОЛЖЕН.
Добавлен новый раздел о спецификации UTF-8 с советами по протоколам.
Удалено предложено UNICODE-1-1-UTF-8 MIME регистрация кодировки.
Добавлен синтаксис ABNF для допустимых последовательностей октетов UTF-8
Расширенный раздел «Вопросы безопасности», в частности влияние нормализации Unicode

13. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[ISO.10646] International Organization for Standardization, «Information Technology — Universal Multiple-octet coded Character Set (UCS)», ISO/IEC Standard 10646, comprised
of ISO/IEC 10646-1:2000, «Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane», ISO/IEC 10646-2:2001, «Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes» and ISO/IEC 10646-1:2000/Amd 1:2002, «Mathematical symbols and other characters».

[UNICODE] The Unicode Consortium, «The Unicode Standard — Version 4.0», defined by The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1),
April 2003,

http://www.unicode.org/unicode/standard/versions/enumeratedversions.html#Unicode_4_0_0.

14. Информационные ссылки

[CESU-8] Phipps, T., «Unicode Technical Report #26: Compatibility Encoding Scheme for UTF-16: 8-Bit (CESU-8)», UTR 26, April 2002,

http://www.unicode.org/unicode/reports/tr26/.

[FSS_UTF] X/Open Company Ltd., «X/Open Preliminary Specification — File System Safe UCS Transformation Format (FSS-UTF)», May 1993,

http://wwwold.dkuug.dk/jtc1/sc22/wg20/docs/N193-FSS-UTF.pdf.

[RFC2045] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, November 1996.

[RFC2234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.

[RFC2978] Freed, N. and J. Postel, «IANA Charset Registration Procedures», BCP 19, RFC 2978, October 2000.

[UAX15] Davis, M. and M. Duerst, «Unicode Standard Annex #15: Unicode Normalization Forms», An integral part of The Unicode Standard, Version 4.0.0, April 2003,

http://www.unicode.org/unicode/reports/tr15.

[US-ASCII] American National Standards Institute, «Coded Character Set — 7-bit American Standard Code for Information Interchange», ANSI X3.4, 1986.

15. URI

[1] http://www.unicode.org/unicode/standard/policies.html

16. Заявление об интеллектуальной собственности

IETF не занимает никакой позиции относительно действительности или объема какой-либо интеллектуальной собственности или других прав, которые могут быть заявлены как относящиеся к внедрению или использованию технологии, описанной в этом документе, или степени, в которой любая лицензия в рамках таких прав может или не может быть имеется в наличии; это также не означает, что оно приложило какие-либо усилия для выявления таких прав. Информацию о процедурах IETF в отношении прав в документации по стандартам и соответствующей документации можно найти в BCP-11. Могут быть получены копии заявлений о правах, предоставленных для публикации, и любых гарантий лицензий, которые должны быть предоставлены, или в результате попытки получения общей лицензии или разрешения на использование таких прав собственности разработчиками или пользователями данной спецификации. из Секретариата IETF.

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

17. Адрес автора

Francois Yergeau
Alis Technologies
100, boul. Alexis-Nihon, bureau 600
Montreal, QC h5M 2P2
Canada

Phone: +1 514 747 2547
Fax: +1 514 747 2561
EMail: [email protected]

18. Полная информация об авторских правах

Этот документ и его переводы могут быть скопированы и предоставлены другим лицам, а производные работы, которые комментируют или иным образом объясняют его или помогают в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, полностью или частично, без каких-либо ограничений. при условии, что вышеупомянутое уведомление об авторских правах и этот параграф включены во все такие копии и производные работы. Однако сам этот документ не может быть изменен каким-либо образом, например, путем удаления уведомления об авторских правах или ссылок на Интернет-сообщество или другие интернет-организации, за исключением случаев, когда это необходимо для разработки стандартов Интернета, и в этом случае процедуры для авторских прав, определенные в необходимо придерживаться процесса интернет-стандартов или по мере необходимости переводить его на другие языки, кроме английского.

Предоставленные выше ограниченные разрешения являются бессрочными и не будут аннулированы Обществом Интернета или его правопреемниками или правопреемниками.

Этот документ и информация, содержащаяся в настоящем документе, предоставляются на условиях «КАК ЕСТЬ», и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖЕНЕРНАЯ ЗАДАЧА ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, НО ОГРАНИЧИВАЯСЬ, НИ ОДНОЙ ГАРАНТИИ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ ЗДЕСЬ НЕ БУДЕТ НАРУШИТЬ ЛЮБЫЕ ПРАВА ИЛИ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОГО ОБЕСПЕЧЕНИЯ ИЛИ ПРИГОДНОСТИ ДЛЯ ОСОБЫХ ЦЕЛЕЙ.

Подтверждение

Финансирование функции RFC Editor в настоящее время обеспечивается Обществом Интернета (Internet Society).

Поделись записью

16 — Infogalactic: ядро планетарного знания

UTF-16 (16-битный формат преобразования Unicode) — это кодировка символов, способная кодировать все 1112 064 возможных символа в Unicode. Кодирование имеет переменную длину, поскольку кодовые точки кодируются с помощью одной или двух 16-битных кодовых единиц . (также см. Сравнение кодировок Unicode для сравнения UTF-8, -16 и -32)

UTF-16, разработанный на основе более ранней 16-разрядной кодировки фиксированной ширины, известной как UCS-2 (для 2-байтового универсального набора символов), когда стало ясно, что двухбайтовая кодировка фиксированной ширины не может кодировать достаточно символов для быть действительно универсальным.

История

В конце 1980-х началась работа по разработке унифицированной кодировки для «универсального набора символов» (UCS), который заменит более ранние языковые кодировки единой скоординированной системой. Цель заключалась в том, чтобы включить все необходимые символы из большинства языков мира, а также символы из технических областей, таких как наука, математика и музыка. Первоначальная идея заключалась в том, чтобы расширить типичные 256-символьные кодировки, требующие 1 байт на символ, с помощью кодировки, использующей 2 ¹⁶ = 65 536 значений, требующих 2 байта на символ.Две группы работали над этим параллельно: IEEE и Консорциум Unicode, последний представлял в основном производителей компьютерного оборудования. Обе группы попытались синхронизировать свои назначения символов, чтобы развивающиеся кодировки были взаимно совместимы. Раннее двухбайтовое кодирование обычно называлось «Unicode», но теперь называется «UCS-2».

В начале этого процесса ^{[требуется цитирование ]}, однако, становилось все более очевидным, что 2 ¹⁶ символов недостаточно, и IEEE ввел большее 31-битное пространство с кодировкой (UCS-4), которая потребовала бы 4 байта на символ.Консорциум Unicode сопротивлялся этому как потому, что 4 байта на символ занимали много места на диске и памяти, так и потому, что некоторые производители уже вложили значительные средства в технологию 2 байта на символ. Схема кодирования UTF-16 была разработана как компромисс для разрешения этого тупика в версии 2.0 стандарта Unicode в июле 1996 г. ^[1] и полностью указана в RFC 2781, опубликованном в 2000 г. IETF. ^[2] ^[3] ^[4]

В UTF-16 кодовые точки больше или равные 2 ¹⁶ кодируются с использованием двух 16-битных кодовых единиц.Организации по стандартизации выбрали самый большой доступный блок из нераспределенных 16-битных кодовых точек для использования в качестве этих кодовых единиц, и кодовые точки из этого диапазона не могут индивидуально кодироваться в UTF-16 (и не могут быть юридически кодированы в какой-либо кодировке UTF).

UTF-16 указан в последних версиях как международного стандарта ISO / IEC 10646, так и стандарта Unicode.

Описание

от U + 0000 до U + D7FF и от U + E000 до U + FFFF

И UTF-16, и UCS-2 кодируют кодовые точки в этом диапазоне как одиночные 16-битные кодовые единицы, которые численно равны соответствующим кодовым точкам.Эти кодовые точки в BMP — это , только кодовых точек, которые могут быть представлены в UCS-2. Современный текст почти исключительно состоит из этих кодовых точек. ^{[ требуется ссылка ]}

U + 10000 до U + 10FFFF

Кодовые точки из других плоскостей (называемые дополнительными плоскостями) кодируются как две 16-битные кодовые единицы, называемые суррогатными парами , ^[5], по следующей схеме:

Декодер UTF-16
Высокий \ Низкий	DC00	DC01	…	DFFF
D800	010000	010001	…	0103FF
D801	010400	010401	…	0107FF
⋮	⋮	⋮	⋱	⋮
DBFF	10FC00	10FC01	…	10FFFF

0x010000 вычитается из кодовой точки, оставляя 20-битное число в диапазоне 0..0x0FFFFF.
Старшие десять битов (число в диапазоне 0..0x03FF) добавляются к 0xD800, чтобы получить первую 16-битную кодовую единицу или старший суррогат , который будет находиться в диапазоне 0xD800..0xDBFF.
Младшие десять битов (также в диапазоне 0..0x03FF) добавляются к 0xDC00, чтобы получить вторую 16-битную кодовую единицу или младший суррогат , который будет в диапазоне 0xDC00..0xDFFF.

Была попытка переименовать суррогаты «высокий» и «низкий» в «ведущие» и «конечные» из-за того, что их числовые значения не совпадают с их именами.Похоже, от этого отказались в последних стандартах Unicode.

Поскольку диапазоны для высоких суррогатов, низких суррогатов и допустимых символов BMP не пересекаются, суррогат не может соответствовать символу BMP или (части) двух соседних символов выглядеть как допустимая суррогатная пара. Это значительно упрощает поиск. Это также означает, что UTF-16 — это самосинхронизирующийся на 16-битных словах: можно ли определить, начинает ли кодовая единица символ, без проверки более ранних кодовых единиц.UTF-8 разделяет эти преимущества, но многие более ранние схемы многобайтового кодирования (такие как Shift JIS и другие азиатские многобайтовые кодировки) не допускали однозначного поиска и могли быть синхронизированы только путем повторного синтаксического анализа с начала строки (UTF- 16 не является самосинхронизирующимся, если один байт потерян или если обход начинается со случайного байта).

Поскольку все наиболее часто используемые символы относятся к базовой многоязычной плоскости, обработка суррогатных пар часто не проверяется полностью. Это приводит к постоянным ошибкам и потенциальным дырам в безопасности даже в популярном и хорошо проверенном прикладном программном обеспечении (например,грамм. CVE-2008-2938, CVE-2012-2135). ^[6]

Дополнительные самолеты содержат эмодзи, исторические сценарии, менее используемые символы, менее используемые китайские иероглифы и многое другое.

U + D800 к U + DFFF

Стандарт Unicode постоянно резервирует эти значения кодовых точек для кодирования UTF-16 для высоких и низких суррогатов, и им никогда не будет назначен символ, поэтому не должно быть причин для их кодирования. Официальный стандарт Unicode говорит, что никакие формы UTF, включая UTF-16, не могут кодировать эти кодовые точки.

Однако UCS-2, UTF-8 и UTF-32 могут кодировать эти кодовые точки тривиальными и очевидными способами, и большое количество программного обеспечения делает это, даже если в стандарте указано, что такие схемы следует рассматривать как ошибки кодирования. Их можно однозначно закодировать в UTF-16, используя кодовую единицу, равную кодовой точке, до тех пор, пока никакая последовательность из двух кодовых единиц не может быть интерпретирована как допустимая суррогатная пара (то есть до тех пор, пока высокий суррогат является никогда не сопровождался низким суррогатом). Большинство реализаций кодировщиков и декодеров UTF-16 переводят между кодировками, как если бы это было так. ^{[требуется ссылка ]} и Windows допускает такие последовательности в именах файлов.

Примеры

Рассмотрим кодировку U + 10437 (𐐷):

Вычтите 0x10000 из 0x10437. Результат: 0x00437, 0000 0000 0100 0011 0111.
Разделите это на старшее 10-битовое значение и младшее 10-битное значение: 0000000001 и 0000110111.
Добавьте 0xD800 к старшему значению, чтобы сформировать старший суррогат: 0xD800 + 0x0001 = 0xD801.
Добавьте 0xDC00 к нижнему значению, чтобы сформировать нижний суррогат: 0xDC00 + 0x0037 = 0xDC37.

В следующей таблице приведены данные об этом и других преобразованиях.Цвета показывают, как биты из кодовой точки распределяются между байтами UTF-16. Дополнительные биты, добавленные в процессе кодирования UTF-16, показаны черным.

Персонаж		Двоичный код	Двоичный UTF-16	UTF-16 шестнадцатеричный кодовые единицы	UTF-16BE шестнадцатеричные байты	UTF-16LE шестнадцатеричные байты
$	`U + 0024`	`0000 0000 0010 0100`	`0000 0000 0010 0100`	`0024`	`00 24`	`24 00`
€	`U + 20AC`	`0010 0000 1010 1100`	`0010 0000 1010 1100`	`20AC`	`20 переменного тока`	`ВМ 20`
𐐷	`U + 10437`	`0001 0000 0100 0011 0111`	`1101 1000 0000 0001 1101 1100 0011 0111`	`D801 DC37`	`D8 01 DC 37`	`01 D8 37 постоянного тока`
𤭢	`U + 24B62`	`0010 0100 1011 0110 0010`	`1101 1000 0101 0010 1101 1111 0110 0010`	`D852 DF62`	`D8 52 DF 62`	`52 D8 62 DF`

Схемы кодирования порядка байтов

UTF-16 и UCS-2 создают последовательность из 16-битных кодовых единиц.Поскольку большинство протоколов связи и хранения определены для байтов, и каждый блок, таким образом, занимает два 8-битных байта, порядок байтов может зависеть от порядка байтов (порядка байтов) архитектуры компьютера.

Чтобы помочь в распознавании порядка байтов кодовых единиц, UTF-16 позволяет метке порядка байтов (BOM), кодовой точке со значением U + FEFF, предшествовать первому фактическому кодированному значению. ^[7] (U + FEFF — невидимый неразрывный пробел нулевой ширины / символ ZWNBSP.) ^[8] Если конечная архитектура декодера совпадает с архитектурой кодера, декодер обнаруживает значение 0xFEFF, но декодер с обратным порядком байтов интерпретирует BOM как несимвольное значение U + FFFE, зарезервированное для этой цели.Этот неверный результат дает подсказку для выполнения замены байтов для оставшихся значений. Если спецификация отсутствует, RFC 2781 говорит, что следует использовать кодировку с прямым порядком байтов. (На практике, из-за того, что Windows по умолчанию использует прямой порядок байтов, многие приложения аналогичным образом предполагают обратный порядок байтов по умолчанию.) Если нет спецификации, одним из методов распознавания кодировки UTF-16 является поиск символа пробела (U +0020), что очень часто встречается в текстах на большинстве языков.

Стандарт также позволяет явно указывать порядок байтов, указывая UTF-16BE или UTF-16LE в качестве типа кодирования.Когда порядок байтов указан явно таким образом, спецификация — это конкретно , а не , который должен быть добавлен к тексту, а U + FEFF в начале следует обрабатывать как символ ZWNBSP. Многие приложения игнорируют код спецификации в начале любой кодировки Unicode. Веб-браузеры часто используют спецификации в качестве подсказки при определении кодировки символов. ^[9]

Для Интернет-протоколов IANA утвердила «UTF-16», «UTF-16BE» и «UTF-16LE» в качестве имен для этих кодировок.(Имена регистронезависимы.) Псевдонимы UTF_16 или UTF16 могут иметь смысл в некоторых языках программирования или программных приложениях, но они не являются стандартными именами в Интернет-протоколах.

Аналогичные обозначения, UCS-2 , UCS-2BE и UCS-2LE , используются для имитации меток и поведения UTF-16. Однако «UCS-2 теперь следует считать устаревшим. Он больше не относится к форме кодирования в 10646 или стандарте Unicode.»^[10]

Использование

UTF-16 используется для текста в API ОС в Microsoft Windows 2000 / XP / 2003 / Vista / 7/8 / CE. ^[11] Старые системы Windows NT (до Windows 2000) поддерживают только UCS-2. ^[12] В Windows XP код выше U + FFFF не включается ни в один шрифт, поставляемый с Windows для европейских языков. ^[13] ^[14] Файлы и сетевые данные, как правило, представляют собой смесь кодировок UTF-16, UTF-8 и устаревших байтовых кодировок.

Системы IBM iSeries обозначают кодовую страницу CCSID 13488 для кодировки символов UCS-2, CCSID 1200 для кодировки UTF-16 и CCSID 1208 для кодировки UTF-8.^[15]

UTF-16 используется операционными системами Qualcomm BREW; среды .NET; и инструментарий кроссплатформенных графических виджетов Qt.

ОС Symbian, используемая в телефонах Nokia S60 и Sony Ericsson UIQ, использует UCS-2. Мобильные телефоны iPhone используют UTF-16 для службы коротких сообщений вместо UCS-2, описанного в стандартах 3GPP TS 23.038 (GSM) и IS-637 (CDMA). ^[16]

Файловая система Joliet, используемая на носителях CD-ROM, кодирует имена файлов с помощью UCS-2BE (до шестидесяти четырех символов Unicode на имя файла).

Языковая среда Python официально использует UCS-2 только для внутреннего использования, начиная с версии 2.0, но декодер UTF-8 для «Unicode» выдает правильный UTF-16. Начиная с Python 2.2, поддерживаются «широкие» сборки Unicode, которые вместо этого используют UTF-32; ^[17] они в основном используются в Linux. Python 3.3 больше никогда не использует UTF-16, вместо этого кодировка, которая дает наиболее компактное представление для данной строки, выбирается из ASCII / Latin-1, UCS-2 и UTF-32. ^[18]

Java изначально использовала UCS-2 и добавила поддержку дополнительных символов UTF-16 в J2SE 5.0.

JavaScript использует UTF-16. ^[19]

Во многих языках строки в кавычках нуждаются в новом синтаксисе для заключения в кавычки не-BMP символов, если синтаксис "\ uXXXX" языка явно ограничивает себя 4 шестнадцатеричными цифрами. Наиболее распространенным (используемым в C #, D и некоторых других языках) является использование заглавной буквы «U» с 8 шестнадцатеричными цифрами, например "\ U0001D11E" ^[20] В Java 7 регулярные выражения и ICU и Perl должен использоваться синтаксис "\ x {1D11E}" .Во многих других случаях (например, Java вне регулярных выражений) ^[21] единственный способ получить символы, отличные от BMP, — это ввести суррогатные половинки по отдельности, например: "\ uD834 \ uDD1E" для U + 1D11E.

Эти реализации все возвращают количество 16-битных кодовых единиц, а не количество кодовых точек Unicode, когда соответствующий вызов функции длины строки используется в их строках, а индексация в строку возвращает индексированную кодовую единицу, а не индексированная кодовая точка, ^[22] ^[23] ^[24] ^[25], это заставляет некоторых людей утверждать, что UTF-16 не поддерживается ^{[ ласковых слов ]}.Однако термин «символ» определяется и используется множеством способов в терминологии Unicode, ^[26], поэтому однозначный подсчет невозможен. Большая часть путаницы происходит из-за устаревшей документации эпохи ASCII, в которой используется термин «символ», когда предназначались «байт» или «октет» фиксированного размера. ^{[ требуется ссылка ]}

См. Также

Список литературы

Base64 Encode and Decode — онлайн

О

Встречайте Base64 Decode and Encode, простой онлайн-инструмент, который делает именно то, что он говорит; декодирует кодировку Base64 и быстро и легко кодирует в нее.Base64 кодирует ваши данные без проблем или декодирует их в удобочитаемый формат. Схемы кодирования

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

Дополнительные параметры

Набор символов: Наш веб-сайт использует набор символов UTF-8, ваши входные данные передаются в этом формате.Измените этот параметр, если вы хотите преобразовать его в другой перед кодированием. Обратите внимание, что в случае текстовых данных схема кодирования не содержит их набора символов, поэтому вам, возможно, придется указать выбранный в процессе декодирования. Что касается файлов, по умолчанию используется двоичный параметр, при котором любое преобразование не выполняется; это требуется для всего, кроме текстовых документов.
Разделитель новой строки: В системах Unix и Windows используются разные символы разрыва строки, предыдущая кодировка любого варианта будет заменена в ваших данных выбранным параметром.В разделе файлов это частично не имеет значения, поскольку они содержат предполагаемые версии, но вы можете определить, какую из них использовать для кодирования каждой строки отдельно и разделения строк на функции фрагментов.
Кодируйте каждую строку отдельно: Даже символы новой строки преобразуются в их закодированные в base64 формы. Используйте эту опцию, если вы хотите закодировать несколько независимых записей данных, разделенных переносом строки. (*)
Разделить строки на фрагменты: Закодированные данные будут представлять собой непрерывный текст без пробелов. Отметьте эту опцию, если хотите разбить его на несколько строк.Применяемое ограничение на количество символов определено в спецификации MIME (RFC 2045), в которой указано, что длина закодированных строк не должна превышать 76 символов. (*)
Выполнение безопасного кодирования URL: Использование стандартного Base64 в URL-адресах требует кодирования символов «+», «/» и «=» в их процентной форме, что делает строку излишне длиннее. Включите этот параметр, чтобы кодировать в вариант Base64, удобный для URL и имени файла (RFC 4648 / Base64URL), где символы «+» и «/» соответственно заменены на «-» и «_», а также заполнение «=» знаки опущены.
Режим реального времени: Когда вы включаете эту опцию, введенные данные немедленно кодируются с помощью встроенных функций JavaScript вашего браузера — без отправки какой-либо информации на наши серверы. В настоящее время этот режим поддерживает только набор символов UTF-8.

(*) Эти параметры нельзя включить одновременно, так как результирующий вывод не будет действителен для большинства приложений.

Надежно и надежно

Все коммуникации с нашими серверами осуществляются через безопасные зашифрованные соединения SSL (https).Загруженные файлы удаляются с наших серверов сразу после обработки, а полученный загружаемый файл удаляется сразу после первой попытки загрузки или 15 минут бездействия. Мы никоим образом не храним и не проверяем содержимое введенных данных или загруженных файлов. Прочтите нашу политику конфиденциальности ниже для получения более подробной информации.

Совершенно бесплатно

Наш инструмент можно использовать бесплатно. Теперь вам не нужно загружать какое-либо программное обеспечение для таких задач.

Подробная информация о кодировке Base64

Base64 — это общий термин для ряда аналогичных схем кодирования, которые кодируют двоичные данные, обрабатывая их численно и переводя в представление с основанием 64.Термин Base64 происходит от конкретной кодировки передачи содержимого MIME.

Дизайн

Конкретный выбор символов для создания 64 символов, необходимых для основы, варьируется в зависимости от реализации. Общее правило — выбрать набор из 64 символов, который одновременно является частью подмножества, общего для большинства кодировок, а также пригоден для печати. Эта комбинация оставляет маловероятным изменение данных при передаче через такие системы, как электронная почта, которые традиционно не были 8-битными чистыми.Например, реализация MIME Base64 использует A – Z, a – z и 0–9 для первых 62 значений, «+» и «/» для последних двух. Другие варианты, обычно производные от Base64, разделяют это свойство, но отличаются символами, выбранными для последних двух значений; Примером является вариант с безопасным URL-адресом и именем файла (RFC 4648 / Base64URL), в котором используются «-» и «_».

Пример

Цитата из «Левиафана» Томаса Гоббса:

« Человека отличает не только его разум, но и… «

представлена в виде последовательности ASCII-байт кодируются в схеме Base64 MIME, как показано ниже:

TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCAuLi4 =

В приведенных выше цитатах закодированного значение Люди в TWFu закодированных в формате ASCII, М . , a , n сохраняются как байты 77, 97, 110, которые равны 01001101, 01100001, 01101110 по основанию 2. Эти три байта объединяются в 24-битный буфер, производящий 010011010110000101101110.Пакеты из 6 бит (6 бит имеют максимум 64 различных двоичных значения) преобразуются в 4 числа (24 = 4 * 6 бит), которые затем преобразуются в соответствующие им значения в Base64.

Текстовое содержание	M								a								n
ASCII	77								97								110
Битовый узор	0	1	0	0	1	1	0	1	0	1	1	0	0	0	0	1	0	1	1	0	1	1	1	0
Индекс	19						22						5						46
Кодировка Base64	T						W						F						u

Как этот пример Как показано, кодировка Base64 преобразует 3 некодированных байта (в данном случае символы ASCII) в 4 закодированных символа ASCII.

кодировок японского языка

кодировок японского языка

Автор: Александр Элиас (изменено для часто задаваемых вопросов sci.lang.japan)

Содержание

Введение

Цель этого документа
Японская письменность
Набор символов и кодировка
Обзор схем кодирования

JIS

Наборы символов JIS

JIS X 0201
JIS X 0208
JIS X 0212
JIS X 0213
Собственное расширение NEC / IBM

Кодировки на основе JIS

EUC-JP
Сдвиг JIS
CP932
ISO-2022-JP

Юникод

Порядок байтов и спецификация
Кодировки на основе Unicode

UTF-8
UTF-16
UTF-32
Punycode

Мертвые кодировки Unicode

UTF-7
SCSU
Другие мертвые кодировки

Кодировки в дикой природе

Проблемы преобразования
Программное обеспечение для преобразования

Microsoft Windows
iconv
Perl
нкф

В сети

Кодировки веб-страниц
HTML-объекты

По электронной почте

Заголовки электронной почты

Таблицы

Наборы японских символов JIS
Схемы кодирования японских символов
Shift JIS преобразований

Интернет-ссылки

1.Введение

1.1. Цель этого документа

Этот документ знакомит с кодировкой японского текста.
на компьютерах.

1.2. Японская письменность

В японском языке есть три основные системы письма: хирагана, катакана и кандзи.
Римские буквы (a, b, c …), арабские цифры (0, 1, 2 …) и различные
знаки препинания (。,!,?, 「,」 …) (см. Как называются японские символы без кана и кандзи?)
найдено в японской письменности. Все эти разные системы письма могут
можно найти в том же предложении.Вот пример:

UNIX の日本語文字コードを扱うために使用されいる従来の
EUC
は次のようなものでした。
Это означает «Обычная кодировка EUC, используемая для обработки японских
коды символов в Unix были следующими ».

Каждый символ хираганы, катакана или кандзи квадратный и состоит из
подобный размер.

Японский язык традиционно писался столбцами сверху вниз,
с последующими столбцами, идущими справа налево. Увидеть
Можно ли писать на японском справа налево? В наши дни японский часто пишут рядами
иду слева направо, как в английском.Помимо обработки текста
и настольных издательских программах, письмо слева направо почти
всегда используется на компьютерных дисплеях.

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

	ka	ki	ku	ke	ko
Хирагана	か	き	く	け	こ
Катакана	カ	キ	ク	ケ	コ

Кандзи — это сложная идеографическая система письма из Китая. Увидеть
Кандзи Они по сей день остаются очень похожими на китайские.В
кандзи объединены с китайским и корейским в символе Unicode
задавать. В Японии используются тысячи иероглифов. В
количество кандзи затрудняет изучение японского письма и
кодировать на компьютерах. Кандзи можно узнать по их комплексу,
сложный внешний вид: например, 通, 飛 и 治 — обычные иероглифы.
Но некоторые кандзи выглядят просто, например 人 и 女.

Поскольку кана может выражать все возможные звуки на японском языке, это
можно написать любое японское предложение, используя только одну из двух кана
системы письма.Таким образом, самый ранний стандартный набор японских символов
для компьютеров (JIS X 0201, описанный ниже) поддерживается только
катакана, что, хотя и неудобно, было достаточно.

1.3. Набор символов и кодировка

Набор символов — это взаимно-однозначное соответствие между набором различных
целые числа и набор письменных символов. Например, определите новый
набор символов FOOBAR, который отображает алфавит {A, B, C} на цифры 1,
2 и 3 соответственно. Набор символов — это абстрактное понятие, которое
существует только в сознании программиста: компьютеры напрямую не
манипулировать наборами символов.

Кодировка — это способ хранения символов в 0 и 1 на компьютере.
объем памяти. Для реализации поддержки FOOBAR на реальном компьютере наиболее
очевидным способом кодирования данных было бы представление одного символа на
byte, следуя обычному способу кодирования целых чисел в двоичном формате. В этом
схема, строка «AABC» будет выглядеть так:

00000001 00000001 00000010 00000011

Так обычно кодируется ASCII. Но поскольку их всего три
отдельные персонажи в FOOBAR, в данном случае это кажется довольно расточительным.В качестве альтернативы можно использовать два бита для каждого символа в
строка. Это позволит нам втиснуть всю строку «AABC» в одну
байт:

01011011

Кодировка изменилась, но набор символов остался прежним. В
в общем, как ни крутила и запутана схема кодирования
становится, концептуально {A, B, C} все еще отображается в {1,2,3}.

1.4. Обзор схем кодирования

В реальной жизни кодировки имеют тенденцию бесконтрольно размножаться как
разработчики учитывают особенности своих систем, но характер
комплектов осталось немного.В англоязычном мире только двое
Наборы символов на радаре — ASCII и EBCDIC. Аналогично там
для написания японского языка используются только два набора символов: JIS (японский
Промышленный стандарт) и Unicode. (И японцы
часть Unicode фактически получена из JIS.)

Юникод — это новый, превосходный стандарт. Японские компьютеры были
использовали JIS в течение десятилетий, а Unicode появился только в последние несколько
лет. Все больше и больше японских текстов пишется в Юникоде, но это
по-прежнему необходимо иметь дело с текстом JIS и Unicode.

По мере развития потребностей оба стандарта претерпели несколько изменений.
В основном это проблема JIS, поскольку процесс его пересмотра был
несколько хаотично. Напротив, Unicode следует политике, согласно которой каждый новый
ревизия должна быть строгим надмножеством предыдущих, поэтому версия
конфликты редко вызывают проблемы.

Есть три кодировки JIS (Shift JIS, EUC, ISO-2022-JP) и
три кодировки Unicode (UTF-8, UTF-16, UTF-32) широко используются. В
в двух словах:

Shift JIS — это кодировка Microsoft JIS, стандартная для
Системы Windows и Mac.Почти все японские веб-страницы раньше были
закодирован в Shift JIS.
EUC (EUC-JP) — это кодировка JIS в Unix. Это
раньше было стандартом для систем Linux / BSD, а иногда и в сети
страниц.
ISO-2022-JP — это 7-битная кодировка JIS, что сообщения электронной почты
обычно отправляется. Он редко используется в других контекстах.
UTF-8 — стандарт кодирования Unicode в Unix и
в Интернете и UTF-16 в кодировке Unicode
стандарт в Windows. UTF-32 в основном используется для внутренних
представление внутри программ, а не для обмена.

2. JIS

JIS означает «Японский промышленный стандарт» на японском языке.
Нихон Когьё Кикаку (日本工業規格). JIS — это общий термин, используемый
для описания всех наборов символов и кодировок не-Unicode японского языка, все
из которых основаны на стандартах, опубликованных Японскими стандартами
Ассоциация, Nihon Kikaku Kyōkai (日本規格協会) на японском языке.

2.1. Наборы символов JIS

В отличие от Unicode, здесь нет единого набора символов JIS.Кодировка JIS
фактически включает в себя несколько стандартных наборов символов, используемых в комбинации:

JIS X 0201 — латинские буквы (a, b, c …) и катакана половинной ширины
только. Стандартный префикс: JG.
JIS X 0208 — Базовый набор символов. 6355 кандзи из
уровень 1 и 2, 524 кана / знаков препинания и т. д.
Стандартный префикс: JH.
JIS X 0212 — Дополнительные символы. 5801 редкий кандзи, 266 неанглийских языков
Европейские персонажи. Стандартный префикс: JJ.
JIS X 0213 — Новый унифицированный набор символов. Иногда называется JIS2000,
введен в 2000 году и предназначен для замены 0208/0212
сочетание. У него нет стандартного префикса.

«X» в названиях этих стандартов является информационным кодом.
стандарты, связанные с технологиями.

Кодировки JIS используют различные методы для использования этих перекрывающихся символов.
устанавливает вместе.

Вышеупомянутые четыре стандарта JIS являются важными, но для
ссылка, вот значение всех кодов JIS X 200:

JIS X 0201 — Роман / катакана (JG)
JIS X 0202 — ISO-2022-JP
JIS X 0203, 0204, 0205, 0206, 0207 — Устаревшие / отмененные стандарты
JIS X 0208 — Основной набор символов кандзи (JH)
JIS X 0209 — Как писать символы JIS X 0211
JIS X 0210 — Как кодировать числа
JIS X 0211 — Стандартные управляющие коды ASCII
JIS X 0212 — Дополнительный набор символов (JJ)
JIS X 0213 — Новый унифицированный набор символов JIS
JIS X 0218 — Определение стандартных префиксов (JG, JH, JJ, JK, JL)
JIS X 0221 — Unicode (JK для UCS-2, JL для UCS-4)

2.1.1. JIS X 0201

JIS X 0201 — это восьмибитный набор символов, поддерживающий только катакану.
и символы ASCII. Шестнадцатеричные коды символов JIS X 0201 могут
иметь префикс «JG», чтобы отличать их от других символов JIS
наборы. Он был разработан в 1960-х годах (задолго до других стандартов),
когда компьютеры не были достаточно мощными, чтобы хранить кандзи.

7-битная часть (то есть от 0x00 до 0x7f) JIS X 0201 идентична ASCII,
с двумя исключениями: символ обратной косой черты ‘\’ (0x5c) заменяется на
символ йены, а символ тильды ‘~’ (0x7c) становится надстрочным.Таким образом, отображение текста ASCII в японском шрифте будет работать почти
отлично — за исключением того, что все обратные косые черты превратятся в иены.
Эта проблема настолько распространена, что больше не является «проблемой»
все: японцы все знают и ожидают найти символы йены вместо
обратная косая черта в разделителях путей DOS / Windows.

Эта часть этой кодировки также известна как JIS Roman.

8-битная часть делится следующим образом:

От 0x80 до 0xa0 включительно: зарезервировано
от 0xa1 до 0xdf включительно: пунктуация в японском стиле и катакана половинной ширины
от 0xe0 до 0xff включительно: зарезервировано

Катакана «полуширины», другими словами высокие и тонкие, потому что
делает их того же размера, что и латинские буквы, и поэтому их легко отображать на
клеммы фиксированной ширины.См. Что такое катакана половинной ширины?

2.1.2. JIS X 0208

JIS X 0208 — самый важный стандарт. Когда люди говорят «JIS
стандарт «, они означают JIS X 0208. Шестнадцатеричный символ JIS X 0208.
коды могут иметь префикс «JH», чтобы отличать их от других JIS
наборы символов. Прошло четыре официальные версии от
Японская ассоциация стандартов.

Лист регистраций изменений:

1978	Стандарт был создан как JIS C 6226.Эта версия также известна как «Олд-JIS». Теперь он более или менее мертв.
1983	Стандарт был изменен для списка кандзи Дзёё 1981 г. (см. Что такое Jōy Kanji ?).
1990	В конец добавлены два иероглифа.
1997	В конец добавлено шесть иероглифов.

Стандарты 1983, 1990 и 1997 годов по сути одинаковы, поскольку
близкие суперсеты друг друга.Это

Учебник: Кодировка символов и Unicode

Учебник: Кодировка символов и Юникод

WWW2005 Учебное пособие: Интернационализация Интернета
Контент и веб-технологии

10 мая 2005 г., Макухари, Тиба, Япония

Мартин Дж. Дюрст ([email protected])

Департамент интегрированной информации
Технологический
Научно-технический колледж
Университет Аояма Гакуин
Токио / Сагамихара, Япония

Для представления символов на компьютере они должны быть:
выбранных ( репертуар персонажей )
в виде чисел ( кодированных символов , символ
стол)
, в конечном итоге, представлен как биты и байты ( символов
кодировка )

Общие разработки:

Все больше и больше символов, все больше и больше бит на символ
Кодировки для больших и больших сообществ (местных, корпоративных,
национальный, наднациональный, глобальный)
Более сложное кодирование (переключение кода ,…)
Все больше и больше сложности (прямое отображение символа-символа-символа ->
сложные отношения)

5-битные кодировки
6-битные кодировки
7-битные кодировки (национальные варианты US-ASCII, ISO 646, …)
8-битные кодировки (EBCDIC, серия ISO 8859-x, …)
многобайтовых кодировок

Многобайтовые кодировки (например, shift_JIS, euc-jp, …)
трудно идентифицировать символы в потоке байтов
адаптация программы с однобайтовой к многобайтовой требует огромных
работа
различных многобайтовых кодировок требуют разных адаптаций
Кодовое переключение (e.грамм. iso-2022-jp, ISO 2022 в целом)
даже сложнее, чем многобайтовые кодировки
сложно получить точную информацию о некоторых частях

Специальные и основанные на исследованиях кодировки
Корпоративные кодировки
Национальные кодировки
Наднациональные кодировки

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

Основная идея: Единая кодировка для всего мира

Первоначально два отдельных проекта:

ISO / IEC 10646 (согласно ISO / IEC JTC1 SC2 WG2)
Стандарт Unicode (Консорциум Unicode)

Объединено между 1991 и 1993 годами, чтобы избежать двух глобальных кодировок.

Для простоты в этом докладе используется термин Unicode для общего
продукт, если он не является двусмысленным.

Два стандарта, очень близко синхронизированные
Набор символов
Таблица символов с номером для каждого символа
Три кодировки
Большая помощь по работе с персонажами

Стандарт Unicode, доступен в виде книги (ISBN 0-321-18578-1) и
онлайн
ISO / IEC 10646, доступно на компакт-диске
ISO / IEC 10646 переведен во многие национальные варианты (например,грамм. JIS X
0221)

Опознавательные знаки:
Какие скрипты
Какие символы (в отличие от несимволов, таких как логотипы,
иконы, …)
Какие персонажи (какой уровень абстракции, …)
Кодирование в центре ввода / рендеринга / обработки / хранения
Unification (какие персонажи одинаковые, какие разные)
Один и тот же символ должен кодироваться только один раз, независимо
языка
Для небольших скриптов решение очевидно или возможно.
в индивидуальном порядке

Для идеографов CJKV необходим более систематический подход:

На основе правил унификации, используемых в национальном стандарте Японии
Ориентировано на обычных пользователей / использование
«явно разные» формы: отдельные кодовые точки (например,грамм.体 U + 4F53 vs.
體 U + 9AD4)
«очень похожие» формы: отдельные кодовые точки, если разные значения
(например, 大、犬、太、土、士)
, в остальном «очень похожие» формы: одна кодовая точка (например, U + 8FBB)

Исходный дизайн ISO / IEC (32-бит): 128 групп по 256 плоскостей
Оригинальный дизайн Unicode (16 бит): 16 бит на символ, 2 ¹⁶
персонажи
Конечная структура: 1 + 16 = 17 самолетов:
БМП (базовый многоязычный самолет, самолет 0, современный)
Плоскость 1, SMP (дополнительная многоязычная плоскость, историческая
скрипты ,…)
Plane 2, SIP (дополнительная идеографическая плоскость, очень редко
идеограммы)
Самолеты 3-13: в настоящее время не используются
Самолет 14, SSP (дополнительный самолет специального назначения, бирки, вариант
селекторы, …)
Самолеты 15 и 16: Частное использование

Номера символов шестнадцатеричные, с использованием цифр 0-9 и A-F
Обозначение: U + hhhh, где hhhh — 4-6 шестнадцатеричных цифр
Первые 128 позиций: идентичны US-ASCII
Первые 265 позиций: идентичны ISO 8859-1 (Latin-1)
Персонажи упорядочены по сценарию и функционируют в блоках
Наименьшие блоки: Kanbun, Katakana Phonetic Extensions ,… (16
знаков каждый)
Самый большой блок: CJK Unified Ideographs Extension B, от U + 20000 до
U + 2A6DF (42720 знаков)
Может быть более одного блока для сценария (пример: 0600..06FF арабский;
0750..077F Арабское приложение)

Некоторые числа не используются или выполняют особую функцию
Несимвольные кодовые точки
Кодовые точки для частного использования
Некоторые «персонажи» не выглядят и не работают так, как мы думаем о персонажах
Управляющие символы
Форматирование символов

Кодовая точка используется для чисел, которые на самом деле не являются символами

UTF-8
Многобайтовая кодировка с хорошими свойствами
ASCII-совместимый в очень строгом смысле
UTF-16
Кодирование с переменной длиной, большинство символов 16 бит
Внутренняя кодировка для многих приложений и систем
UTF-32
Очень просто и понятно
Используется в некоторых системах Unix для внутренней обработки

из	по	использование	байт номер
из	по	использование	1	2	3	4
U + 0000	U + 007F	US-ASCII	0xxx xxxx	–	–	–
U + 0080	U + 07FF	Latin ,…, арабский	110x хххх	10xx xxxx	–	–
U + 0800	U + FFFF	остальная часть БМП	1110 хххх	10xx xxxx	10xx xxxx	–
U + 10000	U + 10FFFF	без BMP	1111 0xxx	10xx xxxx	10xx xxxx	10xx xxxx

Допускается только самая короткая кодировка.

Очистить роли байтовых значений (одиночные: 0 …, начальные: 11 …, конечные:
10 …, не используется: C0, C1, F5-FF; ср. например с Shift_JIS)
Легко определить начало символа в потоке байтов, синхронизировать в случае
ошибок
Легко отличить от других кодировок на основе байтового шаблона
Нет совпадений
Строго защищает US-ASCII, важный для многих протоколов и рабочих
системы
Бинарная сортировка идентична UCS-4 / UTF-32
Достаточно компактный для текста с большим количеством ASCII

См.
Свойства и обещания UTF-8

Кодировка по умолчанию для XML
Многие протоколы
IRI-> преобразование URI
Некоторые файловые системы (становятся популярными из-за имен файлов Unix / Linux)
Внутренняя обработка в некоторых приложениях

Кодовая единица — 16 бит (два байта, одно полуслово)
Одна кодовая единица для символов в BMP
Две кодовые единицы для символов в плоскостях 1-16
2048 «кодовых точек» в BMP зарезервированы для UTF-16
Высокие суррогаты: D800-DBFF
Низкие суррогаты: DC00-DFFF

Каждый символ напрямую представлен как 32-байтовая кодовая единица (одна
слово)
Прямое, но довольно неэффективное кодирование
Используется внутри некоторых Unix-подобных систем и приложений, а также для
отдельные виды обработки
Проблемы с порядком байтов и их решения аналогичны тем, что и в UTF-16

Только в стандарте Unicode, не является частью ISO / IEC 10646

Визуализация и обработка
Преобразование из / в устаревшие (не Unicode) кодировки
Двунаправленный рендеринг
Сортировка
Нормализация
.
No related posts.

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Кодировка 16 битная: Персональный сайт преподавателя информатики — Задача 2.1

Персональный сайт преподавателя информатики — Задача 2.1

Система задач на кодирование текстовой информации.

разрядные и 16разрядные коды символов.

Что Такое Unicode, Utf-8, Utf-16?

Зачем нужен Юникод?

Вопросы памяти

Основы кодирования

Практические соображения программирования

Как работает FC-AL | Журнал сетевых решений/LAN

Основные протоколы физического уровня Fibre Channel.

КОДИРОВАНИЕ 8B/10B

АРБИТРАЖ ДОСТУПА

ИНИЦИАЛИЗАЦИЯ ПЕТЛИ

АДРЕСАЦИЯ

КОНТРОЛЬ ПОТОКОВ

СИНТАКСИЧЕСКАЯ СТРУКТУРА

НА ВСЕ СЛУЧАИ

Реферат utf-16

История появления

Порядок байт

UTF-16LE и UTF-16ВE

UTF-16 в ОС Windows

UTF-16 в сотовой связи

RFC 3629 | UTF-8, формат преобразования ISO 10646

Аннотация

Оглавление

Статус этой заметки

Уведомление об авторских правах

1. Введение

2. Условные обозначения

3. Определение UTF-8

4. Синтаксис байтовых последовательностей UTF-8

5. Версии стандартов

6. Порядок следования байтов (BOM)

7. Примеры

8. Регистрация MIME

9. Соображения IANA

10. Вопросы безопасности

11. Благодарности

12. Отличия от RFC 2279

13. Нормативные документы

14. Информационные ссылки

15. URI

16. Заявление об интеллектуальной собственности

17. Адрес автора

18. Полная информация об авторских правах

16 — Infogalactic: ядро ​​планетарного знания

История

Описание

от U + 0000 до U + D7FF и от U + E000 до U + FFFF

U + 10000 до U + 10FFFF

U + D800 к U + DFFF

Примеры

Схемы кодирования порядка байтов

Использование

См. Также

Список литературы

Base64 Encode and Decode — онлайн

О

кодировок японского языка

Содержание

1.Введение

1.1. Цель этого документа

1.2. Японская письменность

1.3. Набор символов и кодировка

1.4. Обзор схем кодирования

2. JIS

2.1. Наборы символов JIS

2.1.1. JIS X 0201

2.1.2. JIS X 0208

Учебник: Кодировка символов и Unicode

WWW2005 Учебное пособие: Интернационализация Интернета Контент и веб-технологии

Добавить комментарий Отменить ответ

16 — Infogalactic: ядро планетарного знания

WWW2005 Учебное пособие: Интернационализация Интернета
Контент и веб-технологии