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

Тема в разделе "Delphi - FAQ", создана пользователем Mephala, 5 сен 2008.

Статус темы:
Закрыта.
  1. Mephala

    Mephala Гость

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

    morpheus скриптописец

    Регистрация:
    7 авг 2006
    Сообщения:
    3.927
    Симпатии:
    0
    "<!@#>" или "</!@#>" - вот и разделитель
     
  3. slavon-x86

    slavon-x86 Well-Known Member

    Регистрация:
    18 дек 2005
    Сообщения:
    216
    Симпатии:
    0
    Сделай с размером !
    Т.е. в начале идёт число, которое обозначает число байт данных для параметра которые нужно читать.

    К примеру:
    Код (Text):
    16 Я уехал в африку9 Синий кот7 Тетрадь
     
  4. Kmet

    Kmet Well-Known Member

    Регистрация:
    25 май 2006
    Сообщения:
    1.017
    Симпатии:
    1
    велосипедисты... чем XML не угодил?
     
  5. zubr

    zubr Гость

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

    Mephala Гость

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

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

    Mephala Гость

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

    Kmet Well-Known Member

    Регистрация:
    25 май 2006
    Сообщения:
    1.017
    Симпатии:
    1
    что вы понимаете под длл?

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

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

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

    Mephala Гость

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

    Kmet Well-Known Member

    Регистрация:
    25 май 2006
    Сообщения:
    1.017
    Симпатии:
    1
    уверенность осталась
    будут. как будете разруливать случай, когда передоваемый параметр после преобразования в строку будет начинаться с цифры?
     
Загрузка...
Статус темы:
Закрыта.

Поделиться этой страницей