创建自己的文件后缀时有什么命名约定吗?
我正在开发一个小游戏,并想将图像和其他资源打包到我自己的文件中,以保持目录整洁。然后我想,是否有任何约定可以称呼我的文件,或者我可以简单地称呼它而无需任何人关心吗?对于这个相当无辜的话题,可能没有太多强烈的意见,但我想我最好对此做出某种回应。
最明显的是不使用保留字符。
< > : " / \ | ? *
这些是 Windows 的。有人愿意添加在其他系统上保留的字符吗?
我猜不应该使用一些标准后缀,除非该文件实际上适用于后缀的标准。
.bat.exe.dll.lib.cmd
然后还有所有图像文件类型以及其他什么,但这些都是显而易见的。还有什么?
你的意见是什么?我应该尽可能唯一地命名我的后缀,例如 .maf(我的很棒的文件)或其他什么...或者我应该提供更多信息并坚持使用可能揭示我的文件实际上在做什么的已知后缀?或者也许是乏味的旧 .dat 或 .bin?
I'm working on a little game and figured I'd pack images and other resources into my own files to keep the directories neat. Then I thought, is there any convention to what I should call my file, or can I simply call it what ever without anyone ever caring? There's probably not a lot of strong opinions about this rather innocent subject, but I thought I'd better have some kind of response on it.
The most obvious would be to not use reserved characters.
< > : " / \ | ? *
Those are the ones for windows. Anyone care to add what characters are reserved on other systems?
There's some standard suffixes that I'm guessing shouldn't be used, unless the file actually apply to the suffix's standard.
.bat .exe .dll .lib .cmd
And then there's all the image file types and what not, but those are about as obvious. What more?
What is your opinion? Should I name my suffix as uniquely as possible, say .maf (My Awesome File) or what ever... or should I be more informative and stick to a known suffix that might reveal what my file is actually doing there? Or perhaps a bland old .dat or .bin?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
如果您想创建一些与您的程序关联的东西,您当然希望它尽可能独特。当您想出一个扩展时,请检查 FILExt 看看它是否与任何主要内容冲突。
如果您只是想传达“这是一个二进制文件,不要尝试在记事本中打开它或篡改它”,我会选择类似
.bin
的内容,是的。If you want to create something that you want to associate with your program, you do, of course, want it to be as unique as possible. When you come up with an extension, check with FILExt to see if it's conflicting with anything major.
If you just want to convey "this is a binary file, don't try to open it in notepad or tamper with it", i'd go with something like
.bin
, yes.Unix 平台没有文件名限制(NULL 和正斜杠除外),因此不必担心 Windows 不喜欢的任何字符。
您可以担心使用以前从未使用过的扩展名,但除非您想使用很长的扩展名,否则我想说不要打扰,您始终可以使用诸如
.dat或<代码>.bin。您实际上甚至不需要使用扩展名,这(imo)也一样好,除非您将分发其中一些文件而不是与程序一起分发(例如,用户制作的地图,您将需要一个扩展名)因为用户将分发文件)。
您可能需要考虑的另一个小问题是,MS DOS 扩展名必须在点后恰好三个字符。与 DOS 兼容并不是一个大问题(实际上根本不是问题),但这就是为什么您会看到很多扩展名都是三个字符。
Unix platforms don't have filename restrictions (other than NULL and forward slash), so don't worry about any characters other than what Windows doesn't like.
You can worry about using an extension that hasn't been used before, but unless you want to use a really long one, I'd say don't bother, you can always go with something generic like
.dat
or.bin
. You don't actually need to even use an extension, which (imo) is just as good, unless you will be distributing some of these files other than with the program (for example, user made maps, you will want to have an extension since users will be distributing the files).Another minor point you might want to consider is that MS DOS extensions need to be exactly three characters after the dot. Being DOS compatible isn't a huge issue (not an issue at all really), but that's why you'll see a lot of extensions are three characters.
使用对您有意义的内容 - 我会避免众所周知的扩展,因为您建议避免它们被另一个应用程序意外打开。
大多数应用程序/游戏都会提供与应用程序名称或用途相关的扩展名(.doc、.psd 等...)。
Use what makes sense to you - I would avoid well known extensions, as you have proposed to avoid them being accidentaly opened by another application.
Most applications/games will give an extension that is related to the application name or use (.doc, .psd etc...).
除非用户要从资源管理器中双击文件,否则拥有一个信息丰富且唯一的扩展名并不重要,因此您可能需要使用
.bin
或.dat
。然而,存在将文件打包在一起的良好机制(.zip
或.7z
),因此您可能需要使用具有标准扩展名的标准打包程序。Unless users are going to double-click on the files from explorer, having a nice informative, unique extension is not important, so you might want to go with
.bin
or.dat
. However there exist good mechanisms for packing files together (.zip
or.7z
) so you might want to go for a standard packer, with a standard extension.