Как стать автором
Обновить

Комментарии 41

Первая кодировка — это Код Бодо, ну это если не считать Морзянку
3D5 = 00000000 1111010101 (ведущие 10 бит получились нулевые приведем это к шестнадцатиричному числу, получим 0 (первые десять), 3D5 (вторые десять))

Десять или восемь?

1101100000100010 — десятый бит нулевой, значит первый суррогат
1101111010001000 — десятый бит единица, значит второй суррогат

Что-то у меня в обоих случаях десятый бит равен нулю. Или я его не с той стороны отсчитываю? Тогда почему первые 6 отсчитывались с этой же стороны?
Десять или восемь?

Чисто теоретически это без разницы, но лучше чтобы они были

Что-то у меня в обоих случаях десятый бит равен нулю. Или я его не с той стороны отсчитываю? Тогда почему первые 6 отсчитывались с этой же стороны?

Прошу прощения за мою оплошность.

Спасибо что так внимательно прочитали)
> Вопрос с кодировками сейчас конечно уже потерял актуальность

Винда научилась в юникодную кириллицу в терминале?
Теряет актуальность

Да если бы только в винде дело было (там хоть PowerShell теперь есть). Мы, например, у себя Apache Livy подняли, так там послать в Python (причём в третий, где таких проблем, по идее, быть не должно) что-то не-ASCII невозможно, приходится все строки кодировать через escape-последовательности.

Вот бы ещё такой же подробный разбор про utf8mb4

Я постараюсь, но не обещаю)
Тема нормализации не раскрыта :)
Ещё было бы неплохо упомянуть о существовании UTF-16LE / UTF-16BE, а также упомянуть, что UTF-8 всегда кодируется единообразно, несмотря на порядок байт хост системы, в чём несомненный плюс этой кодировки по сравнению с UTF-16.
Да было бы конечно неплохо, но получилась бы очень длинная статья, как по мне, нужно было бы тогда написать про big endian, little endian, от чего это зависит, чем отличается.
А хотелось максимально подробно самую суть описать.
Если вдруг будет продолжение то непременно)
А я вот не вижу смысла в юникоде в командной строке. Ладно, в pdf или иксовых приложениях — там нужно бывает всякие разные символы отображать, не входящие в КОИ8-Р, но в консоли за глаза хватает восьмибитной кодировки. Да еще и дополнительный бонус: в MAXPATH можно вместить больше символов!
Ну отобразите мне файлы с иероглифами в именах.
Зачем? Вы понимаете китайский? Ну, если так, то вам пригодится юникод.
Мне же это не нужно!
И что теперь, ради вас делать отдельную консоль?
Зачем? У меня КОИ8-Р и меня это превосходно устраивает!
Нет, накачал японской музыки.
Поделиться скриптом для переименования файлов (задает имена вида 0001.suff, 0002.suff и т.д.)?
Зачем мне увеличивать энтропию вселенной? У меня юникодная консоль, и эмулятор терминала и FS и GUI.
Хорошая статья, но самое сложное в современных текстах осталось за скобками:
графемы, направленность текста, эмодзи и модификаторы (типа цвета кожи).

Конечно хорошая, поэтому я немного поправлю ваш комментарий:
"..., но ХОТЕЛОСЬ бы узнать про самое сложное в современных текстах: графемы, направленность текста, эмодзи и модификаторы".

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

Правильнее бит? Почему-то через ctrl+enter не отправить.
Все верно, спасибо
если ведущий (первый) бит нулевой

01100101 — первый бит ноль, значит 1 байт кодирует 1 символ -> «e»

Тут надо быть поаккуратнее.
При рассмотрении байта традиционно крайний правый бит считают нулевым, а крайний левый — седьмым.
Автор же вводит понятие «ведущий», да еще и указывает «первый» бит, нарушая общепринятые нормы. В приведенном им примере
01100101
первый бит (если следовать устоявшимся традициям) — это второй справа: 01100101 — я его выделил жирным цветом и подчеркнул.
Далее автор приводит примеры, поясняющие его же слова, и в целом понятно о чем идет речь, но лучше уж следовать общепринятой методологии.
Спасибо автору за статью.
Спасибо, все верно, упустил.
Скорректирую текст в соответствии с нормами
fm-00, Извините, может у Вас есть идея как двоично безопасно перевести байты 128..255
в utf-8, чтобы потом можно их восстановить не указывая исходную кодировку?

Дано двоичный поток байтов от 0 до 255. Надо его конвертировать в UTF-8 и обратно.
\u0-u7f не искажаются, а вот в диапазоне \u80 (& # 128)-\uff (& # 255)
есть Диакрити́ческие зна́ки, которые в разных кодировках потом восстанавливаются по разному :(

Традиционно: блоб кодируется в base64, получаемая base64-строка в уже в ASCII и совместима с другими кодировками. Например, [0x69, 0x73, 0x20, 0xDE, 0xAD] => "aXMg3q0=". Преимущества: стандартизированный алгоритм. Недостатки: ASCII-байты не видно и результат всегда занимает на треть больше места.


Вообще можете просто закодировать байты как Unicode-символы в UTF-8, оставляя ASCII-символы как есть, а у остальных экранируя два старших бита. Например, 0xDE => [0xC0 + 0xDE >> 6, 0x80 + 0xDE & 0x3F] = [0xC3, 0x9E]. Результат является корректным UTF-8 текстом, так как в диапазоне U+0080 — U+00FF нет комбинирующихся символов и прочих особенностей.


А стоп… проблема, похоже, как раз в том, что полученный текст страдает потом от «умных» нормализаторов (потому что декомбинирующиеся символы в том диапазоне есть). Ну тогда можно кодировать старший бит каким-нибудь UTF-8 символом: 0xDE => [0xC2, 0x80, 0xDE & 0x7F] = [0xC2, 0x80, 0x5E]. То есть сбросить старший бит (опустив до ASCII) и приписать спереди UTF-8 байты для U+0080 Padding Character, который наверное никто не тронет.

Надежда была, что я не знал, про какую-то управляющую структуру UTF, типа дальше идет двоичный объект из стольких-то байтов.

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

За прошлый год несколько раз полностью
рассыпался документ в openOffice. Копируешь в него, сохранение, открываешь
файл через некоторое время, и весь текст из непонятной мешанины символов.
В принципе знаешь, что это мог быть сбойный байт или бит оказаться на винте, или при сохранение/чтение ошибка какая в программе из-за всех этих наворотов.

Надежда была, что я не знал, про какую-то управляющую структуру UTF, типа дальше идет двоичный объект из стольких-то байтов.

Да это была бы хорошая штука, особенно если бы еще и не особо влияла на конечный вес файла, но к сожалению не зная исходной кодировки нет универсального способа, чтобы однозначно ее определить
Чтобы получить детальное понимание этого вопроса придется прочитать и свести воедино не одну статью и потратить довольно значительное время на это.
Для детального понимания вопроса наверно будет достаточно всего одной статьи: Краткая история систем кодирования символов естественных языков в США, Европе и Восточно-азиатских странах

А посмотреть на проблему кодировок с точки зрения глобальной политики можно тут: «Проблема кодировок»: стечение обстоятельств или стратегический замысел?
В свое время почему-то безнадежно путался в терминологии.
И все же:
ascii — и таблица и кодировка (или просто кодировки как таковой просто нет)?
кодировка и кодовая страница — синонимы?
ascii — и таблица и кодировка (или просто кодировки как таковой просто нет)?

тут вы очень хорошо описали чем является ascii это таблица и кодировка (но по факту кодировки нет)

кодировка и кодовая страница — синонимы?

возможно это холиварный вопрос, но все же это не синонимы ну или не всегда это синонимы
ASCII — Американский стандарт… только для 7 бит. Фактически все остальные однобайтовые
кодировки с ним совместимы. Но следует отметить, что все же есть вариации 14 символов
(национальные) 23,24,25,2A,40,5B,5C,5D,5E,60,7B,7C,7E
Из-за совместимости все кодовые страницы базировались на ascii
Детали появления UTF-16 жалко не написали. Не понятно, зачем она вообще нужна, если есть UTF-8? Ведь UTF-8 меньше занимает объёма и тоже переменной длины.
Если уж смотреть на кодировку с точки зрения производительности, то если выбирать хрюникод, нужно остановиться на utf-32!!!
Пожалуйста поправьте в строке «2. в результате первого пункта будет получено число не больше FFFF, занимающее до 20 бит»
FFFF на FFFFF
Спасибо, исправил
На самом деле с кодировками всё не так уж сложно, и я бы рекомендовал прочитать статью Joel Spolsky, или вот эти статьи на хабре: раз и два. Если вкратце, тут не одна проблема, а как минимум две (если оставить в стороне всякие юникодные комбинации и смайлики):
— соответствие элементов языка и управляющих конструкций числам
— способ хранения этих чисел в памяти
По сути, когда заданы два этих отображения, мы уже можем интерпретировать байты в памяти машины как какой-то текст в определенной кодировке. И слово «юникод» на самом деле по своей сути относится к первой из этих проблем, а «UTF-8» или «UTF-16» — ко второй. А дальше возникает проблема в том, что какой-нибудь древний файл представляет из себя поток байт без указания на то, каким именно способом осуществлялись эти два преобразования. Если прочитать файл, записанный в кодировке KOI8-R, в память и интерпретировать его через CP-1251, мы получим некий «текст» в виде очень странной последовательности русских букв. А если его интерпретировать через CP-1252, получатся «кракозябры», так как в этой странице на месте байт, соответствующих русским буквам находятся всякие буквы с закорючками (диакритическими знаками). При сохранении в юникоде все эти символы останутся «как есть», но станут занимать не один байт, а несколько. При попытке их прочитать в другой кодировке начнутся проблемы.
Но самое печальное происходит, когда в кодировке, в которой сохраняется файл, отсутствует часть символов. В этом случае ничего не остаётся, как заменить их на какой-то «пустой» символ, и часть информации теряется.
Ну раз уж про UTF речь завели, надо было и BOM упомянуть.
Было два выхода, указывать для каждой страницы кодировки, либо создать одну общую для всех символов в мире таблицу символов. Победил второй вариант, так создали Unicode таблицу символов.

К сожалению, до конца проблему необходимости указывать язык/кодировку Unicode не решил. Из-за того, что разработчики Unicode вначале пытались уложиться в 65536 символов, они стали экономить codepoint'ы, присваивая один и тот же codepoint «похожим» иероглифам в разных языках. В итоге в лимит 65536 все равно не уложились, но при этом породили проблему Han unification. Поэтому, чтобы японский текст на Web-странице не выглядел у части пользователей «по-китайски», придется указывать тег 'lang=«ja»'. А для смешанных текстов (например, японско-китайский словарь) Unicode совсем не подходит, придется использовать другую кодировку (ISO2022, TRON и т.п.).
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории