正如@Uri所说，提供更多上下文会更好。我认为你的主要关注点不在于特定的编码方案，因为对于大多数编码方案而言，为简单的Map<String, String>自己设计编码方案是相当容易的。
一个有趣的问题是：这个中间字符串编码将用于什么？
if it's purely internal, an ad-hoc format is fine eg simple concatenation:
key1|value1|key2|value2
if humans night read it, a format like Ruby's map declaration is nice:
{ first_key => first_value,
second_key => second_value }
if the encoding is to send a serialised map over the wire to another application, the XML suggestion makes a lot of sense as it's standard-ish and reasonably self-documenting, at the cost of XML's verbosity.
<map>
<entry key='foo' value='bar'/>
<entry key='this' value='that'/>
</map>
if the map is going to be flushed to file and read back later by another Java application, @Cletus' suggestion of the Properties class is a good one, and has the additional benefit of being easy to open and inspect by human beings.
编辑：你已经添加了这是要存储在数据库列中的信息 - 是否有使用单个列而不是以下三个列的原因：
CREATE TABLE StringMaps
(
map_id NUMBER NOT NULL, -- ditch this if you only store one map...
key VARCHAR2 NOT NULL,
value VARCHAR2
);
我一直在考虑选择一种通用的表示方式来实现客户端和服务器之间的对话（传输内容）的需要，使用外观模式。我想要一种标准化、人类可读（简洁）、强大、快速的表示方式。我希望它能够轻松实现和运行，易于测试，并且易于“包装”。请注意，我已经根据我的定义和明确意图排除了 XML。
通过“包装”，我指的是我希望支持其他传输内容表示方式，例如 XML、SOAP、可能的 Java 属性或 Windows INI 格式、逗号分隔值（CSV）等，Google 协议缓冲区、自定义二进制格式、专有二进制格式（如 Microsoft Excel 工作簿）以及其他可能出现的格式。我将使用主要外观周围的包装器/装饰器来实现这些次要表示方式。每种次要表示方式都是可取的，特别是在某些情况下与其他系统集成，但由于各种缺点（未能满足上述任一标准），它们都不适合作为主要表示方式。
因此，到目前为止，我选择 JSON 格式作为我的主要传输内容表示方式。我打算在不久的将来详细探讨这个选项。
只有在极端的性能考虑下，我才会跳过翻译底层的传统格式。一个干净的设计的优点包括良好的性能（没有浪费的努力，易于维护），这只需要一个合适的硬件选择作为必要的补充即可。当性能需求变得极端时（例如，每天处理四万个总计四百万交易的传入数据文件），那么一切都必须重新审视。
作为开发人员、数据库管理员、架构师等等，我已经建立了几乎各种规模和描述的系统。我对我的标准选择非常自信，并热切期待其适用性的确认。事实上，我希望将其作为开源实现发布（但不要太急着期待）。
请注意，这个设计讨论忽略了传输媒介（HTTP、SMTP、RMI、.Net Remoting等），这是有意的。我发现将传输媒介和传输内容作为完全独立的设计考虑，比从系统本身出发更加有效。事实上，我的意图是使它们几乎可以“插拔式”的。
因此，我鼓励您强烈考虑使用JSON。祝一切顺利。
提供一些问题的额外背景会有所帮助。
如果您将以整个地图粒度进行编码和解码，为什么不直接使用XML呢？
仅供我编写的组件使用
），您可以连接密钥和值。我更喜欢在密钥和密钥之间以及密钥和值之间使用不同的分隔符：
而不是
key1+SEPARATOR+value1+SEPARATOR+key2 etc
我编码 < br/>
key1+SEPARATOR_KEY_AND_VALUE+value1+SEPARATOR_KEY(n)_AND_KEY(N+1)+key2 etc
如果您必须进行调试，这种方式更清晰（也是按设计而来的）
我知道这是一个旧的“死气沉沉”的帖子，但我有一个之前没有提出过的解决方案，我认为值得一试。
我们将地理要素的“任意”属性（即用户在运行时创建的）以标准XML属性格式存储在数据库中的单个CLOB列中。也就是说：
name="value" name="value" name="value"
String xmlString += "<arbitraryAttributes" + arbitraryAttributesString + " />"