问题标签 [file-format]

通过反向工程来自另一个应用程序的未加密二进制文件格式并读取内容，在我的应用程序中添加对第 3 方文件格式的支持是否合法？

您最喜欢的游戏无损图像格式（即 2d 游戏）是什么？为什么？

需要考虑的一些事情是磁盘大小、转换为可用格式的开销以及格式的特性（即 alpha 支持）。

没有最佳答案，但请务必尽您所能支持您的最佳答案！

我在文本编辑器中打开了我编译的 Hello World Obj-C 应用程序，令我惊讶的是，我发现了大约 8 KB 的 00 00 00 00 00 00 00 00 ...。

这些为什么会在这里？有没有办法清除这些零（我怀疑它有太多功能）？

显然它在这个文件中并不那么重要，因为它开始只有 16kB，但我还是想知道。

我用谷歌搜索并没有看到任何信息。应用程序使用什么格式和图标颜色深度？

我试图以编程方式查看总统竞选捐款，以查看哪些 web 2.0 人员为哪些候选人做出了贡献。您可以在网站http://www.fec.gov/finance/disclosure/ftpdet.shtml#a2007_2008上获取数据文件 indiv08.zip

我可以解析出谁贡献了以及他们贡献了多少，但我无法弄清楚贡献给了谁。似乎有一些 ID，但它与我能找到的任何其他文件中的候选 ID 都不匹配。如果您能对此提供帮助，我想我可以制作一个非常漂亮的页面，显示谁为哪个候选人做出了贡献。

更新——我想知道我是否误解了这个贡献系统。也许候选人根本无法收到捐款，只有委员会？比如我看到“C00431445OBAMA FOR AMERICA”收到了很多投稿。这使得将这些委员会与候选人联系起来变得更加复杂。基本上我想知道谁支持奥巴马，谁支持麦凯恩。

Garmin 和 TomTom 等导航系统一直让我着迷。我想实现小型地图/导航应用程序来尝试各种路径算法并扩展我对它们的了解。

这是一个两部分的问题：

1.) 地图数据如何存储？ - 当您拥有道路网络时，这些数据通常如何存储？保留哪些部分数据以便以后重现地图？每条道路是否存储为一系列改变方向的点？这些数据以何种文件格式存储？是否有公开可用的库来轻松解析这些文件？有没有人有关于如何存储/表示地图/道路数据的细节，这将非常有帮助。

2.）导航/路径 - 在此地图数据（la Garmin）上进行基本路径时，我的假设是否正确，即它被转换为有向图？每个道路交叉点是否是一个顶点，边缘加权顶点之间的距离？这就是我正在考虑做的，所以我可以尝试一些基本的众所周知的路径算法，看看我得到了什么。

我已经在美国看到了这个公开可用的地图数据，但我不确定它是如何表示的，以及它是否足够详细，让我能够从中构建我的有向图。

如果有人有任何信息，我将不胜感激。掌握的知识越详细越好。

我编写了一个基于矢量的 3D 编辑器（UI 自定义有点像技术图纸）。我现在想以可移植格式保存矢量/绘图数据。哪些格式可用；其中哪一个（一个？）是最被广泛接受的，我在哪里可以获得格式规范？

我正在寻找一种用于线框模型的简单文件格式。我知道 VRML、u3D 等，但这些对于我的需求来说似乎很重要。我的标准是：

• 必须有明确的规范。无论是开放的还是非常完善的/记录在案的。
• 我只需要（想要）简单的模型——顶点和边。我不想处理面孔或物体。如果格式支持更多，那很好，只要我可以忽略它们。
• 最终用户工具不是必需的，但会很棒。如果不是，它必须是人类可读的（并且对于简单模型是可编辑的）。
• 能够注释或至少标记节点会很好（但不是必需的）。
• 我使用什么语言并不重要，但可能的选项是 Java/C++ 和 OpenGL

还是我只是更好地将顶点/边缘列表写入文本文件并完成它？

Previously, I asked the question.

The problem is the demands of our file structure are very high.

For instance, we're trying to create a container with up to 4500 files and 500mb data.

The file structure of this container consists of

• SQLite DB (under 1mb)
• Text based xml-like file

• Images inside a dynamic folder structure that make up the rest of the 4,500ish files

• After the initial creation the images files are read only with the exception of deletion.

• The small db is used regularly when the container is accessed.

Tar, Zip and the likes are all too slow (even with 0 compression). Slow is subjective I know, but to untar a container of this size is over 20 seconds.

Any thoughts?

我正在寻找用于保存和查看 3D 场景（工程仿真模型和结果的可视化）的跨平台解决方案，但那里（仍然）似乎并不多。

大约 10 年前，我对此进行了研究，然后选择了 VRML（并开始了最终转向OpenVRML的项目）。不幸的是，在过去的十年里，VRML/X3D 并没有变得无处不在。

理想的解决方案是提供一个 C++ 库，该库可以插入到某个级别的 3D 渲染管道中，以将 3D 场景捕获到文件中；以及一个可自由再分发的查看器，允许查看操作、部分隐藏、注释、尺寸标注等。至少应该支持 linux、mac 和 windows。

3D PDF 似乎可以满足大多数查看器的要求，但 Adob​​e sdk 显然只能在 Windows 上使用。

有什么建议么 ？