Comments 51
Я ещё со времён работы на ДВК (что есть клон DEC PDP-11) приучился показывать даты как "06-Jan-2023", снимает сразу много вопросов:
А точка и запятая как разделитель отличаются да. Я по воле случая работаю в Германии, но в американской компании, так что софт используется и так и сяк, и мы берём разделитель из региональных настроек, чтоб пользователю было комфортно. В принципе особых проблем нет, если всё аккуратно делать. CSV cтараемся по возможности избегать.
Просто надо прекратить использовать текст для передачи информации между компьютерами. Имхо прошли уже те времена, когда человек должен иметь возможность писать и читать (напрямую) то, что предназначается компьютерам.
А что должен читать и писать человек?
Люди предпочитают смайлики, стикеры и эмодзи.
Человек-то конечно кроме текста писать ничего не может. А вот программы (и веб) давно должны перейти на двоичный язык/протокол. А то у нас одна программа пишет в JSON/XML/etc. потом другая программа парсит его. Зачем? Кому этот текст нужен, кроме человека, который уже давно не участвует в передаче и обработке.
Для начала нужно хранить/передавать дату в utc timestamp.
Человеки уже сильно наелись бинарной передачей и давно решили, что надежнее текста, который можно распарсить, ничего не придумали.
В статье текст в основном представлен программным кодом. который с одной стороны сам предназначен для чтения компьютером, а с другой стороны должен генерировать человекочитаемый вывод..
Что касается взаимодействия компьютеров, то мне постоянно приходится переносить данные между bash и Excel. Для моих задач оптимальным оказался текстовый файл с разделителем в виде символа табуляции. Формат CSV, на самом деле, очень сложен в генерации и разборе и ужасно читается как человеком, так и компьютером.
Если же говорить о двоичных форматах при обмене между компьютерами, то учтите, что вам придётся как минимум отслеживать различия архитектур BIG ENDIAN и LITLE ENDIAN, и это тоже не очень просто.
Все же меньше проблем, чем с парсингом той же даты.
Чтобы оценить сложность корректного кодирования/декодирования универсальных двоичных форматов попробуйте как-нибудь распарсить сертификат X.509 в формате der или посмотреть на 100 000 строк библиотеки libasn1 (https://github.com/adirkuhn/libasn1), которая с этим форматом работать умеет.
Справедливости ради, "универсальный двоичный формат" - это всё же не DER, а Avro, Parquet или Protobuf, и вряд ли сложность программной работы с ними существенно превосходит таковую с XML или JSON.
Но с чисто практической стороны задача "по-быстрому глянуть глазами, что там вообще" встречается очень часто, и возможность это быстро и удобно делать - помимо прочего, хорошая гарантия от дурацких ошибок. Так что тут я тоже за текстовые форматы.
На самом деле, сложность работы с различными форматами мало зависит от самих форматов, скорее от удобства библиотек, которые кто-то уже написал для вас. Хотя в маленькой программке для себя при работе с текстовым форматом можно "срезать угол" и, например, выдернуть из XML нужный параметр простым поиском по тексту не заморачиваясь с разбором и валидацией всей структуры.
В двоичном формате тоже нужно определяться как дату передавать: аля юникс дата - число секунд / милисекунд / дней начиная с 01-01-1970 (а почему именно это, а если меньше нужно) или как то по другому
«Философия Unix гласит:
Пишите программы, которые делают что-то одно и делают это хорошо.
Пишите программы, которые бы работали вместе.
Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс».
Откуда тогда этот топик взялся, если все так просто?
Как только в Юниксе разрешили переводы строки в именах файлов, так с текстовыми потоками начались косяки.
Мне кажется, что если бы разработчики Юникса придумали объектные потоки как в PowerShell, то это с одной стороны увеличило бы мощь Юникса на порядок, а с другой стороны, убило бы его, поскольку Юникс взлетел именно как очень простая и лёгкая ОС для слабых машин.
Сдается мне, юникс взлетел все-таки как ОС для больших мэйнфреймов. Все вот эти виртуальные терминалы - наследие подключенных физически терминаов.
Мэйнфреймы 1980-х это многопроцессорные системы с расслоением доступа к памяти, виртуализацией, контейнерами и т.п. — всем тем, до чего персоналки (и Linux вместе сними) доросли спустя тридцать лет.
Юникс была очень простой ОС и стала популярна в первую очередь как ОС для рабочих станций, которые по сути были корпоративными персоналками для инженеров (SUN Solaris, SGI Irix) и для серверов младшего уровня (IBM AIX, HP UX). Microsoft даже пыталась продавать Юникс для персоналок на Intel 286 (Xenix), но потом сосредоточилась на MS DOS.
В начале 1990-х на рынок серверов нижнего ценового уровня вышла Microsoft со своей Windows NT и задавила оригинальный Юникс практически полностью.
Я видел, как дату (в формате дд-мм-гг) в текст завернули. Получилось, эм, своеобразно. При сортировке сначала упорядочилось по дню, одинаковые дни - по месяцу, и с годами аналогично.
А я думал что в csv можно просто двойными кавычками заэкранировать, и тогда вроде как без разницы, какой там разделитель и тд. Однако, чаще смотрю csv в специализированных утилитах типа Tad, Excel и правда черезчур самостоятельный.
Кавычками экранируется текст, который содержит переводы строк, разделители колонок и, кажется, сами кавычки. Вот маленький пример из одной строки и двух колонок. Разделитель колонок — точка с запятой.
"""Abc"";
""""Def""""";"""Abc"",
""""Def"""""
смотрю csv в специализированных утилитах типа Tad
а что такое "Tad", если не секрет?
Отличная вещь. Рекомендую - https://www.tadviewer.com/
Tad is a free (MIT Licensed) desktop application for viewing and analyzing tabular data.
A fast viewer for CSV and Parquet files and SQLite and DuckDb databases that supports large files.
Там кажется даже SQL подобные запросы можно писать.
В сторонних CSV (чаще всего сталкиваюсь с данными каких-нибудь госорганов, финансовой информацей; в других сферах, надеюсь, всё лучше) обычно такие ужасы, что тяну их сразу в OpenRefine, где их можно хорошенько почистить и привести к удобоваримому виду.
Но за наводку на Tad спасибо, гляну, обещают работу с большими файлами, а вот как раз OpenRefine на миллионах строк уже имеет дурную привычку съедать все 192 Гб памяти, которые я ему максимум могу выделить на доступном железе...
P.S. Глянул Tad. Работает умеренно шустро (памяти ест немного, но скорость отклика при любых манипуляциях с данными так себе, и никакого прогресса в процентах не показывает, чтобы хоть понимать, скоро закончит, или можно идти кофе наливать...) Но главное - те самые русские CSV с точками с запятой не понимает вообще :(
Здесь можно поблагодарить разработчиков, программы которых едят оба формата. Компас, например: след ввести размер с точкой, можно с запятой, и оба варианта он обработает, изменив в одном из случаев (в зависимости от системных настроек) знак.
А жирный минус - тем, у кого в одном большом пакете (Ansys) некоторые модули принимают строго точку (потому что писали те, для кого точка это норма), а некоторые - системную настройку (потому что предусмотрели). Ладно хоть между модулями числа нормально ходят.
Это для слабаков. Которые еще не искал ошибку, когда в коде вместо английской "с" стоит кириллица и компилятор валится без указания номера строки с Unknown error.
Наверное, только древние компиляторы валятся от этого с Unknown error. Современные понимают имена на любом языке, и если в одном месте будет другая "с", то он напишет что такой идентификатор не определён. Хорошая IDE подсветит идентификатор с русской "с" в названии. Так что эта проблема позади.
Да, современные этим не страдают.
Но они страдают еще более редкостный бредом, когда на компилятор влияют настройки локализации представления чисел.
Следующий шаг развития, когда на компиляцию будут влиять эмодзи которые будет допустимо вставлять в имена.
Ну еще неизвестно что хуже. Неизвестная ошибка в непонятной строке, которую все же можно отловить последовательными комментариями текста или когда компилятор/интерпретатор "хавает все" и записав значение в Срусское долго пытаешься найти его в Санглийском (если добавить туда локальные, глобальные переменные и области видимости, то задача еще усложняется)
А ведь еще есть и кодировки исходных текстовых файлов ASCII, UTF8, UTF16 etc. и послав текстовую строку в том же JSON не факт что получишь именно ее )))
На заре развития компьютеров в текстовые знакогенераторы зашивали разное начертание похожих букв. Классика - это перечеркнутый 0, отличающийся от O.
Но увы, теперь в мире правят менеджеры и дизайнеры ...
Ох, сразу вспомнилась СМ1420, на которой в компиляторе Фортрана были "русская кавычка" и "латинская кавычка", естественно, не отличающиеся визуально.
А ведь на заре IT разработчики ОС и офисного софта могли бы просто принудить весь мир пользоваться стандартной системой форматов (точка, формат даты год-месяц-день-час-минута-секунда), и никто бы сейчас не возмущался. Наоборот все радовались бы, как все просто и унифицированно. Но вместо этого в угоду непонятно кому сделали дурацкую локализацию.
Просто в юникод надо добавить разделитель строк колонок и дробной части отдельный, не зависимый от локали и все проблемы решаться постепенно, имхо.
Это можно преодолеть, предварительно вставив в начало файла магическую строку
sep=,, но тут вы нарветесь на вторую проблему — теперь ваши числа с десятичными точками будут восприняты не как числа, а как текст. В принципе, можно выделить колонки с числами и сделать во всех ячейках замену точки на запятую, но у себя я наткнулся на третью проблему — при открытии файла Excel попытался угадать формат ячеек и безвозвратно заменил небольшие числа вида "1.2" на даты — "1 февраля 2023".
Вообще, для удобного открытия файла с разделителями другой системы нужно всего лишь открыть параметры Excel, и на вкладке "Дополнительно" снять галочку "Использовать системные разделители: целой и дробной части; разрядов".
Проблема в том, что настраивать Excel надо до того, как открыл файл. Я же просто щелкнул мышкой по файл.csv и только после этого узнал, что он был не совсем правильный.
Попробовал разные варианты. Самый приемлемый, это дать файлу расширение .txt, убрать магическую строку sep=, после чего открыть в Excel. В этом случае помощник предложит выбрать и разделитель колонок и разделитель целой и дробной части.
Точка, точка… запятая?