一般来说，使得您的文档在所有web服务器、代理和客户端浏览器中都能被正确处理的最安全方式可能如下：

1. 使用application/xml内容类型
2. 在内容类型中包括一个字符编码，可能是UTF-8
3. 在XML文档本身的编码属性中包括一个匹配的字符编码。

根据RFC 3023规范，一些浏览器没有正确实现，内容类型的主要区别在于客户端应如何处理字符编码，如下所示：

对于application/xml、application/xml-dtd、application/xml-external-parsed-entity或application/xml的任何一个子类型，例如application/atom+xml、application/rss+xml或application/rdf+xml，字符编码的确定顺序如下：

1. 在Content-Type HTTP标头的charset参数中给出的编码
2. 在文档内的XML声明中给出的编码属性
3. utf-8。

对于text/xml、text/xml-external-parsed-entity或text/foo+xml等子类型，文档内的XML声明中的编码属性将被忽略，字符编码为：

1. 在Content-Type HTTP标头的charset参数中给出的编码或
2. us-ascii。

大多数解析器没有实现规范；它们忽略HTTP Context-Type并仅使用文档中的编码。由于存在如此多的格式不正确的文档，这种情况很难在短期内改变。

text/xml和application/xml之间的区别在于，如果省略了charset参数，text/xml的默认字符编码是US-ASCII：

当明确指定字符集参数，text/xml和application/xml的行为是不同的。如果text/xml的默认字符集（即US-ASCII）由于某些原因（例如糟糕的Web服务器）不方便使用，则application/xml提供了一种替代方案（参见第3.2节中application/xml注册的“可选参数”部分）。

对于text/xml：

与[RFC2046]兼容，如果使用text/xml实体时省略了charset参数，则MIME处理器和XML处理器必须使用"default charset"值为"us-ascii"[ASCII]。如果通过HTTP传输XML MIME实体，则默认的字符集值仍然是"us-ascii"。

对于application/xml：

如果接收到省略了charset参数的application/xml实体，则MIME Content-Type头部未提供有关字符集的任何信息。符合要求的XML处理器必须遵循[XML]的第4.3.3节直接解决这种情况的要求。然而，不是XML处理器的MIME处理器不应该假设应用程序/xml实体中省略了charset参数时有一个默认的字符集。

因此，如果省略了charset参数，则text/xml的字符编码为US-ASCII，而application/xml的字符编码可以在文档中指定。

现在，互联网的一个经验法则是：“输出时要严格，但输入时要宽容。”这意味着在通过互联网传递数据时，尽可能遵守标准。但在接收和解释互联网数据时，建立一些机制来忽略故障或猜测。

因此，在您的情况下，只需选择两种类型之一（我建议使用application/xml），并确保正确指定所使用的字符编码（我建议使用相应的默认字符编码以保险起见，因此，对于application/xml，使用UTF-8或UTF-16）。