我的应用程序应该使用什么文件格式？
我正在编写一个管理待办事项列表的应用程序。与“传统”待办事项列表应用程序不同，我希望用户将这些待办事项列表文件放在其文件系统上并且可见，而不是被应用程序神奇地隐藏。我希望用户能够通过电子邮件互相发送待办事项列表等等。此外，我稍后打算创建一个带有数据库后端的 Web 应用程序，允许用户在待办事项列表上进行协作。
我的问题是，我应该使用什么文件格式来存储应用程序的本地文件？ 当我开始思考这个问题时，我首先想到的是 XML 因为它（在某种程度上） ）可读，但后来我想到了 sqlite 然后发现了 sqlite yaml.org/" rel="nofollow noreferrer">YAML 现在我很困惑。一些指导将不胜感激。
更新：
我应该提到，我很可能会使用 C++、Objective C 或（尽管可能性不大）Python 进行编码。因此，无论提出什么格式，都需要有适当的库。
更新 2：
我还担心能够将所有这些不同的格式与我的应用程序关联起来，因此当打开我的应用程序格式的文件时，我的应用程序将打开，而不是文本编辑器之类的东西。
I'm writing an application that manages todo lists. Unlike 'traditional' todo list applications I want users to have these todo list files sit on their filesystem and be visible instead of being magically hidden by the app. I want users to be able to email todo lists to each other and so on. In addition, I later intend to create a web app with a database backend that will allow users to collaborate on todo lists.
The question I have is, what file format should I use to store the local files of my application?
When I started thinking about this, the first think that came to mind was XML because it's (somewhat) readable but then I thought about sqlite then found out about YAML
and now I'm quite confused. Some guidance would be appreciated.
Update:
I should mention that I will most probably be coding this in C++, Objective C or (not very likely, though) python. So whatever format is proposed it needs to have appropriate libraries.
Update 2:
I'm also concerned about being able to associate all these different formats with my applications so when opens a file of my application format, my application opens up instead of something like a text editor.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我会说 XML，但即使我建议这样做，我还是有一种感觉，既然你问了这个问题，我建议你买一本关于这个主题的编程书并开始阅读......这是一个学校项目吗？
I would say XML, but even as I suggest this, I get a feeling that since you asked this question, I recommend that you get a programming book on this topic and start reading.... Is this for a school project?
另一种选择是使用打包文件格式，特别是如果您希望能够将其他内容（例如图像）嵌入到文档中。优点是用户只需发送一个嵌入了所有内容的文件。另一个优点是可以很好地压缩大型 XML 结构。
此类格式的示例包括 ODF（开放文档格式），它使用包含清单文件的 zip 包，或 Office OpenXML，它使用 OPC（开放打包约定）容器。这两种格式均由 ISO 标准化。
Another alternative, especially if you want to be able to embed other content into your documents such as images, is to use a packaging file format. The advantage is that users only will have to send a single file, which has all content embedded. Another advantage is that large XML structures can be well compressed.
Examples of such formats are ODF (OpenDocument Format), which uses a zip package containing a manifest file, or Office OpenXML, which uses an OPC (Open Packaging Conventions) container. Both formats are standardized by ISO.
在您的应用程序中使用 sqlite 并添加导出/导入功能来导出/导入 xml 中的这些列表怎么样？
What about using sqlite in your app and adding an export / import functionallity that would export/import those lists in xml?
如果您希望用户能够将文件编辑为文本，那么任何文本格式都应该没问题，而且这更多的是偏好问题。
如果您不希望用户能够将其编辑为文本（他们意外弄乱数据的可能性较小），而是只有他们通过您的应用程序编辑文件，那么我会选择 Sqlite。
关于关联文件格式，您不关联格式，而是关联文件扩展名，因此如果您不希望它们与其他应用程序关联，请创建您自己的文件扩展名并将您的应用程序注册到其中。
If you want users to be able to edit the files as text, then any of the text formats should be fine and it's more a matter of preference than anything else.
If you don't want users to be able to edit it as text (less chance of them messing up the data accidentally) and instead they edit the file through your application only then I'd go with Sqlite.
Regarding associating the file format, you don't associate formats, you associate file extensions, so if you don't want them to be associated to another app, make up your own file extension and register your app to it.
我非常喜欢使用 SQLite 数据库作为文档文件（为您提供结构、良好的分析工具、事务等）；但如果您希望用户简单地获取文档并通过电子邮件发送，那么基于文本的强大格式会更好。
XML 是一种可能性；但它太冗长和丑陋了。 YAML 更具可读性，它看起来像 .INI 文件，但具有更多结构。 JSON是一种中间体，不像YAML那么可读，也不像XML那么难看。
所有三种格式都可以采用任意结构，生成基于文本的表示并从中重建结构，因此它们在功能上是等效的。
XML 的主要优点似乎是当它被意外损坏时很容易检测到，因为它将不再是格式良好的文档。但向任何格式添加一些校验和或类似字段并不难。
I'm a big fan of using SQLite databases as document files (gives you structure, a good analysis tool, transactions, etc); but if you want the user to simply take the document and email it, a robust text-based format would be much better.
XML is a possibility; but it's far too verbose and ugly. YAML is a lot more readable, it can look like an .INI file, but with more structure. JSON is an intermediate, not as readable as YAML, not as ugly as XML.
All three formats can take any arbitrary structure, produce the text-based representation and reconstruct the structure from it, so they're functionally equivalent.
The main advantage of XML seem to be that it's easy to detect when it has been accidentally damaged, because it will no longer be a well-formed document. But it's not hard to add some checksums or similar fields to any format.