Java 应用程序配置文件
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/12144/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Application configuration files
提问by ninesided
OK, so I don't want to start a holy-war here, but we're in the process of trying to consolidate the way we handle our application configuration files and we're struggling to make a decision on the best approach to take. At the moment, every application we distribute is using it's own ad-hoc configuration files, whether it's property files (ini style), XML or JSON (internal use only at the moment!).
好的，所以我不想在这里开始一场圣战，但我们正在努力整合我们处理应用程序配置文件的方式，我们正在努力决定采取的最佳方法. 目前，我们分发的每个应用程序都在使用它自己的临时配置文件，无论是属性文件（ini 样式）、XML 还是 JSON（目前仅供内部使用！）。
Most of our code is Java at the moment, so we've been looking at Apache Commons Config, but we've found it to be quite verbose. We've also looked at XMLBeans, but it seems like a lot of faffing around. I also feel as though I'm being pushed towards XML as a format, but my clients and colleagues are apprehensive about trying something else. I can understand it from the client's perspective, everybody's heard of XML, but at the end of the day, shouldn't be using the right tool for the job?
目前我们的大部分代码都是 Java，所以我们一直在研究Apache Commons Config，但我们发现它非常冗长。我们还研究了XMLBeans，但它似乎有很多闲谈。我也觉得好像我被推向了 XML 作为一种格式，但我的客户和同事对尝试其他东西感到担忧。我可以从客户的角度理解它，每个人都听说过 XML，但归根结底，不应该使用正确的工具来完成这项工作吗？
What formats and libraries are people using in production systems these days, is anyone else trying to avoid the angle bracket tax?
这些天人们在生产系统中使用什么格式和库，还有其他人试图避免尖括号税吗？
Edit:really needs to be a cross platform solution: Linux, Windows, Solaris etc. and the choice of library used to interface with configuration files is just as important as the choice of format.
编辑：确实需要一个跨平台的解决方案：Linux、Windows、Solaris 等，用于与配置文件交互的库的选择与格式的选择一样重要。
采纳答案by Herms
XML XML XML XML. We're talking config files here. There is no "angle bracket tax" if you're not serializing objects in a performance-intense situation.
XML XML XML XML。我们在这里谈论配置文件。如果您不是在性能密集的情况下序列化对象，则没有“尖括号税”。
Config files must be human readable and human understandable, in addition to machine readable. XML is a good compromise between the two.
除了机器可读之外，配置文件还必须是人类可读和人类可理解的。XML 是两者之间的一个很好的折衷方案。
If your shop has people that are afraid of that new-fangled XML technology, I feel bad for you.
如果您的商店有人害怕这种新奇的 XML 技术，我为您感到难过。
回答by epatel
What platform are you working on? I'd recommend trying to use the preferred/common method for it.
你在什么平台上工作？我建议尝试使用首选/常用方法。
- MacOSX - plists
- Win32 - Registry (or are there a new one here, long since I developed on it)
- Linux/Unix - ~/.apprc (name-value perhaps)
- MacOSX - plists
- Win32 - 注册表（或者这里有一个新的，我在它上面开发很久了）
- Linux/Unix - ~/.apprc （可能是名称-值）
回答by rjzii
As far as I know, the Windows registry is no longer the preferred way of storing configuration if you are using .NET - most applications now make use of System.Configuration [1, 2]. Since this is also XML based it seems to be that everything is moving in the direction of using XML for configuration.
据我所知，如果您使用 .NET，Windows 注册表不再是存储配置的首选方式 - 大多数应用程序现在都使用 System.Configuration [1, 2]。由于这也是基于 XML 的，似乎一切都朝着使用 XML 进行配置的方向发展。
If you want to stay cross-platform I would say that using some sort of a text file would be the best route to go. As for the formatting of said file, you might want to take into account if a human is going to be manipulating it or not. XML seems to be a bit more friendly to manual manipulation than INI files due to the visible structure of the file.
如果你想保持跨平台，我会说使用某种文本文件将是最好的方法。至于所述文件的格式，您可能需要考虑是否有人要操作它。由于文件的可见结构，XML 似乎比 INI 文件对手动操作更友好一些。
As for the angle bracket tax - I don't worry about it too often as the XML libraries take care of abstracting it. The only time it might be a consideration is if you have very little storage space to work with and every byte counts.
至于尖括号税 - 我不太担心它，因为 XML 库负责抽象它。唯一可能需要考虑的情况是，如果您的存储空间很小并且每个字节都很重要。
[1] System.Configuration Namespace - http://msdn.microsoft.com/en-us/library/system.configuration.aspx
[1] System.Configuration 命名空间 - http://msdn.microsoft.com/en-us/library/system.configuration.aspx
[2] Using Application Configuration Files in .NET - http://www.developer.com/net/net/article.php/3396111
[2] 在 .NET 中使用应用程序配置文件 - http://www.developer.com/net/net/article.php/3396111
回答by Kev
Without starting a new holy war, the sentiments of the 'angle bracket tax' post is one area where I majorly disagreewith Jeff. There's nothing wrong with XML, it's reasonably human readable (as much as YAML or JSON or INI files are) but remember its intent is to be read by machines. Most language/framework combos come with an XML parser of some sort for free which makes XML a pretty good choice.
在没有开始新的圣战的情况下，“尖括号税”帖子的观点是我主要不同意杰夫的一个领域。XML 没有任何问题，它具有合理的人类可读性（与 YAML 或 JSON 或 INI 文件一样多），但请记住它的意图是由机器读取。大多数语言/框架组合都带有某种免费的 XML 解析器，这使 XML 成为一个不错的选择。
Also, if you're using a good IDE like Visual Studio, and if the XML comes with a schema, you can give the schema to VS and magically you get intellisense (you can get one for NHibernate for example).
此外，如果您使用的是像 Visual Studio 这样的好 IDE，并且如果 XML 带有架构，您可以将架构提供给 VS 并且神奇地获得智能感知（例如，您可以为 NHibernate 获得一个）。
Ulimately you need to think about how often you're going to be touching these files once in production, probably not that often.
最终，您需要考虑在生产中接触这些文件的频率，可能不会那么频繁。
This still says it all for me about XML and why it's still a valid choice for config files (from Tim Bray):
这对我来说仍然说明了 XML 以及为什么它仍然是配置文件的有效选择（来自Tim Bray）：
"If you want to provide general-purpose data that the receiver might want to do unforeseen weird and crazy things with, or if you want to be really paranoid and picky about i18n, or if what you're sending is more like a document than a struct, or if the order of the data matters, or if the data is potentially long-lived (as in, more than seconds) XML is the way to go. It also seems to me that the combination of XML and XPath hits a sweet spot for data formats that need to be extensible; that is to say, it's pretty easy to write XML-processing code that won't fail in the presence of changes to the message format that don't touch the piece you care about."
“如果你想提供通用数据，接收者可能想用这些数据做无法预料的奇怪和疯狂的事情，或者如果你想对 i18n 非常偏执和挑剔，或者如果你发送的东西更像是一份文件而不是一个结构，或者如果数据的顺序很重要，或者数据是否可能存在很长时间（例如，超过几秒钟）XML 是要走的路。在我看来，XML 和 XPath 的组合也达到了需要可扩展的数据格式的最佳位置；也就是说，编写 XML 处理代码非常容易，这些代码不会因不涉及您关心的部分的消息格式更改而失败。 ”
回答by dlinsin
We are using properties files, simply because Java supports them natively. A couple of months ago I saw that SpringSource Application Platform uses JSON to configure their server and it looks very interesting. I compared various configuration notationsand came to the conclusion that XML seems to be the best fit at the moment. It has nice tools support and is rather platform independent.
我们正在使用属性文件，仅仅是因为 Java 本身就支持它们。几个月前，我看到 SpringSource 应用程序平台使用 JSON 来配置他们的服务器，看起来很有趣。我比较了各种配置符号，得出的结论是 XML 似乎是目前最合适的。它有很好的工具支持，并且与平台无关。
回答by Clint Davis
回答by Herms
Re: epatel's comment
回复：epatel 的评论
I think the original question was asking about application configuration that an admin would be doing, not just storing user preferences. The suggestions you gave seem more for user prefs than application config, and aren't usually something that the user would ever deal with directly (the app should provide the configuration options in the UI, and then update the files). I really hope you'd never make the user have to view/edit the Registry. :)
我认为最初的问题是询问管理员将要做的应用程序配置，而不仅仅是存储用户首选项。您提供的建议似乎更适合用户偏好而不是应用程序配置，并且通常不是用户会直接处理的内容（应用程序应在 UI 中提供配置选项，然后更新文件）。我真的希望您永远不要让用户必须查看/编辑注册表。:)
As for the actual question, I'd say XML is probably OK, as plenty of people will be used to using that for configuration. As long as you organize the configuration values in an easy to use manner then the "angle bracket tax" shouldn't be too bad.
至于实际问题，我想说 XML 可能没问题，因为很多人会习惯使用它进行配置。只要您以易于使用的方式组织配置值，那么“尖括号税”应该不会太糟糕。
回答by epatel
@Herms
@赫姆斯
What I really meant was to stick to the recommended way software should store configuration values for any given platform.
我真正的意思是坚持推荐的软件应该为任何给定平台存储配置值的方式。
What you often get then is also the recommended ways these should/can be modified. Like a configuration menu in a program or a configuration panel in a "system prefs" application (for system services softwares ie). Not letting the end users modify them directly via RegEdit or NotePad...
您经常得到的也是这些应该/可以修改的推荐方式。就像程序中的配置菜单或“系统偏好设置”应用程序中的配置面板（即系统服务软件）。不允许最终用户直接通过 RegEdit 或 NotePad 修改它们...
Why?
为什么？
- The end users (=customers) are used to their platforms
- System for backups can better save "safe setups" etc
- 最终用户（=客户）习惯了他们的平台
- 备份系统可以更好地保存“安全设置”等
@ninesided
@九边
About " choice of library", try to link in (static link) any selected library to lower the risk of getting into a version-conflict-war on end users machines.
关于“库的选择”，尝试链接（静态链接）任何选定的库，以降低在最终用户机器上陷入版本冲突的风险。
回答by engtech
YAML, for the simple reason that it makes for very readable configuration files compared to XML.
YAML，原因很简单，与 XML 相比，它使配置文件更具可读性。
XML:
XML：
<user id="babooey" on="cpu1">
<firstname>Bob</firstname>
<lastname>Abooey</lastname>
<department>adv</department>
<cell>555-1212</cell>
<address password="xxxx">[email protected]</address>
<address password="xxxx">[email protected]</address>
</user>
YAML:
YAML：
babooey:
computer : cpu1
firstname: Bob
lastname: Abooey
cell: 555-1212
addresses:
- address: [email protected]
password: xxxx
- address: [email protected]
password: xxxx
The examples were taken from this page: http://www.kuro5hin.org/story/2004/10/29/14225/062
回答by Lars M?hlum
XML, JSON, INI.
They all have their strengths and weaknesses.
In an application context, I feel that the abstraction layer is the important thing.
If you can choose a way to structure the data that is a good middle ground between human readability and how you want to access/abstract the data in code, you're golden.
XML、JSON、INI。
他们都有自己的优点和缺点。
在应用程序上下文中，我觉得抽象层是重要的。
如果您可以选择一种结构化数据的方法，在人类可读性和您希望如何在代码中访问/抽象数据之间取得良好的中间立场，那么您就是黄金。
We mostly use XML where I work, and I cant really believe that a configuration file loaded into a cache as objects when first read or after it has been written to, and then abstracted away from the rest of the program, really is that much of a hit on neither CPU nor disk space.
And it is pretty readable too, as long as you structure the file right.
我们主要在我工作的地方使用 XML，我真的不敢相信一个配置文件在第一次读取或写入后作为对象加载到缓存中，然后从程序的其余部分抽象出来，真的是那么多CPU 和磁盘空间都没有受到影响。
只要您正确构建文件，它也非常可读。
And all languages on all platforms supports XML through some pretty common libraries.
所有平台上的所有语言都通过一些非常常见的库支持 XML。
