Преобразование простых свойств в строку в Java

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

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

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

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

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

• если это чисто внутренний формат, подойдет специальный формат, например простая конкатенация:

  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
);

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

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

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

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

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

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

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

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

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

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

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

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

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

internal use

в виде

it's used only by my components, not components written by others

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

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

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

Конфигурация Apache

Я понимаю, что это старая "смертоносная" тема, но у меня есть решение, которое не предлагалось ранее, и которое, я думаю, стоит бросить на ринг.

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

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

Чтобы создать элемент XML, вы просто «оборачиваете» атрибуты в элемент xml. Это:

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

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

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

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

Ваше здоровье. Кит.