Comments 41
Первая кодировка — это Код Бодо, ну это если не считать Морзянку
3D5 = 00000000 1111010101 (ведущие 10 бит получились нулевые приведем это к шестнадцатиричному числу, получим 0 (первые десять), 3D5 (вторые десять))
Десять или восемь?
1101100000100010 — десятый бит нулевой, значит первый суррогат
1101111010001000 — десятый бит единица, значит второй суррогат
Что-то у меня в обоих случаях десятый бит равен нулю. Или я его не с той стороны отсчитываю? Тогда почему первые 6 отсчитывались с этой же стороны?
> Вопрос с кодировками сейчас конечно уже потерял актуальность
Винда научилась в юникодную кириллицу в терминале?
Винда научилась в юникодную кириллицу в терминале?
Теряет актуальность
Да если бы только в винде дело было (там хоть PowerShell теперь есть). Мы, например, у себя Apache Livy подняли, так там послать в Python (причём в третий, где таких проблем, по идее, быть не должно) что-то не-ASCII невозможно, приходится все строки кодировать через escape-последовательности.
Вот бы ещё такой же подробный разбор про utf8mb4
Тема нормализации не раскрыта :)
Ещё было бы неплохо упомянуть о существовании UTF-16LE / UTF-16BE, а также упомянуть, что UTF-8 всегда кодируется единообразно, несмотря на порядок байт хост системы, в чём несомненный плюс этой кодировки по сравнению с UTF-16.
А я вот не вижу смысла в юникоде в командной строке. Ладно, в pdf или иксовых приложениях — там нужно бывает всякие разные символы отображать, не входящие в КОИ8-Р, но в консоли за глаза хватает восьмибитной кодировки. Да еще и дополнительный бонус: в MAXPATH можно вместить больше символов!
Хорошая статья, но самое сложное в современных текстах осталось за скобками:
графемы, направленность текста, эмодзи и модификаторы (типа цвета кожи).
графемы, направленность текста, эмодзи и модификаторы (типа цвета кожи).
байта (будьте внимательны, если будете переводить символы в двоичную систему с помощью например онлайн конвертера, то первый нулевой ведущий байт может быть отброшен, что может сбить с толку).
Правильнее бит? Почему-то через ctrl+enter не отправить.
если ведущий (первый) бит нулевой
01100101 — первый бит ноль, значит 1 байт кодирует 1 символ -> «e»
Тут надо быть поаккуратнее.
При рассмотрении байта традиционно крайний правый бит считают нулевым, а крайний левый — седьмым.
Автор же вводит понятие «ведущий», да еще и указывает «первый» бит, нарушая общепринятые нормы. В приведенном им примере
01100101
первый бит (если следовать устоявшимся традициям) — это второй справа: 01100101 — я его выделил жирным цветом и подчеркнул.
Далее автор приводит примеры, поясняющие его же слова, и в целом понятно о чем идет речь, но лучше уж следовать общепринятой методологии.
Спасибо автору за статью.
fm-00, Извините, может у Вас есть идея как двоично безопасно перевести байты 128..255
в utf-8, чтобы потом можно их восстановить не указывая исходную кодировку?
Дано двоичный поток байтов от 0 до 255. Надо его конвертировать в UTF-8 и обратно.
\u0-u7f не искажаются, а вот в диапазоне \u80 (& # 128)-\uff (& # 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. Копируешь в него, сохранение, открываешь
файл через некоторое время, и весь текст из непонятной мешанины символов.
В принципе знаешь, что это мог быть сбойный байт или бит оказаться на винте, или при сохранение/чтение ошибка какая в программе из-за всех этих наворотов.
В кодировке такого наворотили, что без начала текста, понять что означает
именно этот кусок байтов нельзя.
За прошлый год несколько раз полностью
рассыпался документ в openOffice. Копируешь в него, сохранение, открываешь
файл через некоторое время, и весь текст из непонятной мешанины символов.
В принципе знаешь, что это мог быть сбойный байт или бит оказаться на винте, или при сохранение/чтение ошибка какая в программе из-за всех этих наворотов.
Надежда была, что я не знал, про какую-то управляющую структуру UTF, типа дальше идет двоичный объект из стольких-то байтов.
Да это была бы хорошая штука, особенно если бы еще и не особо влияла на конечный вес файла, но к сожалению не зная исходной кодировки нет универсального способа, чтобы однозначно ее определить
Чтобы получить детальное понимание этого вопроса придется прочитать и свести воедино не одну статью и потратить довольно значительное время на это.Для детального понимания вопроса наверно будет достаточно всего одной статьи: Краткая история систем кодирования символов естественных языков в США, Европе и Восточно-азиатских странах
А посмотреть на проблему кодировок с точки зрения глобальной политики можно тут: «Проблема кодировок»: стечение обстоятельств или стратегический замысел?
В свое время почему-то безнадежно путался в терминологии.
И все же:
ascii — и таблица и кодировка (или просто кодировки как таковой просто нет)?
кодировка и кодовая страница — синонимы?
И все же:
ascii — и таблица и кодировка (или просто кодировки как таковой просто нет)?
кодировка и кодовая страница — синонимы?
ascii — и таблица и кодировка (или просто кодировки как таковой просто нет)?
тут вы очень хорошо описали чем является ascii это таблица и кодировка (но по факту кодировки нет)
кодировка и кодовая страница — синонимы?
возможно это холиварный вопрос, но все же это не синонимы ну или не всегда это синонимы
ASCII — Американский стандарт… только для 7 бит. Фактически все остальные однобайтовые
кодировки с ним совместимы. Но следует отметить, что все же есть вариации 14 символов
(национальные) 23,24,25,2A,40,5B,5C,5D,5E,60,7B,7C,7E
Из-за совместимости все кодовые страницы базировались на ascii
кодировки с ним совместимы. Но следует отметить, что все же есть вариации 14 символов
(национальные) 23,24,25,2A,40,5B,5C,5D,5E,60,7B,7C,7E
Из-за совместимости все кодовые страницы базировались на ascii
Детали появления UTF-16 жалко не написали. Не понятно, зачем она вообще нужна, если есть UTF-8? Ведь UTF-8 меньше занимает объёма и тоже переменной длины.
Пожалуйста поправьте в строке «2. в результате первого пункта будет получено число не больше FFFF, занимающее до 20 бит»
FFFF на FFFFF
FFFF на FFFFF
На самом деле с кодировками всё не так уж сложно, и я бы рекомендовал прочитать статью Joel Spolsky, или вот эти статьи на хабре: раз и два. Если вкратце, тут не одна проблема, а как минимум две (если оставить в стороне всякие юникодные комбинации и смайлики):
— соответствие элементов языка и управляющих конструкций числам
— способ хранения этих чисел в памяти
По сути, когда заданы два этих отображения, мы уже можем интерпретировать байты в памяти машины как какой-то текст в определенной кодировке. И слово «юникод» на самом деле по своей сути относится к первой из этих проблем, а «UTF-8» или «UTF-16» — ко второй. А дальше возникает проблема в том, что какой-нибудь древний файл представляет из себя поток байт без указания на то, каким именно способом осуществлялись эти два преобразования. Если прочитать файл, записанный в кодировке KOI8-R, в память и интерпретировать его через CP-1251, мы получим некий «текст» в виде очень странной последовательности русских букв. А если его интерпретировать через CP-1252, получатся «кракозябры», так как в этой странице на месте байт, соответствующих русским буквам находятся всякие буквы с закорючками (диакритическими знаками). При сохранении в юникоде все эти символы останутся «как есть», но станут занимать не один байт, а несколько. При попытке их прочитать в другой кодировке начнутся проблемы.
Но самое печальное происходит, когда в кодировке, в которой сохраняется файл, отсутствует часть символов. В этом случае ничего не остаётся, как заменить их на какой-то «пустой» символ, и часть информации теряется.
— соответствие элементов языка и управляющих конструкций числам
— способ хранения этих чисел в памяти
По сути, когда заданы два этих отображения, мы уже можем интерпретировать байты в памяти машины как какой-то текст в определенной кодировке. И слово «юникод» на самом деле по своей сути относится к первой из этих проблем, а «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 и т.п.).
Sign up to leave a comment.
Как работают кодировки текста. Откуда появляются «кракозябры». Принципы кодирования. Обобщение и детальный разбор