КАК РАБОТАЮТ КОДИРОВКИ - ОСНОВЫ ПРОГРАММИРОВАНИЯ

1. Nikolay •
Есть пара ошибок. Порядок байт в UTF-8 не зависит от порядка байт платформы. Подобная зависимость появляется только если отправить в файл число типа больше 1 байта (или область памяти такие числа содержащую) напрямую. UCS-2, UTF-16, UTF-32 представляются как некоторые числа 16 или 32 бита, даже если код использует utf8 напрямую (а не кодирует в неё при записи) байты они и есть байты, endiannes на них не влияет. И BOM в UTF-8 тоже бывает, но используется как сигнатура для автоматического определения кодировки. Виндовый блокнот, например, его добавляет. 10 в начале у второго и последующих байт символа нужны не для определения порядка, они и непригодны для этого, файл может состоять из мегабайта ASCII и в конце будет встречаться один многобайтный символ, определять порядок байтов при начале чтения в таком случае не получится, а проверять при обработке каждого символа накладно. 10 нужен для обработки смещений. Если указатель указывает на байт 10 то получатель понимает, что ему дали смещение, попадающее в середину символа и либо пропустит до следующего начального байта, либо кинет ошибку.
Вторая ошибка - нелюбовь к UTF-8 в качестве внутренних строк связана не со скоростью, а со старым кодом. Код, считающий что может обрабатывать строку как массив и резать поэлементно, брать любое смещение внутри строки и считать длину в символах, он в принципе не пригоден для UTF-8. Строго говоря, он и для других кодировок непригоден, и дело не только в суррогатных парах, в юникоде полно других служебных символов, модификаторов для добавления надсимвольных элементов, индикаторов для BiDi, но на ошибку с этим ещё надо напороться, а подобную проблему в UTF-8 словишь при первом же не-ASCII символе. В новых языках, чьи библиотеки проектируются после появления юникода, в том же Rust например, тупой индексации байт в строковом типе нет, есть посимвольная итерация по строке или перевод строки в массив символов, в итоге в Rust для внутренних строк используется именно UTF-8 и ему норм

2. Mikola •
Думаю, что сложность кодировок символов устраивают нарочно. Чтобы иметь возможность создавать ошибки, и посылать с их помощью сообщения. Отстаивают очень старательно. Нагромождения кодировок. Взять, к примеру, UTF-8. Изначальный стандарт предусматривал длину до 6 байт - чтобы был задел под новые символы. Но в последующем стандарте длину сократили до 4 байт, а фактическое значение кода Юникод - до текущего максимального. Т.е. когда произойдёт очередное расширение Юникод, кодировка UTF-8 станет непригодна :) . Понадобится новая кодировка, и сопутствующие проблемы совместимости :) . Нет сомнений, что нарочно. Поэтому, не удивляйтесь, что суррогатные пары UTF-16 - это так сложно. Это чтобы Вы путались и совершали в программировании этих вещей ошибки. Это ради ошибок.
Нет смысла пытаться создать кодировку с запасом - лишённую этих недостатков. Ей просто не дадут ход.

3. Рустам •
проще было бы создать Троичную и/или Четверичную систему и не мучаться с нехваткой символов Скринте господа Айтишники с моей технологией можно уменьшить все объемы памяти в разы
ПРИМЕР
Двоичная система:
001 - А
010 - Б
100 - В
011 - Г
101 - Д
111 - Е
все, далее уже ограничение, ни чего не создать , а если добавить еще цифру, то выйдет ниже
Троичная система:
001 - А
010 - Б
100 - В
011 - Г
101 - Д
111 - Е
002 - Ё
020 - Ж
200 - З
022 - И
222 - Й
202 - К
012 - Л
102 -
120 -
122 -
121 -
201 -
211
212
221
222
и так далее, ну логику вы поняли, Нужна троичная система
СКРИНТЕ
Я ГЕНИЙ ))

4. Это •
Привет
Подскажи, пожалуйста, по поводу символа П.
На видео ты говоришь, что в юникоде он занимает 11 бит -
100 0001 1111
таким образом мы должны подставить к нему вторую маску: к старшему байту подставляем 110, к младшему - 10. После подстановки у тебя получается число следующего вида:
1101 0000 1001 1111 (что равно D09F).
Я пробовал сделать тоже самое и, у меня получается по-другому:
1100 0100 1001 1111 (что равно С49F)
Отличие заключается в позиции единицы в старшем бите. Не могу понять, почему она сдвинулась у тебя на 2 позиции влево?

5. SoKoL •
Блин играю в одну игру, мышка программируемая. Много макросов писать приходится,а как? Смотря видео геймеров как они пишут ища одинаковые символы подставляя в свои методом тыка и многими проверками в игре. Но теперь немного понятно как это работает, синие строки, черные ,крастные. Автор очень большая просьба объяснить поверхностно про макросы на мышь, я думаю много геймеров на вас подпишется

6. P1ratRuleZZZ •
высший пилотаж в объяснении просто, я хоть и опытный и вроде много всего мучил с кодировками, но все равно познал много нового, в том числе и исторические причины, почему так. Мое введение в кодировки началось с перекидывания контактов в айпод, там я и узнал, что такое яЛП или BOM подпись. круто, надеюсь это посмотрит каждый, кто учится или уже работает в айти сфере

7. Endless •
Ну вот буква а из русского алфавита кодируется как 01100001 в двоичной системе счисления, но ведь буква а может быть отображена разным типом шрифта. буквы это ведь векторная графика и строится каждая буква тэгом <path> внутри svg файла и каждый path в зависимости от семейства шрифта имеет разные данные. в какие двоичные данные кодируется семейство шрифтов?

8. Дэнчик •
Это очень странно говорить про скорость чтения символов и меняться у кого байты короче, когда я вызвал cmd, ввел 21000000 и через пару секунд получит ответ. Неужели нельзя ввести какой-то единый способ кодировки который решит все проблемы? Китайцы уже во всю хреначат 5G, и каждый школьник имеет по террабайту+ места на жёстком диске.

9. CAPTAIN •
Когда проходили это в универе, нам конечно рассказывали про ASCII, но в ролике пропущена интересная часть о том, что у нас была параллельно отечественная КОИ8 а потом и ISO версии кодировок пошли до UTF. На некоторых заводах у нас КОИ8 использовалась очень долго до перехода на юникод. Видимо видео сделано по англоязычной книге.

10. Alexander •
UTF-8 не имеет проблем с порядком байто не потому, что начальный и остальные байты имеют разную структуру, а потому, что code unit здесь - 1 байт. Соответственно никакой проблемы и нет: символ в UTF-8 кодируется последовательностью байт, в то время как в UTF-16 - последовательностью 16-битных слов (а в UTF-16 - одним 32-битным словом)

11. Игорь •
Пришёл сюда в процессе изучения указателей в Паскале по первому тому Столярова. Всё понял, хоть и смотрел на перемотке. Да, вы друг друга сильно дополняете, он преподносит через книгу доходчиво, а вы иллюстрируете так же грамотно. Если бы не учился по этому учебнику, ничего бы не понял вообще. Спасибо большое

12. rasimbot •
Странный пассаж, что создать что-то "универсальное" не удалось. Разве не ясно, что чего-то "универсального" не существует. Либо компактная кодировка, но которая требует больше операций для обработки, либо быстрая, но расточительная по потребной памяти. Везде компромиссы. Не только в кодировке

13. Пуся •
Почему у некоторых символов разные коды Даже в шрифтах разные коды указывают на разные символы Например 'о' и 'o' , 'y' и 'у', 'H' и 'Н' а столько одинаковых букв в разных языках которые можно кодировать одним и тем же номером Кстати тогда бы и цензуру ботов тг было сложнее обходить

14. Владимир •
Может быть кто-нибудь здесь мне подскажет. Если java использует utf-16 , кодировка которая включает в себя кириллицу, как я понимаю, то почему возникает проблема с кодировкой при работе со spring, как бы и сколько бы я не передавал кириллицы на веб страницу она отображается не корректно?

15. Tigran •
Не скажу, что понял все, что объяснял автор, но вы натолкнули меня на некоторые мысли в своей работе - не программирование, но у нас большие проблемы с быстрым перекодираванием в Unicode. Попробую осуществить то, что задумал. Надеюсь, получится. Автору большущий респект))

16. Лев •
А в звуковом всемирном алфавите всего 108 букв и любой язык можно записать этими буквами. Если бы люди думали в этом направлении - 8 бит хватило бы на долго (по крайней мере, для связи, а на пк мог стоять переводчик и любая кодировка)

17. Валерий •
Это видео было как многосерийный фильм, в конце рассказа про очередную кодировку её постигала неудача, а в новой серии появлялась новая кодировка. А в самом конце видео я ждал что будет UTF-64, которая придёт и всех спасёт

18. Misha •

Влепил лайк, подписался, ударил в колокол на все уведомления Это восхитительный материал в одном видео столько ответов на давние вопросы или такие вопросы, которые ещё даже не появились Очень познавательно Благодарю

19. Flamin •
Интересно, а чтение сразу всего файла в переменную (память) в C# через тот же ReadAllText будет быстрее на utf 32?
Или запись в оперативку из-за большего объёма будет не такой уж и быстрой, а потому и смысла нет?

20. Shpilevoy •
Обидно что новые прогеры даже не представляют как это переводить с одной таблицы в другую. Пишеш код, и он работает... а мы, в свое время, парились с буквой Щ в MySQL'e, и не думали что может быть иначе...

21. W. •
Сратые вавилоняне, не смогли насчёт молотка договориться, а я должен теперь за электричество больше теперь платить, потому что на конвертацию кодировок интернетика больше ресурсов требуется.

22. CountryBluesOwl •
Спасибо тебе, очень последовательно и доходчиво обьяснено. Из необходимости обраоботки не английских символов через параметры скрипта пришел к необходимости понимания сути проблемы.

23. PooKan_VoolKaN •
Удивительное совпадение. Вечером посмотрел видео ради интереса. А на следующий день на собеседование попалось задание как раз связанное с кодировкой символов. Спасибо за видео

24. Vasja •
Наткнулся на твой канал, это просто очень круто Я занимаюсь программистом на высоком уровне и даже не задумывался о таких "мелочах". Спасибо что ты мне это объяснил.

25. Albert •
Спасибо огромное Великолепное объяснение Подписался Пожалуйста, делайте больше образовательных видео в таком формате Буду вас поддерживать лайками и комментариями

26. Дарья •
мне кажется для большего охвата просмотров стоило в названии написать ascii, utf-8, utf-16 и тд.. иначе я не понимаю почему так мало просмотров ведь это же просто шедевр

27. Konst •
У вас есть хорошее видео про кеши процессора. при большой разнице в частотах памяти и процессора разница в скорости utf(1632) и utf8 будет более сомнительной.

28. Alexey •
Я правильно понял, что ascii и unicode это таблицы с символами, а utf8 utf16 utf32 это алгоритми/протоколы кодирования/шифрования символов из unicode таблицы? Спасибо