TXT vs. XML #600925

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

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

xml

CSV

ну, дабы не срамиться,

4.01 из тебя до сих пор не выветрился, я смотрю.

CSV - зло естественно  XML

3. mxl

попробовав раз, ем и сейчас! ©

xml гумно жрет гигабайты памяти фстопку негодуэ

кстати, почему нет DBF?

а в каком стандарте 1с выгружает XML, так как первый вопрос от иностранных коллег был именно таким, а я даже не знал что ответить, они сказали что они смогут загружать и выгружать в стандарте gs1.

, мне на выбор дали два варианта XML и TXT

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

Текстовый - как, в одну строку или разделитель? Разделители табуляторы или символы? При одинаковых объемах данных, в XML будет больший размер из-за тэгов.

Делай так, как хотят иностранцы.

если текстовый, то колонки буду разделяться строго длиной, то есть первое значение 20 символов, втрое - 3... иностранцы сказали, что бы мы решили TXT или XML.

- разделитель какой? а то мучался с загрузкой из клиент банка в текстовом формате. где разделителем выступала ";". Вот когда в назначении платежа этих точек с запятой было несколько было очень весело Поэтому ХМЛЬ

Ну конечно XML

разделителя не будет совсем, то есть будем иметь следущее: 20120315Ноутбук 15          7888454   2000.00 20120316Хлебопечка          785411    178.0

изменились размеры реквизитов, изменился порядок или позиция в парсируемой строки - началося море "удовольствия", ну а оно надо?

и как выгрузите товар  "Лопата совковая" или контрагента "Аптека №6"?

проблематично сериализовать =)

при открытии xml гигабайты озу сжираются

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

не думаю что размеры реквизитов могут сильно именится, к примеру изначально на поле артикул выдиляется 20 символов, сейчас реально 12 (8 в запасе). Кстати заметил что из САПа в основном выгружают без разделителей, то есть строго по длине.

а что по поводу производительности, обмен будет делатся по расписанию и через ftp, не будет ли больше проблем из XML или каких то сбоев, поскольку XML будет большего размера чем TXT.

и Знаком и с разделителями ;) Некоторые банки грузят строго определенное поле, пустое оно или заполнено, но если надо 40 символов, их есть. Некоторые пустые поля просто пропускают и помечают только разделитель. Для моего парсера пофиг, сколько там букивок - 40, 20 или дв разделителя подряд, т.к. он ползёт посимвольно и нашел разделитель - считал поле до следующего. Если два разделителя подряд - поле пустое, читаем следующее зп ним поле.

Не будет. Не намного он больше, архивируй. Тем более, что восьмёрка архивирует нативно.

см Только кома-сепаратор - частный случай "Текста с разделителями" (мне больше нравиться в качестве разделмителей непечатные и естественно неуправляющие символы), применение в качестве разделителя ";" (CSV) чревато. Атак: 3. Вариант 3 - другое. Плевать какой формат, лишб бы было удобно им пользоваться и (главное!!) чтобы работало.

Вот и лепи по-саповому. А еще лучше - XML, поиздевайся над буржуями, пусть свою саму научат разговаривать на XML.

Обычно казначейство лепит точку с запятой, непечатаемые не встречал, но вот из неиспользуемых частенько используется вертикальная черта |

+ к 28 Сам использую 1. Для выгрузки в МеДок XML 2. Обмен с некоторыми клиентами MMO или его вариация EXT 3. С другими клиентами ТХТ (зараннее оговоренного вида) или DBF (в некоторых частных случаях применения = самый быстрый, особенно если к ДБФ-у присобачиваю индексный файл).

обмен чего? одна-две таблицы с простыми типами - TXT иначе XML.

Однохренственно.

После нескольких случаев выгрузки контрагентов с непечатаемыми символами в названии (из Excel или с web-сайтов копировали при заведении) - только XML. Он их хоть как-то поедает.

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

Небольшое пояснение к п.31_3: "ТХТ (зараннее оговоренного вида)" - имеется в виду строго фиксированный текстовый формат, где расписаны форматы как каждой строки так и последовательность строк. Например: 1-я строка и т..д.

"xml гумно жрет гигабайты памяти фстопку негодуэ" Эксель гумно, жрет память, поэтому рисую таблицы в нотепаде. Автокад гумно, поэтому проектирую в паинте.

XML однозначно рулит

да

Ненаучно выражаешься. ПО-научному "монопенисуально".

Ну да. А 1С так вообще... на кривых запросах ложит сервер или сама выпадает.

Да изофаллически мне, "однохренственно" или "монопенисуально"...

XML - только потому что стандарт обменов самой 1С Для своих уникальных обменов есть вагон и маленькая тележка вариантов вне XML

На вопрос "В каком стандарте XML выгружает 1С" надо отвечать - Одинэс настолько крутая программа, что может выгружать в любом стандарте. В том числе и gs1. Пусть от зависти подавятся и не считают тут нас за лохов которые только с текстовыми файлами справится могут.

интересно, сможет ли буржуйская прога съексть то, что ей 1с нагенерит в xml. И vice versa (1с-овский xml не все парсеры понимают и в дерево развернуть могут)

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

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

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

так у тебя же есть поля по которым ты должен выгружать. Сделай более универсальным его, что бы можно было в хмл или в тхт :).

фигли тут размышлять

Оно? Будь мужиком, блеать, сделай по человечески! Пусть буржуи описание стандарта скинут и всё. Ты же только табличную часть товаров передавать будешь, там всего то несколько полей, чё ты ссышь так.

А чего не печатные копии? Проверять ту ли тебе txt прислали, тоже прикольно, а тупые xml схемы, чтобы код не писать - ацтой!

похрен

не так давно сам стал делать

xml

иностранное или межпланетное? они по-моему грузят в XRVGTYUIOSD

ТС, тут ответа не дождешься, тем более с голосовалкой. Каждый любит свои сигареты...

тут дело в том, что 1. Структурированные данные удобнее обрабатывать XML 2. Чтение/ЗаписьXML генерят XML с тегами укороченной формы. Косяк (хотя фиг знает -- возможен ли) может быть в том, если буржуинам понадобятся непременно теги полной формы. Тогда XML надо будет генерить через простые текстовые файлы. Что уже сложнее, чем текстовый обмен

Почему я так волнуюсь за буржуйскую прогу? Потому что 1с-ники бесплатны по сравнению с буржуями, и всю работу будет делать ТС. А некоторые файлы, которые генерит 1с через XML-запись НЕ открываются парсерами XML. Возможно, парсеры кривые... но проблема только с xml от 1с возникает, хотя и не всегда

За XML, генеренный через текст надо руки отрывать. Валидатор охреневать будет местами, и парсер вслед за ним.

пример файла в студию

ну, никто не заставляет юзать ДОМ-модель

XML суть текст. а руки надо отрывать горе-писателям, которые не в состоянии сгенерить валидный хмл

Проще так

Чтобы сгенерить валидный XML в общем случае - надо учесть все нюансы и фактически написать абсолютно стандартные вещи заново.

дануна! и что же такого придётся писать? пару-тройку функций на 20-30 строк? экая задача

Это было около 3-ех лет назад. Из КД-2. Пробовал микрософтовским парсером, он выдал попап, что может открыть только как plain-текст.... не сохранился, к сожалению. Но случай запомнился

версия парсера, поди, 3-я была?

Я и не помню... оно в браузер встроено было, в ослик 6-ой

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

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

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

+ но после отладки их лучше убрать, ибо, если использовать их в повседневке, то смысл прямой записи хмл теряется

Хочешь сказать что твои строчки запишут хмл валиднее чем годами оттестированные библиотеки?

Библиотеки тоже люди писали...

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

+ xsd

Аминь

чо тут думать?..

Чего тут думать? Если кодировка UTF-8 для простых типов данных - формат TXT. Если структурированные данные - XML.

Всем спасибо за советы!

У xml есть символы которые 1с не читает и сваливается по ошибке к примеру "&". Делал обмен с интернет магазином столкнулся с таким.

&amp

Сделать схему и сообщения валидировать перед отправкой.

У меня уже давно алгоритмы написаны чтения/записи XML или TXT - зачем такое обсуждать? Берешь, пользуешься. В XML можно хранить несколько табличных частей...

спасибо, поржал

XML - это все-таки стандарт

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

CSV - там разделение вроде как ";" и он открывается в екселе и в итоге получается, что-то типа ДБФ приходилось как-то для САПа делать.

Фактический стандарт для 1С.

+ Отточишь навыки.

"Плюс, для определенных объемов передаваемых данных XML в принципе не подходит"  мягко говоря, неправда

Начнём с того, что xml - это один из вариантов текстового файла, так как там внутри текст, только специально структурированный. Проблема в xml в том, что записывается очень много лишней информации, так как название каждого поля объекта пишется так, как оно указано. Кажущая простота парсинга xml-файла упирается в то, что есть готовые парсеры, которые чаще всего загружают весь файл в память и там его разбирают, что иногда кончается нехваткой памяти. При изменении структуры xml-файла придётся также править программу, как и в случае с txt-файлами, а может быть, даже и больше. Также для xml-файла оказывается смертельной вложенность другого файла во внутрь, так как может просто произойти нарушение дерева xml из-за одинаковых объектов. Для txt-файла есть большая свобода размещения данных, а также возможность использования, например, php-сериализации, когда можно складывать ссылки между объектами, что напрямую в xml-файле не поддерживается. Некоторые системы умеют выгружать xml-файлы, но половина свойств объектов оказывается в параметрах тега объекта, а другие - во вложенных тегах - сиё определяет выгружающая программа. А вот при "кормлении" 1С такими файлами возникает проблема, так как нужно точно и ясно оговаривать что и где будет. В случае применения экранирования символов можно избежать наложения символов внутри блока данных с символами разделения блоков. Построчное чтение txt-файла оказывается быстрее, чем чтение xml-файла.

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

Дерево объектов строится в памяти - поэтому, файл чаще всего или целиком в памяти или читается много раз по кусочкам (что даже медленнее, чем файл в памяти).

Последовательное чтение хмл никто не отменял. Можно хоть по одной записи выдергивать если есть желание.

Настаиваю опять, только печатные копии и проверять руками структуру, каждый раз, или валиться по ошибке, если не та, или фигню в базу напихать! Адназначна (с).