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

Красота и изящество таблицы ASCII

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров14K
Всего голосов 54: ↑53 и ↓1+73
Комментарии66

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

Здесь не хватает описание что же такое ASCII (англ. American standard code for information interchange). А весь восторг прекрасно изложен в русской википедии ASCII

Забавно, что когда много работаешь с ней, то на память уже знаешь многие символы. Например пробел 0x20, любое число - это число + 0x30, ESC 0xB1 или \033.

мне когда-то приходилось много умножать в уме в шестнадцатеричной системе, когда в hex-кодах для 8080 программировал. Распечатка этой таблички перед глазами очень помагала, был определённый алгоритм в голове, чтобы не сбиваться

А я до сих пор помню это всё и в восьмеричной системе, в эпоху СМ/ЕС ЭВМ она была сильно популярнее шестнадцатеричной.

Меня огорчает, что кто-то в свое время забыл о существовании FILE/GROUP/UNIT/RECORD SEPARATOR и в результате родился уродец, который CSV. Ну и сейчас хорошо бы их применять во многих случаях, когда в строку отдельные части чего-нибудь пытаются уложить - вместо пробелов/запятых/двоеточий

не то что бы кто-то их забыл, но наверное в 63м году проблематика структурирования данных как-то не стояла на повестке, изобретению COBOL на тот момент было всего 3 года как

но наверное в 63м году проблематика структурирования данных как-то не стояла на повестке, изобретению COBOL на тот момент было всего 3 года как

Так я про позднее. Забыли давно и надежно. Вот какой стандартный (т.е. первый приходящий на ум) формат файла, когда нужно экспортировать несколько таблиц с небинарными данными?

А оно как бы именно при помощи этих символов легко делается и потом столь же легко парсится.

просто структурирование делалось с изобретения Коболя лет 20 только в двоичном виде, текстовые форматы вроде csv обрели популярность только с 80x, когда основные кодировки уже устоялись

Честно говоря, не понял аргумента.

Мой, если развернуть, приблизительно так будет: Вот есть у нас, скажем, Excel-табличка. Миллиарды их в разных местах.

Нужно ее экспортировать и прочитать чем-то, для чего лень либу чтения самого Excel искать или ее (на тот момент) просто не существовало. Во что эту табличку сохранят? Вот csv будет же с запятыми вместо прочих разделителей. С заметным повышением вероятности что эти данные где-то потом неправильно распарсят.

я просто имею в виду про историческое развитие: оно сейчас не очевидно, но когда кодировки вводились, в то время и еще долго потом не стояло проблемы сериализации и структурирования текстовых данных. Проблема, которую вы имеете в виду, скоре в том что в 80х никто не удосужился выработать какой-то общий стандарт для такой сериализации. Ввели кавычки для полей, это понятно, но как тогда экранировать кавычку в самом поле, каким символом? А нужно ли экранировать CR/LF в поле? Стандарта нет, каждый разработчик фантазирует как может.

Исторически, COBOL вообще первый язык который ввёл структуры данных, но они там долгое время все фиксированной длинны и не требовали дополнительной разметки при хранении и передачи данных - программа просто знала, что например первые 20 байт для имени, след. 20 для фамилии, один для пола, итд., так и работали.

Поля переменной длинны хорошо позже возникли, это была целая смена парадигмы, как вообще с данными работать.

Активная работа с текстами в нашем понимании зарождается где-то в академической среде с unix в семидесятых, к 80м достигает массового пользователя в виде текстовых редакторов и табличных процессоров, вот тогда csv и понадобился

Проблема, которую вы имеете в виду, скоре в том что в 80х никто не удосужился выработать какой-то общий стандарт для такой сериализации.

Так я как раз про то, что на этот момент ASCII с ее сепараторами - была (вот, скажем, 1968 год), т.е. прямо в нее как раз уже были внесены кое-какие средства сериализации. Но ими не воспользовались, а начали использовать вот все эти кавычки и запятые.

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

Вообще, вплоть до 90х данными рулил в основном IBM с его майнфреймами, так он там вообще умудрялся спокойно жить с шестью несовместимыми вариантами своей EBCDIC, спал спокойно и совесть не мучила :) Помню, когда в начале 90х изучал Cobol, в руководствах для оператора указывалось что, при необходимости перекодировки в другой формат вроде ascii, для этого к мейнфрейму докупается специальная железка- перекодировщик, а сам он такой мелочью не занимается...

Вообще-то здесь бы уместно вставить картинку про ещё один стандарт.

Хотя, как наблюдал программистов 80х и сам начал на zx и позже на pc в 90-е - в процессе написания программ никто не задумывается о стандартах, за исключением, если это изначально не академическая работа с первоначальным планированием, четким контролем что, куда и как использовать...

К слову об таких программах - они спотыкаются об человеческий фактор и всё равно в коде видим трэш и угар от конкретного кодера.

Единственное, что я наблюдал красивое - это руководство от DEC по написанию кода, там на пальцах прививали красивое и простое написание кода.

Исторически всё хранилось в фиксированном формате, строго по позициям. Поэтому никакие разделители были не нужны. Просмотрите на ввод-вывод в Коболе и Фортране. Тратить ресурсы процессора на распознавание длины элемента было слишком дорого, просто тупо копировалось фиксированное количество байтов между устройством и памятью.

Как спецсимволы с клавиатуры вводить и в распечатке показывать? Даже с табами в качестве разделителей и в наше время многие пользователи не понимают, как их посмотреть и вставить и чем они от пробелов отличаются.

Приблизительно все текстовые редакторы (кроме уж совсем-совсем тупых) умели и умеют работать с непечатными символами. Кроме того, файлы сериализации/импорта/экспорта, в общем, и не предполагаются для распечатки и лишь условно предполагаются для чтения. Когда кто-то csv делает - это не для того, чтобы читать и редактировать (это прямо в Excel делать хорошо), оно в подавляющем случае для того, чтобы в какую-то другую программу втянуть.

как их посмотреть и вставить и чем они от пробелов отличаются.

И тут эти сепараторы как раз хороши - потому что они на отображении отличаются.

Так какой символ считаете нужно было использовать вместо ,

не то что вместо, человек скорее удивляется (вполне заслуженно) что специальные символы для этого даже одно время были предусмотрены, но потом их забыли как-то.

Это обычный человеческий фактор, более того, в виду популярных тогда терминальных рабочих мест и не совсем правильного распознавания и сложного ввода этих символов было каким-то сейчас безвестным программистом принято решение использовать запятую или другой разделитель.

Не нужно искать тайную ложу, скорее просто человеческая лень.

Если символа нет на клавиатуре и его не будет видно в редакторе, то потеряется самый цимус от csv...

на самом деле графическое представление у них всегда было (такие смешные стрелочки), и ввести любой код ascii можно было на клавиатуре, с самого 81-го года, это была фирменная фишка IBM PC и его потомков: удерживая нажатым левый alt набрать 2-3 десятичных цифры. Другое дело, что csv был удобен тем что его можно в виде таблицы и в текст вставить, и из чужого текста выделить и скопировать. Если бы эти символы имели визуально хоть какое-то отношение к таблицам, может люди даже бы про них и помнили, всетаки у них коды короткие и запоминаются легко. А так, если уж вспоминали про подходящие визуально символы, то брали из блока псевдографики, от 179 и дальше. Но держать их в голове уже трудно было, да и набирать дольше, особенно когда много колонок в таблице.

Вы представляете себе возможности редактора способные сделать замену спец-символа набираемого через Alt+171 на спец-символ Alt+172
И сложность в поиске строки в которой случайно поставили один раз Alt+180 вместо Alt+171 если все они отображаются как смешные стрелочки
Всё это нужно в MS DOS c учётом резидентной програмки подкладывающей нужную раскладку для корректного отображения латиницы. На дворе 1988 год если чё

Так какой символ считаете нужно было использовать вместо ,

Цитата из описания:

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.

Кстати, вот: https://www.rfc-editor.org/rfc/rfc20 - вполне конкретно определяет назначение всех управляющих символов, 69-й год. Похоже что изобретателям csv не очень интересно было во всякие эти RFC заглядывать.

С другой стороны, этот RFC ведь определяет не формат файла, а формат обмена по сети; для кого-то это могло быть достаточной причиной не захотеть его для файлов использовать.

И возникает еще один вопрос, не будет ли коллизий при работе с файлами через терминал? Когда управляющий символ одновременно является и командой для терминала, и символом, который нужно напечатать в файле?

csv можно править в любом текстовом редакторе. Ввести запятую - легко, вот она на клавиатуре. Как ввести Unit Separator?
Да, можно было бы изобрести клавиатуру с дополнительными кнопками, нашлось место для PgUp/PgDn - нашлось бы и для Separator. Но клавиатуры проектировали другие люди.

Уже в который раз указываю, что csv это - промежуточный формат для переноса несовместимых бинарных.

 Как ввести Unit Separator?

При программировании - вообще их литералами писать не надо. При редактировании файла - Ctrl-C -- Ctrl-V любого близкостоящего из того же файла или эквивалент. Но вот честно - ну вот зачем эти csv в принципе редактировать до такой степени может понадобиться? Часто такое надо? Мне, практически всегда, когда это (ручная правка сепараторов) делать приходилось - так это как раз чтобы разные кавычки расставить/убрать, запятые на табуляцию заменить или еще что-нибудь такое чтобы парсеры потом не ломались.

Прелесть csv именно в том что его можно отредактировать в ЛЮБОМ текстовом редакторе. Причём принцип "явности" - что вижу то и имею, крайне приятен и полезен.
По тем или иным причинам, работа с csv может происходить не только через программы, но и именно руками. Опять таки именно потому, что его можно читать и редактировать

По тем или иным причинам, работа с csv может происходить не только через программы, но и именно руками. 

Можно все-таки сценарий, когда это руками удобней делать, а не предварительно втянув в программу, предназначенную для редактирования таблиц. Причем именно такой, когда разделители набирать надо.

Причём принцип "явности" - что вижу то и имею, крайне приятен и полезен.

Как-то мне неочевидно, что видеть

"Папка ""Цветы"", прозрачная","12,4"

Как-то сильно понятнее и приятнее чем

Папка "Цветы", прозрачная12,4

или даже на текстовом терминале (как у меня совершенно текстовый Vim показывает, подсвечивая непечатные символы)

Или, в notepad++

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

Ну, вернитесь мысленно в 70-е годы. Excel и Supercalc еще не изобретены. А данные уже существуют.

(вспоминая, как в свое время работал на настоящих, железных алфафитно-символьных терминалах)

Ни за что не поверю, что эти данные хоть как-то вводились и редактировались в текстовом редакторе. Обычно какая-то формочка была "Выберете 1, чтобы отредактировать имя, 2-чтобы редактировать цену" и так далее.

  1. Ну вот я регулярно правлю. А ещё удобно смотреть файл когда под рукой случайно нет офиса. Хоть на телефоне. Кнопочном.

  2. В те времена ещё активно использовались терминалы с их управляющими символами. Ещё были модемы с текстовыми протоколами. И принтеры, на которые можно было просто кинуть текст.

  3. Ну и собственно основная задача - это именно текстовый файл без невидимых символов. Например тот же RTF это, по своей сути, DOC в текстовой версии. Да и куча их. Даже сейчас, если покопаться, есть прорва современных форматов в текстовой и бинарной версии. Это удобно.

Папка "Цветы", прозрачная12,4
Глядя на это, я 'вижу' 3 колонки если там вообще разделитель ','
А в встоенном редакторе Norton как эти символы непечатные отображаются?
1-й сценарий: есть файл CSV который не грузится в программу, например она не поддерживает разделитель этот
2-й сценарий: есть CSV и где-то нужно поправить данные, находим поиском строку и меняем. При этом наличие возможности удобной в Vim или notepad++ не может являться основанием, поскольку есть хоть одна программа которая не отображает эти символы

TSV?

Претензии те же самые, что и у csv, только слово "запятая" нужно заменить на "таб"

Нет, в отличие от CSV, он куда более прост и однозначен - потому что в самих данных не может быть Tab (соответственно нет всех проблем совместимости диалектов CSV). Так что он наиболее близок к использованию тех самых символов, да.

Я бы не был столь уверен, что в данных никогда не встретится tab

Ох уж мне эти изобретатели... |, конечно же!

CSV - такой же "уродец", как и все текстовые форматы...

Предлагаемый вариант с управляющими символами - как раз настоящий уродец. Толком и не текстовый формат и не бинарный. Зато сочитающий недостатки обоих.

Ну не знаю. Польза от условной текстовости (т.к. как бы пригодно для редактирования в текстовом редакторе) - сомнительна. Достаточно пару раз проредактировать csv с разной длиной полей, содержащих кавычки и запятые., чтобы убедиться. А проблемы с тем, как экранировать кавычки и не запутаться при наборе и парсинге - вроде, достаточно очевидны.

вообще, если кому интересно, предыстория сабжа:

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х, забавные были агрегаты

Любопытный факт в нагрузку: в первых механических пишущих машинках не было цифры 1: ожидалось, что вместо неё будет использоваться буква I. Для печати это нормально, но не особо удобно для считываемых компьютером данных.

А что, идея хороша. Можно сделать такой ЯП, где из контекста должно выводиться, цифра у нас или буква:

if (I0 == 1O) // Компилятор: "Не знаю, что вы имели в виду, но это точно true!"
{
    I = 0;
    O = 1; // Happy debugging, bitches!
    0x = Ox; // Ошибка: не хватает значащих цифр! (Справа от =, если что).
}

Очень напоминает kdb+ по духу (не по синтаксису). :))

Как-то размышлял на тему и даже пытался работать над темой ("перезагрузить ASCII" в рамках пилотной архитектуры) и могу сказать, что ИМХО, в таблице ASCII имеется ряд недостатков:
Первое: 32 управляющего кода - слишком много. Сейчас это - "мёртвый груз", так как большинство кодов безнадёжно морально устарело. Остаются популярными и достаточными лишь 00, 0D и 1B.
Второе: Недостаточная "интуитивность" кодировки (особенно, для начинающих программистов). Почему цифра "1" и знак "!" располагаются на одной линии, а цифра "7" и знак "?" - нет, хотя они графически похожи, как "5" и "$", как "8" и "&"?
(То есть, вместо «!"#$%&'()» "интуитивнее" было бы «!%#^$(?&)»: Делал как-то подобную раскладку у себя в системе. Быстро переучиваешься, привыкаешь.)

Почему цифра "1" и знак "!" располагаются на одной линии, а цифра "7" и знак "?" - нет, хотя они графически похожи, как "5" и "$", как "8" и "&"?

Причему тут ASCII?

Почему мёртвым? Никто не запрещает использовать их в своих форматах и протоколах (например, при требовании быть совместимыми с NUL-terminated строками Си); терминалы опять же до сих пор используют их.

Раз уж пошла такая "пьянка", выскажу и я своё мнение (понятно что очень спорное) не о коде символов, а о клавише "Caps Lock" (о клавишах пишущей машинки в статье речь шла, однако).

Когда у меня запущено/открыто несколько программ или несколько документов, бывает надо периодически переходить то на одну/один, то на другую/другой. Понятно, что один документ я набираю на русском языке, другой скажем на английском, и переходя между документами у меня нет необходимости опять выбирать раскладку. Раскладка меняется автоматически.

Но до чего же выбешивает иногда общий для всех документов/программ "Caps Lock". Неужели сейчас нет возможности привязать его состояние для каждого документа/программы индивидуально, что бы не приходилось потом править фрагмент текста с ошибочным регистром, установленным в предыдущем документе/программе


Тут такое дело. Раскладка – это просто программный флажок, а Caps Lock – аппаратный триггер в клавиатуре. Он ничего не знает об окнах. Можно, конечно, его переключать со стороны компьютера, но тогда пойдёт рассинхронизация при сбоях связи, особенно на блютузе. Буквы при перебоях со связью просто в буфере копятся, а с этим так не выйдет.

Вообще если подключить к компу две клавиатуры то они отлично синхронизируют этот самый Caps Lock между собой, и даже с экранной клавиатурой. Также под линуксом слышал что народ часто вешает переключение раскладок на этот самый Caps Lock. Ну и я не особо вдавался в протоколы работы клавиатуры, но из того что я помню, клавиши шлют скан коды, при нажатии отпускании кнопок. И вот CAPS если я правильно помню ни как на это не влияет, то есть он просто работает как обычная кнопка. Индикаторы, если я не ошибаюсь опять же включаются/выключаются драйвером клавиатуры(если система мертво висит то индикаторы не реагируют на клавиатуру.), Так что выходит что Caps Lock вполне себе такой же программный флажек.

У меня на Scroll Lock переключение раскладок висит: Это удобнее, так как Caps Lock тоже нужен в ряде случаев программирования, а Scroll Lock - тоже давно устаревший триггер. И находится уже вне основной части клавиатуры.

С чего он устаревший? Постоянно пользуюсь (да хотя бы в Excel) и в своих собственных программах обязательно делаю поддержку Scroll Lock.

сколько не пробывал нажимать эту кнопку, так и не понял как она работает (а работает ли вообще?) Какой эффект должен быть? Судя по названию должен заблокироватья скрол страницы/листа, но этого не происходит

При навигации стрелками на клавиатуре, при включённом ScrollLock происходит блокировка перемещения курсора и делается просто пролистывание документа. В MS Word не работает, но в MS Excel всё нормально. Попробуйте открыть какой-нибудь большую таблицу в Excel. Если ScrollLock не включён, то стрелки на клавиатуре перемещают по ячейкам, а если включён, то прокручивают таблицу.

Scroll Lock выключен: стрелки, Home, End, PageUp, PageDown меняют положение текущего выделения (положение каретки, выделенную ячейку, строку, иной элемент, в зависимости от сути контрола).

Scroll Lock включен: стрелки, Home, End, PageUp, PageDown управляют прокруткой.

В консоли FreeBSD это например прокрутка экрана (аналог Shift+PgUp), про Эксель уже сказали рядом.

Caps Lock сейчас программно - аппаратный. Можно управлять с компьютера. Но приоритет имеет физическая кнопка.

А вообще он настолько древний...

Но приоритет имеет физическая кнопка.

Там вообще нет такой закономерности, в драйвер идут сканкоды. Это вы, возможно, NumLock вспомнили, там как раз есть, что флажок управляет генерацией сканкодов.

Сто лет вешаю на него переключение раскладки рус/англ, которая именно что запоминается у меня отдельно для каждого окна.

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

Все познаётся в сравнении. Чтобы понять величие ASCII, сравните её с EBCDIC.

Красота - это конечно хорошо, но вот из-за такого интервального расположения групп цифр, больших букв и малых букв, пространство между ними набили разными значками (всякие скобки, больше, меньше и т.д.), которые могут являться управляющими символами в разных языках, например значки больше и меньше - края тегов в html.

А как бы красиво смотрелся алгоритм кодирования Base64 если бы набор цифр и букв обоих регистров в ASCII шёл последовательно, без лишних вкраплений. Буквально в одну строчку можно было бы кодировщик сделать, а не через таблицу или кучу ветвлений. И был бы он куда производительнее. Так что, всё зависит от позиции наблюдателя, или, как говорится, красота в глазах смотрящего.

Вообще-то до base64 применяли UUE, который именно таким и был...

Не совсем понимаю, при чём тут UUE... В своём предыдущем комментарии я лишь посетовал, что в таком красивом и изящном ASCII напихали спецсимволов между буквами и цифрами, что усложняет алгоритмическую работу некоторых кодировок, где избегают этих символов.

Ожидал увидеть упоминание, что регистры букв отличаются только одним битом, отчего программе "удобно" проходить по текстам не отвлекаясь на регистр просто игнорируя этот бит.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий