源代码中的文件数据?

发布于 2024-12-22 14:03:43 字数 233 浏览 1 评论 0原文

我正在开发一个用于管理 STFS 文件的类,我需要的一些数据有数百字节长。我想知道使用源代码中的信息创建字节数组而不是从文件中读取它是否有任何问题。就像这样做:

byte[] data = new byte[0x100]{0x23,0x55,0xFF...

我认为无论你做什么,你都在创建一个字节数组,但我从未见过这样的代码,所以我认为这可能是错误的,或者不是出于可读性目的而完成的。

I'm working on a class for managing STFS files, and some of the data I need is hundreds of bytes long. I'm wondering if there's anything wrong with creating a byte array with that information in the source code instead of reading it from a file. Like doing:

byte[] data = new byte[0x100]{0x23,0x55,0xFF...

I would think that you're creating a byte array no matter what you do, but I've never seen any code like that, so I thought it might be wrong, or not done for readability purposes.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

爱冒险 2024-12-29 14:03:43

如果它是关于您读取的文件的验证(例如,标头),那么我认为可以在字节数组中声明值。但请确保,您的整个应用程序中只有一个这样的实例。

例如:

static class STFSValidation
{
     public static readonly byte[] Header = new byte[] { ... };
}

If it is about validation (e.g., headers) of files you read, then I think it is okay, to declare the values in a byte array. But be sure, that you have only one instance of that in your whole application.

For instance:

static class STFSValidation
{
     public static readonly byte[] Header = new byte[] { ... };
}
愿与i 2024-12-29 14:03:43

如果数据相对较小并且永远不会改变(永远=比源代码少得多),那是可以的。

做出决定时请考虑以下因素:

  • 是否需要在源中注释数据(即 magicHeader[3]=42;// 答案)。
  • 它相对较小吗(我想说最多 256 个条目)
  • 它是否会改变(即现有文件格式 GIF 的签名 - 0x47,0x49, 0x46, 0x38, 0x37, 0x61 本质上是一成不变的并且永远不会改变 - 在 http://en.wikipedia.org/wiki/Magic_number_(programming)#

对于将大型常量 blob 作为资源嵌入到应用程序中可能是更好的方法。

It is ok if data is relatively small and will not ever change (ever = singnificantly less often then source code).

Conisder following when making the decision:

  • do you need to comment data in the source (i.e. magicHeader[3]=42;// the answer).
  • is it relatively small (I'd say 256 entries is max)
  • does it ever change (i.e. signatures for existing file formats GIF - 0x47,0x49, 0x46, 0x38, 0x37, 0x61 are essentially set in stone and will not ever change - see more on magic numbers in http://en.wikipedia.org/wiki/Magic_number_(programming)# )

For large constant blobs embedding into an application as a resource may be better approach.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文