Какой выбрать разделитель при передаче параметров

[Mephala]

Доброго всем дня!
Необходимо параметры функции записать в строку, а затем строку распарсить и выбрать оттуда все параметры (пишется провайдер между программами). Параметрами могут быть, как числа, дата и время, текст, так и массивы, ссылки и объекты.
Среда разработки - Delphi 7.
Какой лучше выбрать для этого разделитель? Точка с запятой, запятая, пробелы могут встретиться в тексте, ковычки - тоже не очень как-то.
Может кто-нибудь сталкивался с такой проблемой? Поделитесь, пожалуйста, опытом.
Спасибо!

 

[morpheus]

"<!@#>" или "</!@#>" - вот и разделитель

 

[slavon-x86]

Сделай с размером !
Т.е. в начале идёт число, которое обозначает число байт данных для параметра которые нужно читать.

К примеру:

16 Я уехал в африку9 Синий кот7 Тетрадь

 

[Kmet]

велосипедисты... чем XML не угодил?

 

[zubr]

Согласен с Kmet - xml самый лучший вариант. Но если все же идти путем разделителя, то самый надежный вариант, применяемый во многих протоколах - это любой символ. Если он встречается в тексте, то удваивается. При парсинге строки пара этих символа преобразуются в один и относятся к тексту, оставшийся к разделителю.

 

[Mephala]

Спасибо большое за ответы. Получается, что одни из лучших - это xml и удвоение символа. А если будут еще передаваться и бинарные данные в строку, то какой из этих лучше использовать?
Сама понимаю, что от велосипедов не деться. Суть такая, что из дельфовой программы нужно передать в хранимую процедуру СУБД (dll) входные параметры. А так как количество входных параметров может быть разным для разных функций, то было принято решение занести все параметры в один. Если у вас есть лучшее решение и пр., то буду рада любой критике

И еще вопрос: какие существуют классы, методы, объекты, чтобы парсить и формировать xml? С этим еще не сталкивалась я. Буду рада помощи.
Спасибо!

 

[Mephala]

СУБД - Advantage SQL.
Да, создали одну ХП в длл для универсальности. Эта процедура обрабатывает один входной параметр, разбивает его на массив параметров и передает уже эти параметры нужной внутренней хранимой процедуре СУБД (Advantage SQL). Поэтому и была написана одна универсальная хранимая процедура (ДЛЛ), которая смогла бы обрабатывать множество других процедур и функций, чтобы не клепать множество идентичных самописных длл. Поэтому и было принято решение все параметры засунуть в один. Это легче при интеграции, масштабировании, развертывании и по производительности.
Что скажете?
Есть вариант формирования строки по схеме - длина 1 параметра - первый параметр - длина 2 параметра - второй параметр и т.д. Такой подход мне кажется производительным - только один цикл для строки. Для удвоения - нужно будет несколько циклов, и для xml тоже будет трудоемкий процесс.
Или может еще что-то. Как вы считаете?

 

[Kmet]

что вы понимаете под длл?

Есть вариант формирования строки по схеме - длина 1 параметра - первый параметр - длина 2 параметра - второй параметр и т.д. Такой подход мне кажется производительным - только один цикл для строки.

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

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

имхо, идеальный вариант если не надо сохронять информацию о типе.

согласен с sax_ol, непонятно какие мотивы вас сподвигли на такое неоднозное решение. БД с множеством ХП, которые обеспечат проверку типов, много лучше вашего решения.

 

[Mephala]

Мотивы такие оказались из сложности самой платформы, на котором все работает уже много-много лет. А вот сейчас хочется это все переместить на новый движок на новую СУБД с совместимостью с прошлыми наработками. Другие варианты, как не рассматривали - не подошли. А из-за того что я только часть проекта осветила, а 95% - нет, вот и появляется уверенность, что это очередной велосипед и багадром...
Вы правы, как никогда :blink: Без этого ни одни проект не создается.
>не очевидно как передавать числа, даты и тд
Как строку. Есть же функции для преобразования типов. С этим как раз проблем не будет.
И БД с множеством ХП как раз и будет. И мой провайдер тоже будет использоваться для конкретных задач.
Спасибо большое всем за отклик!

 

[Kmet]

Мотивы такие оказались из сложности самой платформы, на котором все работает уже много-много лет. А вот сейчас хочется это все переместить на новый движок на новую СУБД с совместимостью с прошлыми наработками. Другие варианты, как не рассматривали - не подошли. А из-за того что я только часть проекта осветила, а 95% - нет, вот и появляется уверенность, что это очередной велосипед и багадром... smile.gif

уверенность осталась

>не очевидно как передавать числа, даты и тд
Как строку. Есть же функции для преобразования типов. С этим как раз проблем не будет.

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