Почему для кодирования одного символа нужен именно 1 байт?
Почему для кодирования 1-го символа нужен именно 1 байт? Я прекрасно понимаю, что минимальная единица информации — 1 бит и чтобы выразить 255 символов в двоичном коде надо использовать 8 бит. И по таблице брать двоичный код и по нему находить нужный символ, но почему каждый символ обязательно занимает 1 байт? Зачем записывать число именно вот так 0000001 , а не просто 1 , тем самым заняв всего 1 бит информации и по таблице взять ему соответствующий символ.
Отслеживать
51.6k 201 201 золотой знак 65 65 серебряных знаков 246 246 бронзовых знаков
задан 1 авг 2018 в 17:23
Никита Антонов Никита Антонов
125 1 1 серебряный знак 9 9 бронзовых знаков
Байт — минимальная адресуемая единица информации. Хранить каждый символ меньше чем в одном байте неэффективно по скорости доступа. А для длительного хранения (при сохранении в файл, например) никто не мешает применить сжатие.
1 авг 2018 в 17:27
@insolor, Use the answer form, Luke!
– user207618
1 авг 2018 в 17:34
Символы не хранят в одном байте уже лет тридцать 🙂
1 авг 2018 в 17:36
А вообще теоретически использовать один бит не разрешает, только вот 11111111 — это один символ (число 255) или восемь символов 1 ? Придётся добавлять дополнительную информацию, поясняющую, как правильно интерпретировать эти единицы. Ну и да, использовать число битов меньшее чем «минимальная адресуемая единица информации» банально неудобно, ибо именно под восьмибитный байт спроектированы все современные компьютеры
1 авг 2018 в 17:39
@andreymal, о спасибо большое! Теперь дошло! Только вот еще вопрос тоесть большие последовательности в зависимости от кодировки делятся на определенное количество байт (1, 2 и тд) и уже по таблице находится определенные символы ?
1 авг 2018 в 17:42
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Не обязательно 1 ..есть кодировки (например utf-16, utf-32 ) где символы по 2 , по 4 байта. тут еще многое зависит от количества кодируемых символов. не всегда хватает 256 вариантов. часто нужно больше.то есть битность напрямую зависит от числа символов в таблице символов. Если влезть в ассемблер, то можно сделать свою таблицу символов. проблема будет только в том что твою кодировку будет понимать только твоя программа. А так просто принятый стандарт, и все. по поводу же адресации, да — опять же стандарт. хотя есть системы , которые работают и 9-ю битами ( старые советские системы связи) , где 9-й бит был или контрольным или знак передавал.
Отслеживать
ответ дан 1 авг 2018 в 17:35
Сергей Петрашко Сергей Петрашко
1,493 8 8 серебряных знаков 15 15 бронзовых знаков
Я наверное неправильно задал вопрос имею в виду почему все символы имеют 1 и тот же размер(тоесть 2 байта или 1), а не так чтобы 1 символ весит больше, а другой меньше, если все равно старшие разряды заполнены нулями (00000001 к примеру)
1 авг 2018 в 17:38
@НикитаАнтонов в кодировке UTF-8 длина одного символа может быть 1, 2, 3 или 4 байта 🙂 А использовать число бит, не кратное восьми, неудобно из-за архитектуры современных компьютеров, заточенных именно на 8 бит
1 авг 2018 в 17:40
будут проблемы с синхронизацией. такая проблема есть в азбуке морзе. то есть трудно понять где закончился один символ и начался второй. поэтому и принято использовать такие битности.
Сколько байт в одном символе?
Чаще всего 1 символ = 1 байт. в кодировке «юникод» 1 символ= 2 байтам.
Новые вопросы в Информатика
створити програму для його обчислення в Pascal. t^2-2tb+b^2 (7 класс)
. СРОЧНО. помогите
7. Напишите программу нахождения суммы четных чисел, находящихся в промежутке от 26 до 88. Используя while
сделайте в excel у меня время до завтра пожалуйстааааааааааа
ПОЖАЛУЙСТА СРОЧНОООО ДАЮ 80 БАЛОВВ
4.3. Кодирование символов. Байт.
На основании одной ячейки информационной ёмкостью 1 бит можно закодировать только 2 различных состояния. Для того чтобы каждый символ, который можно ввести с клавиатуры в латинском регистре, получил свой уникальный двоичный код, требуется 7 бит. На основании последовательности из 7 бит, в соответствии с формулой Хартли, может быть получено N =2 7 =128 различных комбинаций из нулей и единиц, т.е. двоичных кодов. Поставив в соответствие каждому символу его двоичный код, мы получим кодировочную таблицу. Человек оперирует символами, компьютер – их двоичными кодами.
Для латинской раскладки клавиатуры такая кодировочная таблица одна на весь мир, поэтому текст, набранный с использованием латинской раскладки, будет адекватно отображен на любом компьютере. Эта таблица носит название ASCII (American Standard Code of Information Interchange) по-английски произносится [э́ски], по-русски произносится [а́ски]. Ниже приводится вся таблица ASCII, коды в которой указаны в десятичном виде. По ней можно определить, что когда вы вводите с клавиатуры, скажем, символ “*”, компьютер его воспринимает как код 42(10), в свою очередь 42(10)=101010(2) – это и есть двоичный код символа “*”. Коды с 0 по 31 в этой таблице не задействованы.
Юникод и байты
Про Юникод написано много, но мне кажется, что это одна из тем, про которую «чисто ради интереса» никто читать не полезет. Поэтому я решил поделиться здесь одной штукой, которая, как я в разговорах со многими замечал, не всем известна. Речь о том, «сколько байт занимает юникод».
Старые кодировки (например WINDOWS-1251, KOI8-R) совершенно четко определяют, какие конкретные значения одного байта используются для кодирования одного символа (человеческого или служебного). И отсюда вытекает их известная проблема с тем, что они не могут кодировать больше 256 символов. Для того, чтобы с этой проблемой бороться универсально, был придуман Юникод.
Вот дальше идет то самое частое, потому что очень логичное, заблуждение о том, что Юникод — это кодировка, где для каждого символа отводится 2 байта, а значит она может кодировать 65536 символов. Больше того, хоть я и не смотрел специально, кажется именно так она и была задумана в самом начале. Но сейчас все совсем не так.
Довольно быстро возникла необходимость кодировать гораздо больше, чем 65536 символов (чуть больше миллиона сейчас) и, что главное, появилась необходимость кодировать их по-разному. Поэтому в отличие от старых кодировок стандарт Юникода полностью разделяет две вещи:
- номера, присваиваемые символам
- какими байтами эти номера представляются
Номера, присваиваемые символам, полностью абстрактны. Это не байты, не двубайты, а просто числа. Например символу «Заглавная кириллическая буква А» назначен номер 1040, он же — 410 в шестнадцатеричной системе. И формально в Юникоде это принято записывать как U+0410.
А вот способов представлять это число в памяти или записывать в файлы существует больше одного. Называются они «». Вот наиболее распространенные.
UTF’ы
Есть несколько форм кодирования, которые официально входят в стандарт.
В этой форме юникодные символы кодируются одиночными байтами. Но поскольку одного байта для кодирования миллиона символов слегка мало, разные символы кодируются разным количеством байтов. Те, которые входят в старый ASCII, кодируются одним байтом и их значения полностью с ASCII совпадают. Русские и, например, западноевропейские символы кодируются двумя байтами, японские катакана и хирагана — тремя, а есть еще всякая экзотика, где могут быть и четыре байта.
UTF-8 совместим со старым софтом и протоколами, потому что в такой строке не может встретиться байт 0x00 , который бы ее обрывал. Также в большинстве текстов файлов конфигураций и исходников программ, которые традиционно состоят в основном из ASCII, он не занимает сильно больше места, чем ASCII — тот же байт на символ. Еще один плюс — у него нет разных вариантов для разных платформ, он везде одинаковый.
Самый существенный его минус — это то, что по количеству байт в строке невозможно определить ее длину в символах.
UTF-16 (или, что почти одно и то же — UCS-2)
Это, собственно, то, с чего начинался Юникод: для кодирования одного символа используются двухбайтовые целые. Этого хватает для того, чтобы хранить большинство нужных и распространенных на практике символов. И только для редких символов, включенных в Юникод позднее, используются пары двухбайтовых целых.
Кстати, UCS-2 — это как раз UTF-16 без этих дополнительных символов, то есть строго символ = 2 байта.
На практике редкие символы действительно редки (часто встречались с древнегреческой музыкальной грамотой?), поэтому во многих системах для внутреннего представления символов используется именно UTF-16, например в NTFS для имен файлов, в Delphi для WideString’ов, и Java, насколько я знаю, тоже внутри вся в UTF-16 работает со строками.
Однако двухбайтовость делает затруднительным использование UTF-16 для обмена данными из-за двух проблем: наличия нулевых байтов в строке и разночтения порядка следования старшего и младшего байтов на разных платформах.
UTF-32 (или, что почти одно и то же — UCS-4)
Это — форма для перфекционистов. Для представления символа используется строго 4 байта, которыми можно представить абсолютно любой юникодный символ. С недавнего времени тот же Python на большинстве платформ использует именно четырехбайтовое представление для юникодных строк.
Отличия от UCS-4 совсем умозрительные и непрактические.
Минус у этого представления, помимо плохой переносимости, как у UTF-16, еще и в том, что UTF-32 попросту занимает еще больше места.
Другие формы
Помимо UTF’ов, внесенных в стандарт Юникода, существует еще несколько знакомых многим способов представления юникодных номеров.
В первую очередь это XML и HTML со своими А и А . Такое представление, хоть и занимает места еще больше, чем UTF-32 (по 7 байт в двух предыдущих примерах), зато обладает несомненным плюсом в том смысле, что их можно использовать, даже если вы храните сам файл в старой однобайтовой кодировке. А вот если у вас файл и так хранится в одном из юникодных представлений (UTF-8 чаще всего), то в него можно вставлять все стрелочки и кавычечки прямо в UTF-8, которые можно либо взять из charmap’а, либо сам редактор может уметь обрабатывать всякие мудреные комбинации клавиш для этого. Оно и выглядит более читаемо при этом.
Ну и еще напоследок — представление в Javascript. Суть та же, что и у (X|HT)ML’а, только запись другая: \u0410 , \u0160 .
То, что я тут написал — довольно упрощенное прдставление, где я не касался всяких форм нормализации, символов, которые не символы, и прочих «высших и низших суррогатов». Хотя вчера успел совершенно замучить жену цитатами из стандарта Юникода, который читал, чтобы уточнить пару вещей для статьи. Штука, конечно, интересная, но удивительно запутанная. Если кого это все заинтересует, то лучше всего начать со статьи про Юникод в русской Wikipedia (очень хорошая).
Комментарии: 9
Есть ещё UTF-7, а у UTF-8 есть интересная особенность — всегда можно определить находимся ли мы посередине символа или в его начале. Ну и ещё ты забыл упомянуть, что наличие нулевого байта в строке это проблема языков, где строки хранятся как в Cи.
Спасибо, наконец-то я получил толковое объяснение почему так много кодировок называющих себя Юникодом. ))
Замечательный обзор, спасибо.
Зная, что Вы, Иван, знаете Python не понаслышке, хочу спросить о следующем:
В первую очередь это XML и HTML со своими А ;
Есть ли библиотечка, которая переводит все эти
привет питон
в «нормальный» вид, а вот как возник вопрос:
from mechanize import * from BeautifulSoup import * b = Browser() b.open("http://www.translate.ru/text.asp?lang=ru") b.select_form(nr=0) b["source"] = "hello python" html = b.submit().get_data() soup = BeautifulSoup(html) print soup.find("span", ).string А отличный рассказ про разные UTF есть тут
Pak поднял мучающий меня вопрос:) Как в Python перевести HTML и (особенно мучает:)) Javascript-коды в UTF8-строки?
Иван Сагалаев
Честно говоря, никогда не приходилось отдельно коды переводить. Если это HTML или XML, то он парсится парсерами (модуль htmllib и семейство модулей xml.* соответственно). А чтобы парсить javascript’овые строки есть, например, simplejson (с недавних пор включается в django.utils.simplejson, кстати). Делается примерно так:
from simplejson.decoder import JSONDecoder JSONDecoder().decode(r'"\\u0410"') Возвратит питоновскую юникодную строку.
Почему бы на ru.wikipedia.org Вам не добавить этот текст?
Иван Сагалаев
Мне показалось, что там тема проработана глубже, поэтому моя статья и не добавит ничего.
Интересная статья. Как раз столкнулся с проблемой — неизвестная четырехбайтовая кодировка. Первые 2 байта C3 90 или C3 91 (шестнадцатиричные), потом еще 2 байта (очевидно конкретно уточняющие символ). В общем выглядит примерно так — C3 90 C2 BA (один символ). Ни одна из имеющихся программ-перекодировщиков не смогла переварить такое. Не подскажите, что это может быть?