Comments 63
Здесь не хватает описание что же такое 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-чтобы редактировать цену" и так далее.
Ну вот я регулярно правлю. А ещё удобно смотреть файл когда под рукой случайно нет офиса. Хоть на телефоне. Кнопочном.
В те времена ещё активно использовались терминалы с их управляющими символами. Ещё были модемы с текстовыми протоколами. И принтеры, на которые можно было просто кинуть текст.
Ну и собственно основная задача - это именно текстовый файл без невидимых символов. Например тот же RTF это, по своей сути, DOC в текстовой версии. Да и куча их. Даже сейчас, если покопаться, есть прорва современных форматов в текстовой и бинарной версии. Это удобно.
Папка "Цветы", прозрачная12,4
Глядя на это, я 'вижу' 3 колонки если там вообще разделитель ','
А в встоенном редакторе Norton как эти символы непечатные отображаются?
1-й сценарий: есть файл CSV который не грузится в программу, например она не поддерживает разделитель этот
2-й сценарий: есть CSV и где-то нужно поправить данные, находим поиском строку и меняем. При этом наличие возможности удобной в Vim или notepad++ не может являться основанием, поскольку есть хоть одна программа которая не отображает эти символы
TSV?
del
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; // Ошибка: не хватает значащих цифр! (Справа от =, если что).
}
вот, для развития идеи :)
http://p-nand-q.com/programming/languages/java2k/manual.html
Как-то размышлял на тему и даже пытался работать над темой ("перезагрузить 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 сейчас программно - аппаратный. Можно управлять с компьютера. Но приоритет имеет физическая кнопка.
А вообще он настолько древний...
Сто лет вешаю на него переключение раскладки рус/англ, которая именно что запоминается у меня отдельно для каждого окна.
Все познаётся в сравнении. Чтобы понять величие ASCII, сравните её с EBCDIC.
Красота - это конечно хорошо, но вот из-за такого интервального расположения групп цифр, больших букв и малых букв, пространство между ними набили разными значками (всякие скобки, больше, меньше и т.д.), которые могут являться управляющими символами в разных языках, например значки больше и меньше - края тегов в html.
А как бы красиво смотрелся алгоритм кодирования Base64 если бы набор цифр и букв обоих регистров в ASCII шёл последовательно, без лишних вкраплений. Буквально в одну строчку можно было бы кодировщик сделать, а не через таблицу или кучу ветвлений. И был бы он куда производительнее. Так что, всё зависит от позиции наблюдателя, или, как говорится, красота в глазах смотрящего.
Красота и изящество таблицы ASCII