Подтвердить что ты не робот

Простые свойства для преобразования строк в Java

Используя Java, мне нужно закодировать Map < String, String > пар значений значения для хранения в String и возможность декодировать его снова. Они будут храниться в столбце базы данных и, вероятно, обычно будут короткими и простыми, поэтому обычный случай должен создать простую симпатичную строку, но не должен искажать данные, даже если они содержат неожиданные символы и т.д.

Как бы вы решили сделать это так, чтобы:

  • Закодированная форма - это единственная, понятная для человека строка.
  • Для кодирования/декодирования не требуется большая библиотека или много контекста.
  • Любые разметки должным образом экранированы

Url-кодирование? JSON? Сделай сам? Укажите любые вспомогательные библиотеки или методы, которые вы будете использовать.

(Отредактировано, чтобы указать больше контекста и требований по запросу.)

4b9b3361

ОТВЕТЫ

Ответ 1

Как говорит @Uri, дополнительный контекст будет хорошим. Я думаю, что ваши основные проблемы меньше связаны с конкретной схемой кодирования, поскольку для большинства кодировок довольно просто сделать простой Map<String, String>.

Интересный вопрос: для чего будет использоваться эта кодировка промежуточной строки?

  • если он чисто внутренний, ad-hoc формат хорош, например, простая конкатенация:

    key1|value1|key2|value2

  • если люди ночью прочтут это, формат, подобный объявлению карты Ruby, хорош:

    { first_key  => first_value, 
  second_key => second_value }

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

    <map>
    <entry key='foo' value='bar'/>
    <entry key='this' value='that'/>
</map>

  • если карта будет сброшена в файл и снова прочитана другим Java-приложением, предложение @Cletus класс свойств является хорошим и имеет дополнительное преимущество: легко открывать и проверять людьми.

Изменить: вы добавили информацию, которую он должен хранить в столбце базы данных, - есть причина использовать один столбец, а не три столбца:

CREATE TABLE StringMaps 
(
    map_id NUMBER   NOT NULL,  -- ditch this if you only store one map...
    key    VARCHAR2 NOT NULL,
    value  VARCHAR2
);

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

Изменить еще раз: вы сказали, что действительно нужно вписаться в один столбец, и в этом случае я либо:

  • используйте первую кодировку, разделенную по каналам (или любой другой экзотический символ, который вам нравится, может быть, какой-то unprintable-in-English символ юникода). Простейшая вещь, которая работает. Или...

  • если вы используете базу данных, такую ​​как Oracle, которая распознает XML как реальный тип (и поэтому может дать вам оценки XPath против него и т.д.) и должна быть способна хорошо читать данные из уровня базы данных, пойдите с XML. Написание XML-парсеров для декодирования никогда не бывает забавным, но не должно быть слишком болезненным с такой простой схемой.

Даже если ваша база данных не поддерживает XML изначально, вы можете просто вставить ее в любой старый характерный тип столбцов...

Ответ 2

Почему бы просто не использовать класс свойств? Это делает именно то, что вы хотите.

Ответ 3

Я рассматриваю аналогичную потребность в выборе общего представления для разговоров (транспортный контент) между моими клиентами и серверами через шаблон фасада. Я хочу, чтобы стандартное стандартизованное представление, понятное для человека (краткое), надежное, быстрое. Я хочу, чтобы он был легким для реализации и запуска, простым в тестировании и простым "обертыванием". Обратите внимание, что я уже удалил XML по моему определению и с явным намерением.

Под "wrap" я подразумеваю, что я хочу поддерживать другие представления транспортного содержимого, такие как XML, SOAP, возможно, свойства Java или форматы Windows INI, значения разделенных запятыми (CSV) и т.д., буферы протокола Google, пользовательские двоичные файлы форматы, патентованные двоичные форматы, такие как книги Microsoft Excel, и все, что еще может прийти. Я бы использовал эти вторичные представления, используя обертки/декораторы вокруг основного фасада. Каждое из этих вторичных представлений желательно, особенно для интеграции с другими системами в определенных обстоятельствах, но ни одно из них не желательно в качестве первичного представления из-за различных недостатков (неспособность выполнить один или несколько из моих критериев, перечисленных выше).

Поэтому до сих пор я выбираю формат JSON в качестве своего основного представления транспортного содержимого. Я намерен подробно изучить этот вариант в ближайшем будущем.

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

Как разработчик, администратор баз данных, архитектор и многое другое, я создал системы практически каждого размера и описания. Я уверен в своем выборе критериев и с нетерпением жду подтверждения его пригодности. В самом деле, я надеюсь опубликовать реализацию как open-source (но пока не задерживаю дыхание).

Обратите внимание, что это обсуждение дизайна игнорирует транспортный носитель (HTTP, SMTP, RMI,.Net Remoting и т.д.), который является намеренным. Я считаю, что гораздо эффективнее рассматривать транспортную среду и транспортный контент как совершенно разные соображения дизайна, друг от друга и от рассматриваемой системы. Действительно, я намерен сделать их практически "подключаемыми".

Поэтому я призываю вас серьезно рассмотреть JSON. С наилучшими пожеланиями.

Ответ 4

Некоторый дополнительный контекст для вопроса поможет.

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

Ответ 5

Как говорит @DanVinton, если вам это нужно во внутреннем использовании (я имею в виду "

внутреннее использование

как

он используется только моими компонентами, а не компонентами, написанными другими

вы можете указать ключ и значение. Я предпочитаю использовать разный разделитель между ключом и ключом и ключом и значением:
Вместо
key1+SEPARATOR+value1+SEPARATOR+key2 etc
Я код
key1+SEPARATOR_KEY_AND_VALUE+value1+SEPARATOR_KEY(n)_AND_KEY(N+1)+key2 etc

если вы должны отлаживать, этот способ более ясен (по дизайну тоже)

Ответ 6

Проверьте конфигурационный пакет apache. Это позволит вам читать/сохранять файл как XML или формат свойств. Он также дает вам возможность автоматически сохранять изменения свойств в файл.

Настройка Apache

Ответ 7

А осознайте, что это старый "мертвый" поток, но у меня есть решение, не поставленное ранее, которое, как мне кажется, стоит выбросить на ринг.

Мы сохраняем "произвольные" атрибуты (т.е. созданные пользователем во время выполнения) географических функций в одном CLOB в БД в стандартном формате атрибутов XML. То есть:

name="value" name="value" name="value"

Чтобы создать элемент XML, вы просто "завершаете" атрибуты в элементе xml. То есть:

String xmlString += "<arbitraryAttributes" + arbitraryAttributesString + " />"

"Сериализация" экземпляра "Свойства" для строки xml-attributes - это не проблема... это похоже на десять строк кода. Нам повезло, что мы можем налагать на пользователей правило, что все имена атрибутов должны быть действительными именами xml-element; и мы xml-escape (т.е. &quote; и т.д.) каждое "значение", чтобы избежать проблем с двойными кавычками и независимо от строк значений.

Это эффективный, гибкий, быстрый (достаточно) и простой.

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

Приветствия. Кит.