Таблица ASCII полезна. Но знали ли вы, что она ещё красива и изящна?
ASCII по-прежнему с нами; даже если вы передаёте современный Unicode3, то должны знать, что самый популярный формат кодировки UTF-8 специально спроектирован как обратно совместимый с ASCII! Декодировав эту статью как ASCII, вы в целом поймёте её смысл… если закроете глаза на мусорные символы в конце предложений (прим. ред.: имеет смысл только для оригинальной статьи на английском).
1. Связаны с программированием? Ага. Например, геокэшеры, которые хотя бы раз кодировали геокэш с координатами, заданными в двоичном виде (то есть в двоичном представлении ASCII) в данном случае считаются «связанными с программированием».
2. И в книге, и в фильме Марк Уотни разделяет круг рядом с восстановленной станцией Pathfinder на сегменты, соответствующие шестнадцатеричным цифрам от 0 до F, чтобы поворот камеры (выполняемый операторами с Земли) мог передавать пары 4-битных слов. Два 4-битных слова составляют 8-битный байт, который можно декодировать как ASCII, восстановив таким образом связь с Землёй.
3. Например, чтобы отправлять свои любимые эмодзи.
История
Изначально кодировка ASCII была стандартизирована в документе с легко запоминающимся названием X3.4-1963, где было присвоено значение сотне из потенциальных 128 кодовых точек, представляемых в двоичном 7-битном виде4, то есть двоичными значениями от 0000000 до 1111111:
Можно заметить, что в этой первой реализации отсутствует… весь алфавит в нижнем регистре! Есть тут и некоторые странности, на которые могут обратить внимание фанаты современного ASCII, например, любопытные стрелки влево и вправо внизу столбца 101____, а также управляющие коды ACK и ESC в столбце 111____.
4. ASCII многие считают 8-битным кодом, но на самом деле он 7-битный. Поэтому почти в каждом ASCII-сообщении практически все октеты начинаются с нуля. 8 битов удобны для передачи, но первые 8-битные системы чаще всего использовали восьмой бит для проверки чётности, чтобы выявлять ошибки передачи. Разумеется, при этом ничто не мешает передавать один за другим поток 7-битных символов.
Если вы уже догадались, к чему я веду, то вам должно быть интересно взглянуть на таблицу X3.4-1963 и убедиться в том, что многие из тех же изящных решений уже существовали в 1963 году. Это очень круто!
Таблица
На случай, если вы ещё незнакомы с таблицей, давайте рассмотрим её. Я отметил цветом некоторые её части, которые считаю самими красивыми:
В этой таблице показаны только десятеричные и шестнадцатеричные значения символов, но чтобы оценить её красоту, нам понадобятся и двоичные.
▍ Управляющие коды
Первые 32 «символа» (и, можно сказать, последний тоже) мы не можем увидеть, это команды, передаваемые между машинами. Возможно, вам известен «возврат каретки» (carriage return,
0D) и «перевод строки» (line feed, 0A), означающие «вернуться к началу этой строки» и «перейти на следующую строку»5.5. Во времена, когда данные отправлялись телетайпным принтерам, эти два символа имели сильно отличающееся значение; иногда устройства так медленно возвращали головки в левую часть бумаги, что требовалось дополнительно отправлять несколько нулевых байтов, например
0D 0A 00 00 00 00, чтобы печатающая головка точно оказывалась в нужном месте до отправки новых данных: тогда у принтеров ещё не было буферов памяти! Ради совместимости с телетайпами в первых миникомпьютерах соблюдался тот же стандарт «возврат каретки плюс перевод строки» даже при выводе текста на экраны. В дальнейшем для сохранения обратной совместимости уже с этими системами следующее поколение компьютеров тоже для обозначения следующей строки использовало символ возврата каретки и перевода строки. Поэтому даже сегодня многие компьютерные системы (в том числе по большей мере Windows и многие протоколы Интернета) продолжают использовать комбинацию возврата каретки и символа перевода строки каждый раз, когда им нужно перейти на следующую строку; эта избыточность встроена в цепь обратной совместимости, устаревшей уже десятки лет назад, но оставшейся с нами навечно как часть нашего цифрового наследия.Многие из прочих больше широко не используются, они были спроектированы для компьютерных систем, совершенно отличающихся от нынешних, но всё равно присутствуют в таблице.
Число 32 является степенью двойки, то есть можно логично предположить, что эти управляющие коды имеют в своём двоичном виде определённый математический «паттерн», отличающий их от остальной части таблицы. И это действительно так! Все управляющие коды соответствуют паттерну
00_____, то есть начинаются с двух нулей. Поэтому когда мы считываем 7-битный элемент ASCII6, то если он начинается с 00, это непечатаемый символ. Все остальные символы печатаемы.6. Получили 8 двоичных цифр? Вероятно, первая равна нулю. Отбрасываем её. Теперь мы получили 7-битный ASCII. Вот и всё.
Этот паттерн не только упрощает чтение кодировки людьми (таким образом повышая его упорядоченность и усиливая красоту), но и помогает, если вы работаете на древней медленной компьютерной системе, сравнивающей по одному биту информации за раз. В таком случае можно использовать дерево принятия решений для ускорения работы.
Среди управляющих кодов есть одно исключение: DEL, последний символ таблицы, соответствующий двоичному числу
1111111. Это привет из прошлого, когда работа велась с бумажными лентами: для обозначения нулей и единиц клавиатура пробивала комбинации из семи отверстий. Удалять отверстия после их пробивания было нельзя, поэтому единственным способом пометить символ как недействительный была перемотка ленты и пробивание всех отверстий в этой позиции, то есть всех единиц.▍ Пробел
Первый печатаемый символ — это пробел; это невидимый символ, но он всё равно значим для людей, так что это не управляющий символ (сегодня это кажется очевидным, то при изначальном обсуждении стандарта ASCII это вызвало споры о семантике).
Помещение его численно перед всеми печатаемыми символами было очень продуманным и преднамеренным решением. Причина этого заключается в сортировке. Проще всего компьютеру отсортировать список (файлов, строк или чего-то ещё) численным способом, применив ту же таблицу преобразования символов, что и для всего другого7.
7. Я крайне благодарен разделу 13.8 книги Coded Character Sets, History and Development Чарльза Маккензи (1980 год), весь текст которой выложен бесплатно онлайн, за помощь в понимании важности позиции символа пробела в наборе символов ASCII. Основную часть изложенного в посте я уже знал давно, но раньше я не осознавал полностью важность расположения пробела!
Естественнее всего, чтобы символ пробела шёл перед всеми остальными символами, или же в отсортированном компьютером списке John Smith не будет идти перед Johnny Five, как мы того ожидаем.
Кроме того, что это первый печатаемый символ, пробел имеет красивый и запоминающийся двоичный вид, легко узнаваемый человеком:
0100000.▍ Числа
Расположение арабских чисел 0-9 тоже не было совпадением. Их позиция означает, что они начинаются с нуля, находящегося в красивом круглом двоичном значении
0110000 (и аналогично круглом шестнадцатеричном значении 30) и продолжаются последовательно:
Последние четыре разряда двоичного числа описывают значение соответствующей десятеричной цифры. Кроме того, последний разряд шестнадцатеричного числа равен десятеричной цифре. Это просто потрясающе!
Если вы решили использовать этот пост, чтобы научиться мысленно «читать» ASCII в двоичном виде, то следует запомнить такое правило: если символ начинается с
011, то оставшуюся часть числа нужно воспринимать как двоичное представление самого числа. Вероятно, вы не ошибётесь: если получившееся число больше 9, то, скорее всего, это уже какой-то знак препинания.▍ Числа с шифтом
Вычтите
0010000 из каждого числа, и вы получите числа с шифтом. К сожалению, первое уже занято символом пробела, но в случае всех остальных символы являются тем, что вы получаете при одновременном нажатии на клавишу Shift и числовую клавишу.«Но ведь нет!», — воскликнете вы. Да, возможно, вы правы. Я печатаю на 105-клавишной QWERTY-клавиатуре ISO/UK и только четыре из девяти цифр 1-9 правильно отражены в таблице ASCII.
Боюсь, это вызвано тем, что ASCII создан на основе не современных компьютерных клавиатур, а позиций механической пишущей машинки Remington No. 2, раскладка со сдвигом которой, вероятно, в те времена была компромиссом, наиболее близким к стандарту. Но если вас это утешит, то можно сказать, что вы узнали что-то новое о пишущих машинках.
Любопытный факт в нагрузку: в первых механических пишущих машинках не было цифры 1: ожидалось, что вместо неё будет использоваться буква I. Для печати это нормально, но не особо удобно для считываемых компьютером данных.
▍ Буквы
Как и цифры, буквы имеют паттерн. После символа
@ со значением 1000000 все буквы в верхнем регистре начинаются с 10, а далее идёт двоичное представление их позиции в алфавите. 1 = A = 1000001, 2 = B = 1000010 и так далее до 26 = Z = 1011010. Если вы сможете выучить числа позиций букв алфавита, то умеете считать в двоичном коде, и этого будет достаточно, чтобы прочитать любую букву верхнего регистра в ASCII, закодированную в двоичном виде8.8. Я уверен, что вы уже это знаете, но на случай, если вы один из сегодняшних 10000 счастливчиков, скажу, что причина того, что мы называем заглавные и строчные буквы верхним (uppercase) и нижним (lowercase) регистром, связана с печатью в 19-м веке, когда наборный шрифт хранился в коробках (type case) в зависимости от типа символа. Обычно заглавные буквы хранились в верхнем (upper) ящике.
А разобравшись с верхним регистром, легко понять и нижний. Позиция этих символов в таблице означает, что они ровно на
0100000 выше, чем соответствующая буква в верхнем регистре; то есть все буквы в нижнем регистре начинаются с 11! 1 = a = 1100001, 2 = b = 1100010, а 26 = z = 1111010.Возможно, вам непонятно, почему буквы в верхнем регистре идут первыми — причина снова в сортировке; кроме того, первая реализация ASCII, которую мы видели выше, была придумана ещё до того, как стало понятно, что компьютерным системам нужно будет разделять коды символов букв в верхнем и нижнем регистре (можно разработать альтернативную реализацию, которая бы вместо этого, например, передавала управляющие коды, сообщающие получателю о необходимости смены регистра). Учитывая современные технологии, я рад, что в конечном итоге разработчики стандарта выбрали правильное решение.
Красота
ASCII обладает странным неуловимым очарованием. Мы используем этот стандарт (и производные от него) буквально каждый день, поэтому легко подумать, что это просто какая-то произвольная кодировка.
Но решения, принятые при выборе того, какие потоки нулей и единиц будут описывать символы, раскрывают продуманную логику. Она эстетически приятна и усеяна историческими артефактами, позволяющими нам узнать о тайной истории компьютеров. И она построена на основе паттернов, достаточно сложных для упрощения мощных вычислений и в то же время достаточно согласованных для запоминания, изучения и понимания человеком.
Telegram-канал со скидками, розыгрышами призов и новостями IT ?
Комментарии (50)
inkelyad
24.07.2024 13:45+11Меня огорчает, что кто-то в свое время забыл о существовании FILE/GROUP/UNIT/RECORD SEPARATOR и в результате родился уродец, который CSV. Ну и сейчас хорошо бы их применять во многих случаях, когда в строку отдельные части чего-нибудь пытаются уложить - вместо пробелов/запятых/двоеточий
Oangai
24.07.2024 13:45не то что бы кто-то их забыл, но наверное в 63м году проблематика структурирования данных как-то не стояла на повестке, изобретению COBOL на тот момент было всего 3 года как
inkelyad
24.07.2024 13:45но наверное в 63м году проблематика структурирования данных как-то не стояла на повестке, изобретению COBOL на тот момент было всего 3 года как
Так я про позднее. Забыли давно и надежно. Вот какой стандартный (т.е. первый приходящий на ум) формат файла, когда нужно экспортировать несколько таблиц с небинарными данными?
А оно как бы именно при помощи этих символов легко делается и потом столь же легко парсится.
Oangai
24.07.2024 13:45просто структурирование делалось с изобретения Коболя лет 20 только в двоичном виде, текстовые форматы вроде csv обрели популярность только с 80x, когда основные кодировки уже устоялись
inkelyad
24.07.2024 13:45Честно говоря, не понял аргумента.
Мой, если развернуть, приблизительно так будет: Вот есть у нас, скажем, Excel-табличка. Миллиарды их в разных местах.
Нужно ее экспортировать и прочитать чем-то, для чего лень либу чтения самого Excel искать или ее (на тот момент) просто не существовало. Во что эту табличку сохранят? Вот csv будет же с запятыми вместо прочих разделителей. С заметным повышением вероятности что эти данные где-то потом неправильно распарсят.
Oangai
24.07.2024 13:45+1я просто имею в виду про историческое развитие: оно сейчас не очевидно, но когда кодировки вводились, в то время и еще долго потом не стояло проблемы сериализации и структурирования текстовых данных. Проблема, которую вы имеете в виду, скоре в том что в 80х никто не удосужился выработать какой-то общий стандарт для такой сериализации. Ввели кавычки для полей, это понятно, но как тогда экранировать кавычку в самом поле, каким символом? А нужно ли экранировать CR/LF в поле? Стандарта нет, каждый разработчик фантазирует как может.
Исторически, COBOL вообще первый язык который ввёл структуры данных, но они там долгое время все фиксированной длинны и не требовали дополнительной разметки при хранении и передачи данных - программа просто знала, что например первые 20 байт для имени, след. 20 для фамилии, один для пола, итд., так и работали.
Поля переменной длинны хорошо позже возникли, это была целая смена парадигмы, как вообще с данными работать.
Активная работа с текстами в нашем понимании зарождается где-то в академической среде с unix в семидесятых, к 80м достигает массового пользователя в виде текстовых редакторов и табличных процессоров, вот тогда csv и понадобился
inkelyad
24.07.2024 13:45Проблема, которую вы имеете в виду, скоре в том что в 80х никто не удосужился выработать какой-то общий стандарт для такой сериализации.
Так я как раз про то, что на этот момент ASCII с ее сепараторами - была (вот, скажем, 1968 год), т.е. прямо в нее как раз уже были внесены кое-какие средства сериализации. Но ими не воспользовались, а начали использовать вот все эти кавычки и запятые.
Oangai
24.07.2024 13:45+1может кто их и предложил по доброте душевной, но видимо в то время никто не понял зачем это нужно, перед ними другие задачи стояли.
Вообще, вплоть до 90х данными рулил в основном IBM с его майнфреймами, так он там вообще умудрялся спокойно жить с шестью несовместимыми вариантами своей EBCDIC, спал спокойно и совесть не мучила :) Помню, когда в начале 90х изучал Cobol, в руководствах для оператора указывалось что, при необходимости перекодировки в другой формат вроде ascii, для этого к мейнфрейму докупается специальная железка- перекодировщик, а сам он такой мелочью не занимается...
strvv
24.07.2024 13:45Вообще-то здесь бы уместно вставить картинку про ещё один стандарт.
Хотя, как наблюдал программистов 80х и сам начал на zx и позже на pc в 90-е - в процессе написания программ никто не задумывается о стандартах, за исключением, если это изначально не академическая работа с первоначальным планированием, четким контролем что, куда и как использовать...
К слову об таких программах - они спотыкаются об человеческий фактор и всё равно в коде видим трэш и угар от конкретного кодера.
Единственное, что я наблюдал красивое - это руководство от DEC по написанию кода, там на пальцах прививали красивое и простое написание кода.
vadimr
24.07.2024 13:45+4Исторически всё хранилось в фиксированном формате, строго по позициям. Поэтому никакие разделители были не нужны. Просмотрите на ввод-вывод в Коболе и Фортране. Тратить ресурсы процессора на распознавание длины элемента было слишком дорого, просто тупо копировалось фиксированное количество байтов между устройством и памятью.
N-Cube
24.07.2024 13:45+6Как спецсимволы с клавиатуры вводить и в распечатке показывать? Даже с табами в качестве разделителей и в наше время многие пользователи не понимают, как их посмотреть и вставить и чем они от пробелов отличаются.
inkelyad
24.07.2024 13:45Приблизительно все текстовые редакторы (кроме уж совсем-совсем тупых) умели и умеют работать с непечатными символами. Кроме того, файлы сериализации/импорта/экспорта, в общем, и не предполагаются для распечатки и лишь условно предполагаются для чтения. Когда кто-то csv делает - это не для того, чтобы читать и редактировать (это прямо в Excel делать хорошо), оно в подавляющем случае для того, чтобы в какую-то другую программу втянуть.
как их посмотреть и вставить и чем они от пробелов отличаются.
И тут эти сепараторы как раз хороши - потому что они на отображении отличаются.
sotland
24.07.2024 13:45Так какой символ считаете нужно было использовать вместо ,
Oangai
24.07.2024 13:45+3не то что вместо, человек скорее удивляется (вполне заслуженно) что специальные символы для этого даже одно время были предусмотрены, но потом их забыли как-то.
strvv
24.07.2024 13:45Это обычный человеческий фактор, более того, в виду популярных тогда терминальных рабочих мест и не совсем правильного распознавания и сложного ввода этих символов было каким-то сейчас безвестным программистом принято решение использовать запятую или другой разделитель.
Не нужно искать тайную ложу, скорее просто человеческая лень.
sotland
24.07.2024 13:45Если символа нет на клавиатуре и его не будет видно в редакторе, то потеряется самый цимус от csv...
Oangai
24.07.2024 13:45на самом деле графическое представление у них всегда было (такие смешные стрелочки), и ввести любой код ascii можно было на клавиатуре, с самого 81-го года, это была фирменная фишка IBM PC и его потомков: удерживая нажатым левый alt набрать 2-3 десятичных цифры. Другое дело, что csv был удобен тем что его можно в виде таблицы и в текст вставить, и из чужого текста выделить и скопировать. Если бы эти символы имели визуально хоть какое-то отношение к таблицам, может люди даже бы про них и помнили, всетаки у них коды короткие и запоминаются легко. А так, если уж вспоминали про подходящие визуально символы, то брали из блока псевдографики, от 179 и дальше. Но держать их в голове уже трудно было, да и набирать дольше, особенно когда много колонок в таблице.
inkelyad
24.07.2024 13:45Так какой символ считаете нужно было использовать вместо ,
Цитата из описания:
FS (File Separator), GS (Group Separator), RS (Record Separator), and US (Unit Separator): These information separators may be used within data in optional fashion, except that their hierarchical relationship shall be: FS is the most inclusive, then GS, then RS, and US is least inclusive. (The content and length of a File, Group, Record, or Unit are not specified.)
Вместо запятой, соответственно(которая разделитель столбцов таблицы) - Unit Separator.
Oangai
24.07.2024 13:45Кстати, вот: https://www.rfc-editor.org/rfc/rfc20 - вполне конкретно определяет назначение всех управляющих символов, 69-й год. Похоже что изобретателям csv не очень интересно было во всякие эти RFC заглядывать.
С другой стороны, этот RFC ведь определяет не формат файла, а формат обмена по сети; для кого-то это могло быть достаточной причиной не захотеть его для файлов использовать.
Razoomnick
24.07.2024 13:45И возникает еще один вопрос, не будет ли коллизий при работе с файлами через терминал? Когда управляющий символ одновременно является и командой для терминала, и символом, который нужно напечатать в файле?
kuzzdra
24.07.2024 13:45+2csv можно править в любом текстовом редакторе. Ввести запятую - легко, вот она на клавиатуре. Как ввести Unit Separator?
Да, можно было бы изобрести клавиатуру с дополнительными кнопками, нашлось место для PgUp/PgDn - нашлось бы и для Separator. Но клавиатуры проектировали другие люди.inkelyad
24.07.2024 13:45Уже в который раз указываю, что csv это - промежуточный формат для переноса несовместимых бинарных.
Как ввести Unit Separator?
При программировании - вообще их литералами писать не надо. При редактировании файла - Ctrl-C -- Ctrl-V любого близкостоящего из того же файла или эквивалент. Но вот честно - ну вот зачем эти csv в принципе редактировать до такой степени может понадобиться? Часто такое надо? Мне, практически всегда, когда это (ручная правка сепараторов) делать приходилось - так это как раз чтобы разные кавычки расставить/убрать, запятые на табуляцию заменить или еще что-нибудь такое чтобы парсеры потом не ломались.
sotland
24.07.2024 13:45+1Прелесть csv именно в том что его можно отредактировать в ЛЮБОМ текстовом редакторе. Причём принцип "явности" - что вижу то и имею, крайне приятен и полезен.
По тем или иным причинам, работа с csv может происходить не только через программы, но и именно руками. Опять таки именно потому, что его можно читать и редактироватьinkelyad
24.07.2024 13:45По тем или иным причинам, работа с csv может происходить не только через программы, но и именно руками.
Можно все-таки сценарий, когда это руками удобней делать, а не предварительно втянув в программу, предназначенную для редактирования таблиц. Причем именно такой, когда разделители набирать надо.
Причём принцип "явности" - что вижу то и имею, крайне приятен и полезен.
Как-то мне неочевидно, что видеть
"Папка ""Цветы"", прозрачная","12,4"Как-то сильно понятнее и приятнее чем
Папка "Цветы", прозрачная12,4или даже на текстовом терминале (как у меня совершенно текстовый Vim показывает, подсвечивая непечатные символы)
Или, в notepad++
kuzzdra
24.07.2024 13:45Можно все-таки сценарий, когда это руками удобней делать, а не предварительно втянув в программу, предназначенную для редактирования таблиц.
Ну, вернитесь мысленно в 70-е годы. Excel и Supercalc еще не изобретены. А данные уже существуют.
inkelyad
24.07.2024 13:45(вспоминая, как в свое время работал на настоящих, железных алфафитно-символьных терминалах)
Ни за что не поверю, что эти данные хоть как-то вводились и редактировались в текстовом редакторе. Обычно какая-то формочка была "Выберете 1, чтобы отредактировать имя, 2-чтобы редактировать цену" и так далее.
DrZlodberg
24.07.2024 13:45Ну вот я регулярно правлю. А ещё удобно смотреть файл когда под рукой случайно нет офиса. Хоть на телефоне. Кнопочном.
В те времена ещё активно использовались терминалы с их управляющими символами. Ещё были модемы с текстовыми протоколами. И принтеры, на которые можно было просто кинуть текст.
Ну и собственно основная задача - это именно текстовый файл без невидимых символов. Например тот же RTF это, по своей сути, DOC в текстовой версии. Да и куча их. Даже сейчас, если покопаться, есть прорва современных форматов в текстовой и бинарной версии. Это удобно.
redsh0927
24.07.2024 13:45+1CSV - такой же "уродец", как и все текстовые форматы...
Предлагаемый вариант с управляющими символами - как раз настоящий уродец. Толком и не текстовый формат и не бинарный. Зато сочитающий недостатки обоих.
inkelyad
24.07.2024 13:45+1Ну не знаю. Польза от условной текстовости (т.к. как бы пригодно для редактирования в текстовом редакторе) - сомнительна. Достаточно пару раз проредактировать csv с разной длиной полей, содержащих кавычки и запятые., чтобы убедиться. А проблемы с тем, как экранировать кавычки и не запутаться при наборе и парсинге - вроде, достаточно очевидны.
Oangai
24.07.2024 13:45+2вообще, если кому интересно, предыстория сабжа:
https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B4_%D0%91%D0%BE%D0%B4%D0%BE
https://ru.wikipedia.org/wiki/%D0%9C%D0%A2%D0%9A-2
Телетайпы с МТK-2 я еще застал на своей первой работе, начало 90х, забавные были агрегаты
ImagineTables
24.07.2024 13:45+3Любопытный факт в нагрузку: в первых механических пишущих машинках не было цифры 1: ожидалось, что вместо неё будет использоваться буква I. Для печати это нормально, но не особо удобно для считываемых компьютером данных.
А что, идея хороша. Можно сделать такой ЯП, где из контекста должно выводиться, цифра у нас или буква:
if (I0 == 1O) // Компилятор: "Не знаю, что вы имели в виду, но это точно true!" { I = 0; O = 1; // Happy debugging, bitches! 0x = Ox; // Ошибка: не хватает значащих цифр! (Справа от =, если что). }Oangai
24.07.2024 13:45+2вот, для развития идеи :)
http://p-nand-q.com/programming/languages/java2k/manual.html
Alikberov
24.07.2024 13:45+1Как-то размышлял на тему и даже пытался работать над темой ("перезагрузить ASCII" в рамках пилотной архитектуры) и могу сказать, что ИМХО, в таблице ASCII имеется ряд недостатков:
Первое: 32 управляющего кода - слишком много. Сейчас это - "мёртвый груз", так как большинство кодов безнадёжно морально устарело. Остаются популярными и достаточными лишь 00, 0D и 1B.
Второе: Недостаточная "интуитивность" кодировки (особенно, для начинающих программистов). Почему цифра "1" и знак "!" располагаются на одной линии, а цифра "7" и знак "?" - нет, хотя они графически похожи, как "5" и "$", как "8" и "&"?
(То есть, вместо «!"#$%&'()» "интуитивнее" было бы «!%#^$(?&)»: Делал как-то подобную раскладку у себя в системе. Быстро переучиваешься, привыкаешь.)
matwel
24.07.2024 13:45Раз уж пошла такая "пьянка", выскажу и я своё мнение (понятно что очень спорное) не о коде символов, а о клавише "Caps Lock" (о клавишах пишущей машинки в статье речь шла, однако).
Когда у меня запущено/открыто несколько программ или несколько документов, бывает надо периодически переходить то на одну/один, то на другую/другой. Понятно, что один документ я набираю на русском языке, другой скажем на английском, и переходя между документами у меня нет необходимости опять выбирать раскладку. Раскладка меняется автоматически.
Но до чего же выбешивает иногда общий для всех документов/программ "Caps Lock". Неужели сейчас нет возможности привязать его состояние для каждого документа/программы индивидуально, что бы не приходилось потом править фрагмент текста с ошибочным регистром, установленным в предыдущем документе/программе
vadimr
24.07.2024 13:45+2Тут такое дело. Раскладка – это просто программный флажок, а Caps Lock – аппаратный триггер в клавиатуре. Он ничего не знает об окнах. Можно, конечно, его переключать со стороны компьютера, но тогда пойдёт рассинхронизация при сбоях связи, особенно на блютузе. Буквы при перебоях со связью просто в буфере копятся, а с этим так не выйдет.
VBKesha
24.07.2024 13:45+1Вообще если подключить к компу две клавиатуры то они отлично синхронизируют этот самый Caps Lock между собой, и даже с экранной клавиатурой. Также под линуксом слышал что народ часто вешает переключение раскладок на этот самый Caps Lock. Ну и я не особо вдавался в протоколы работы клавиатуры, но из того что я помню, клавиши шлют скан коды, при нажатии отпускании кнопок. И вот CAPS если я правильно помню ни как на это не влияет, то есть он просто работает как обычная кнопка. Индикаторы, если я не ошибаюсь опять же включаются/выключаются драйвером клавиатуры(если система мертво висит то индикаторы не реагируют на клавиатуру.), Так что выходит что Caps Lock вполне себе такой же программный флажек.
Alikberov
24.07.2024 13:45У меня на Scroll Lock переключение раскладок висит: Это удобнее, так как Caps Lock тоже нужен в ряде случаев программирования, а Scroll Lock - тоже давно устаревший триггер. И находится уже вне основной части клавиатуры.
firehacker
24.07.2024 13:45С чего он устаревший? Постоянно пользуюсь (да хотя бы в Excel) и в своих собственных программах обязательно делаю поддержку Scroll Lock.
Genrehopper
24.07.2024 13:45сколько не пробывал нажимать эту кнопку, так и не понял как она работает (а работает ли вообще?) Какой эффект должен быть? Судя по названию должен заблокироватья скрол страницы/листа, но этого не происходит
Themen
24.07.2024 13:45При навигации стрелками на клавиатуре, при включённом ScrollLock происходит блокировка перемещения курсора и делается просто пролистывание документа. В MS Word не работает, но в MS Excel всё нормально. Попробуйте открыть какой-нибудь большую таблицу в Excel. Если ScrollLock не включён, то стрелки на клавиатуре перемещают по ячейкам, а если включён, то прокручивают таблицу.
firehacker
24.07.2024 13:45Scroll Lock выключен: стрелки, Home, End, PageUp, PageDown меняют положение текущего выделения (положение каретки, выделенную ячейку, строку, иной элемент, в зависимости от сути контрола).
Scroll Lock включен: стрелки, Home, End, PageUp, PageDown управляют прокруткой.
Dr_Faksov
24.07.2024 13:45Caps Lock сейчас программно - аппаратный. Можно управлять с компьютера. Но приоритет имеет физическая кнопка.
А вообще он настолько древний...
GBR-613
24.07.2024 13:45+3Все познаётся в сравнении. Чтобы понять величие ASCII, сравните её с EBCDIC.
questfulcat
24.07.2024 13:45+2Красота - это конечно хорошо, но вот из-за такого интервального расположения групп цифр, больших букв и малых букв, пространство между ними набили разными значками (всякие скобки, больше, меньше и т.д.), которые могут являться управляющими символами в разных языках, например значки больше и меньше - края тегов в html.
А как бы красиво смотрелся алгоритм кодирования Base64 если бы набор цифр и букв обоих регистров в ASCII шёл последовательно, без лишних вкраплений. Буквально в одну строчку можно было бы кодировщик сделать, а не через таблицу или кучу ветвлений. И был бы он куда производительнее. Так что, всё зависит от позиции наблюдателя, или, как говорится, красота в глазах смотрящего.
dlinyj
Здесь не хватает описание что же такое ASCII (англ. American standard code for information interchange). А весь восторг прекрасно изложен в русской википедии ASCII
Забавно, что когда много работаешь с ней, то на память уже знаешь многие символы. Например пробел 0x20, любое число - это число + 0x30, ESC 0xB1 или \033.
Oangai
мне когда-то приходилось много умножать в уме в шестнадцатеричной системе, когда в hex-кодах для 8080 программировал. Распечатка этой таблички перед глазами очень помагала, был определённый алгоритм в голове, чтобы не сбиваться