Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / C++ |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 5 6 вперед Ctrl→ все |
Dima T Member Откуда: Сообщений: 15686 |
В этом нет никакого криминала. Табуляция вполне себе символ, никакой угрозы безопасности не несет. Вставить табуляцию копипастом элементарно благодаря браузерам. Пример: Выделяем табличку и давим Ctrl+C
Вставляем что получилось Ctrl+V, а получился TSV 1 2 3 4 Опубликовав это сообщение я сохранил табуляцию в БД сайта sql.ru :) |
|||||||||
20 фев 21, 12:50 [22284024] Ответить | Цитировать Сообщить модератору |
petrav Member Откуда: Сообщений: 2861 |
Вообще спор не стоит выеденного яйца. Нужно просто использовать качественную библиотеку и не париться. Давайте лучше поговорим про строки и Юникод. А лучше вообще разработаем свой класс строки. Ведь С++ это язык программирования созданный что бы писать свои классы строк. Я и название придумал: JaString. ![]() |
||||||||
20 фев 21, 12:53 [22284026] Ответить | Цитировать Сообщить модератору |
Dima T Member Откуда: Сообщений: 15686 |
Проблема как раз в продвинутости парсеров, они слишком много нарушений прощают. Пример вышеописанной проблемы с кавычкой. Сохрани текст ниже в файл CSV и открой его экселем ООО "Рога и копыта;1 |
||||
20 фев 21, 13:10 [22284037] Ответить | Цитировать Сообщить модератору |
petrav Member Откуда: Сообщений: 2861 |
Криминала нет? А потом в БД данные не грузятся? Ну не знаю… Тут дело в том что в UI должен быть фильтр, аля белый список, который пропускает только то что можно. Если табы по смыслу поля данных недопустимы, то их там (в БД) быть не должно — хоть копипасть, хоть чё делай. Далее… Нужно использовать качественную библиотеку в которой исключены сбои из-за каких-то нюансов. Всё должно быть экранировано и т.д. Возможно она же (библиотека) проверяет корректность данных: говорим ей непечатных символов, кроме пробелов, быть не должно. И вот ещё что… Если ошибка только в одной строке, то тут возникает нюанс. В зависимости от того как построен парсер может случиться ситуация когда ошибка внешне станет незаметной если ошибка только в одной строке. False negative страшная вещь. Сообщение было отредактировано: 20 фев 21, 13:08 |
|||||||||||||
20 фев 21, 13:12 [22284039] Ответить | Цитировать Сообщить модератору |
Dima T Member Откуда: Сообщений: 15686 |
Если не путаю там учет в 1С идет. Собственно и криминала не было до тех пор как потребовалось выгрузить именно в TSV, в любой другой формат табуляция выгружается без проблем.
Ошибка будет незаметна. Лишняя табуляция сдвинула последующие поля в строке Сообщение было отредактировано: 20 фев 21, 13:14 |
||||||||
20 фев 21, 13:19 [22284043] Ответить | Цитировать Сообщить модератору |
Dima T Member Откуда: Сообщений: 15686 |
Теоретически да, а практически если у тебя десятки-сотни разных источников этих выгрузок, то ты просто устанешь долбить всех писателей чтобы писали правильно, плюнешь и будешь парсить лишь бы парсилось. |
||||
20 фев 21, 13:25 [22284044] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51015 |
Это философия. Или старый принцип проектирования гетерогенных систем. Аналогичный текст я читал где-то в сетевых протоколах.
Вобщем writer/serializer должен быть максимально строг. А reader/parser/de-serializer - максимально толерантен к исходным данным. |
||||||||||
20 фев 21, 14:23 [22284077] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51015 |
Зачем? |
||||
20 фев 21, 14:29 [22284079] Ответить | Цитировать Сообщить модератору |
Alex_Ustinov Member Откуда: Nickel Сообщений: 3721 |
смотрю в dbForge для MySql настройки выгрузка-копирование в CSV - хочешь - в кавычках все, хочешь - только текст хочешь - все поля без кавычек разделитель настраивается и все нормально работает надо понять что CSV должен быть настраиваемым, как загрузка так и выгрузка и TSV - частный случай CSV |
20 фев 21, 14:41 [22284082] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51015 |
ЕМНИП при импорте произвольных пользовательских данных в Excel - есть мастер импорта который позволяет указать различные границы колонок и сплиттеры. Есть даже вариант испорта fixed-column. Это тесно связано со старыми форматами dbms где records имели одинаковый бинарный размер. Щас такое уже не катит но лет 20 назад можно было взять dbBase/FoxPro датафайл. Отрезать ему голову и спокойно заимпортировать такой файл в Excel. |
20 фев 21, 14:50 [22284093] Ответить | Цитировать Сообщить модератору |
Dima T Member Откуда: Сообщений: 15686 |
Записи в DBF фиксированного размера, а числа с датами хранятся в сериализованном виде. Хотя непонятно зачем это делать если эксель и так их открывает. Но нынче фокус может не пройти, т.к. добавились типы которые хранятся без сериализации (int, datetime) |
||||
20 фев 21, 14:56 [22284097] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51015 |
Ну или без dbf. Вот такие позиционные форматы.
|
|
20 фев 21, 19:30 [22284219] Ответить | Цитировать Сообщить модератору |
Dima T Member Откуда: Сообщений: 15686 |
mayton, нынче json и строки в utf8 наше всё. Даже MS с этим согласен. Зачем старье ворошить? Его надо хоронить, и чем быстрей, тем лучше. |
20 фев 21, 20:55 [22284258] Ответить | Цитировать Сообщить модератору |
petrav Member Откуда: Сообщений: 2861 |
Наше всё это православный XML и XML схемы. |
20 фев 21, 21:14 [22284263] Ответить | Цитировать Сообщить модератору |
Dima T Member Откуда: Сообщений: 15686 |
MS уже так не считает, это тоже старье |
||||
20 фев 21, 21:20 [22284264] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51015 |
(задумчиво) Если рассматривать json как способ экспорта или импорта данных - то скорее нет, чем да. При прочих условиях (есть выбор) я-бы выбирал лаконичный способ отдать данные. JSON (JavaScrip Object notation) создавался для сериализации браузерных объектов и транспорта их в веб-соединениях. И если у вас есть таблица в 8Гб в сыром виде (это близко к размеру в CSV) то ее представление в JSON может удвоить объем файла экспорта. Кто из нас готов согласиться с таким внезапным увеличением накладных расходов? И зачем? Все равно прогрузить в память такой файл (16 Гб) почти нереально. А если не грузить - то как делать запросы через JSonPath, JSonifier. Хотя для REST-сервисов он удобен. Как само-описательный. Все значения посылаемого месседжа - имеют внятные названия и их видно глазами в tcp-dump например. Даже кодер слабой квалификации более-менее сносно решает проблемы если ему показать проблемный request/response в этом формате. Но в Рест-сервисах речь-бы не шла о 8Гб. |
||||
20 фев 21, 21:33 [22284267] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51015 |
XML был смелым экспериментом в 2000х. У меня на эту тему было куплено несколько восторженных книг. Есть такая избитая фраза - "практика показала"... Вобщем показала что некоторые из предметных областей (XHTML, Dbms (Sedna), Oracle(XmlType)) провалились в части активного использования XML. Или не принесли ожидаемого эффекта. Например при выборе опции формата REST ответа - большая часть разработчиков и кастомеров выбирают Json вместо Xml. Это обычный прагматизм и бритва Оккама. Если задача решается вовлечением меньшего числа сущностей - то ее так и надо решать. Xml даже для разработчика сложен. Он имеет много уровней семантики. (Как например С++ имеет уровни макро-процессинга и шаблонизации) и разработчики НЕ готовы их ВСЕ использовать. А не готовы просто потому что эти уровни оказались не нужны. Например XSLT и стандартизация схемы. И если эти все уровни не задейстовать - тогда возникает вопрос - а зачем вам вообще Xml? Ради красивого слова? Или угловых скоб? |
||||
20 фев 21, 21:45 [22284269] Ответить | Цитировать Сообщить модератору |
petrav Member Откуда: Сообщений: 2861 |
В случае сложных документов лично мне кажется, что XML гораздо более читабелен чем json. При наличии XML-схемы в редакторе гораздо (на порядок) легче писать XML документы благодаря автодополнению кода — Ctrl+Space и появляется меню с возможными элементами или допустимыми значениями атрибутов. Что-то мне подсказывает, что XML (даже без схем) вообще лучше поддаётся автоматической валидации по сравнению с json. Когда я работал в web я знал и XSLT, и Схемы, и XPath (и даже DTD). Проблем не было. XML схемы я вообще в метро выучил полистывая распечатанную документацию. |
||||
20 фев 21, 22:01 [22284275] Ответить | Цитировать Сообщить модератору |
Dima T Member Откуда: Сообщений: 15686 |
В запакованном виде они не сильно будут отличаться. Еще один неприятный момент CSV - отсутствие описания структуры данных. Прилетает такая выгрузка из 10-15 колонок и сиди гадай где что. Потом разнородные данные не сохранить в один файл CSV. А как правило надо выгрузить именно такие данные. Например при выгрузке накладной надо куда-то писать шапку. Сталкивался с тем что при небольшой шапке ее суют в тело, т.е. табличка становится такой
И хз что теперь меньше на диске займет.
Не надо его грузить целиком, читай последовательно. С большими json дела не имел, а с xml было дело, файлик 0.5 Гб быстро читается с помощью XmlReader Наверно и для json есть подобное. |
||||||||||||||
21 фев 21, 07:59 [22284340] Ответить | Цитировать Сообщить модератору |
petrav Member Откуда: Сообщений: 2861 |
Кстати сказать, а наличие JSON Schema тебя не смущает? Странные у тебя рассуждения. PS: Json популярен не потому что XML плох, а потому что JavaScript — единственный язык программирования фронт-энда. |
||||
22 фев 21, 13:08 [22284708] Ответить | Цитировать Сообщить модератору |
petrav Member Откуда: Сообщений: 2861 |
Может ли json описывать документы? Вот никогда такого не видел. Пример:
Ну и как тут без XSLT... Сообщение было отредактировано: 22 фев 21, 13:16 |
22 фев 21, 13:21 [22284718] Ответить | Цитировать Сообщить модератору |
Alex_Ustinov Member Откуда: Nickel Сообщений: 3721 |
|
||
22 фев 21, 13:25 [22284720] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51015 |
Я пробовал Json-schema. К сожалению мне не удалось сделать проверки достаточно строгими. Тоесть у меня получилось проверять только те сущности которые были декларированы. А новые почему-то успешно проходил валидацию хотя и не должны-быть по идее. |
||||||||
22 фев 21, 13:31 [22284724] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51015 |
json это всё таки в первую очередь объект а уж во вторую - таблица. Поэтому если работать с ним на стандартных ЯП программирования веба (JavaScript/C#/Java/Node) то я готов спорить на виски что для отработки реквеста ... ну не знаю с JPointer нам придется прогрузить весь документ-объект в память. Вариант курсора (аля БД) скорее всего не сработает. Хотя и респонс может выглядеть как итератор например. Словом - это тема отдельного топика. Накладные расходы на JPointer при запросах к толстым документам. |
||||
22 фев 21, 13:35 [22284725] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51015 |
Да. Это проблема. Но внятные описания колонок можно сгенерировать лишь для небольшого подмножества таблиц с малым числом колонок. Я работал с дата-аналитикой где количество колонок было до 1000. И названия у них были такие типа FXC01.D2.M4 e.t.c. И была какая-то визуальная хронология. Тоесть следующая колонка могла быть инкрементом от предыдущей. И понимал такое имя - только data-analyst который работал с данными и мог сказать что - цена акции такой-то в таких-то единицах. Для таких баз отдельно создавалась мелкая базка которая называлась мета-информация и туда складывались детальные характеристики. Дескрипшен. Единицы. Иногда вместо этой базки мог быть хардкод в софте. Например сет классов или пропертей описывал эти колонки наподобие ORM. Хотя сам ОРМ не использовался но идея была похожа. Тоесть вобщем неинформативные названия реально существуют но XML не решает на 100%. По крайней мере я не видел провайдеров бизнес-информации которые лично решили публиковать сводки в XML только потому что там информативные поля. Скоре они выбирали CSV и полагались на мастерство и опыт тех людей для которых этот CSV был предназначен. Сообщение было отредактировано: 22 фев 21, 13:36 |
||||||||
22 фев 21, 13:42 [22284729] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 5 6 вперед Ctrl→ все |
Все форумы / C++ | ![]() |