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

xml

CSV

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

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

(2) CSV - зло
(0) естественно  XML

3. mxl

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

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

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

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

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

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

Текстовый - как, в одну строку или разделитель?
Разделители табуляторы или символы?

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

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

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

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

Ну конечно XML

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

да

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

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

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

XML - только потому что стандарт обменов самой 1С

Для своих уникальных обменов есть вагон и маленькая тележка вариантов вне XML

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

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

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

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

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

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

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

http://www.gs1.org/ecom/xml Оно?
(47) Будь мужиком, блеать, сделай по человечески! Пусть буржуи описание стандарта скинут и всё. Ты же только табличную часть товаров передавать будешь, там всего то несколько полей, чё ты ссышь так.

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

(0) похрен

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

xml

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

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

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

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

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

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

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

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

Проще так

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

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

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

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

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

Хотя, файлы xml обмена с логистикой акселотовской открывались нормально с сохранением структуры.

В чем дело -- не знаю, просто эту неприятную возможность я отметил

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

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

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

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

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

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

+ xsd

Аминь

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

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

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

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

(82) &amp

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

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

(82) спасибо, поржал

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

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

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

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

(89) wiki:CSV

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

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

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

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

Некоторые системы умеют выгружать xml-файлы, но половина свойств объектов оказывается в параметрах тега объекта, а другие - во вложенных тегах - сиё определяет выгружающая программа. А вот при "кормлении" 1С такими файлами возникает проблема, так как нужно точно и ясно оговаривать что и где будет.

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

Построчное чтение txt-файла оказывается быстрее, чем чтение xml-файла.

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


не все же сразу в память

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

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

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

ИМХО

(100)

XML с использованием фабрикиXDTO

(101) На больших файлах - нет!

тупая ветка... пока нет внятных требований к носителю - все выборы бессмысленны

(103) Угу
И вроде не раз обсуждали уже , например
Обмен в формате XML, DBF, TXT?

Все равно - большую часть кода что в тексте, что в иксемеле  занимает не чтение и разбор данных а распихивание ппрочитанного по нужным местам/объектам - поэтому, в общем по барабану. иксемель может быть чуток понятнее за счет наличия тегов/атрибутов - ДА И ТО, В РЕДКИХ СЛУЧАЯХ. ну а так как периодически случается невозможность работы парсера - то приходится извращаться.. Текст - прочитается всегда.
.
так что - текст...

(105) Предлагаю и всякие SQL отменить, они ж на дисках хранятся.

(106) а фигли делать.. грузиишь например v7+ - 1ска падает... и вместо того, чтобы грузить данные - кучу времени убиваешь на поиски бодяги...
.
хотя мну пофиг.. обменов у меня мало - что наружу что внуть - отдам/загружу в каком надо формате...
все равно - что под каждый текстовик, что под каждый иксемель - писать свою загрузку данных...

(83) И что это?
(86) Смари не абассыся от смеха.

Как передать наименование товара которое содержит данный символ к примеру "проктер & гэмбэл"

(86) Дерзай http://zalil.ru/32909240

   ЧтениеXML = Новый ЧтениеXML;
   ЧтениеXML.ОткрытьФайл("c:/1.xml");
   Пока ЧтениеXML.Прочитать() Цикл
   // Обработка узла XML
   КонецЦикла;

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

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

Голосую за:

+ Сам разрабатываешь структуру файла. Используешь спец знаки в строке.
Потом разбираешь строку по этим знакам и получаешь все что необходимо.

(109) Ну где же дерзкий чел из (89)?

3. Вэб-сервис

3. JSON
4. YAML

(114) а как делсть схему?

(86) ANDREWKS ответь на (109)

объемы данных не указаны

в голосовалке нет кг/ам

(121) Согласен.

имхо проще

(125) у тебя не валидный xml, это тоже самое что в dbf запишешь в заголовок мусор всякий, а потом жалуешься, что не открывает.  http://screencast.com/t/05jb8LDWeqO

Без вариантов, сам боялся, но уже теперь нравиться после N-выгрузок/загрузок в налоговую :)))

Насчет спец.символов, учите мат.часть ХМЛ-а:
& ==== &

(120) почитай-ка здесь: wiki:XML, раздел "Спецсимволы"

привычно да и лучше