我进行了一项需要逆向工程文件格式的研究，我目前正在寻找记录该工作的方法。
在网络上，您会找到使用方框图和自由文本的资源。例如，尝试查看 Microsoft Access：https : //github.com/brianb/mdbtools/blob/master/HACKING
这与 ISO 规范中针对格式所采用的方法相当一致。
这种类型的工作是我专业工作的一部分，但我没有遇到任何可以帮助我以一致且有用的方式为其他人存储我的信息 - 几个月后它甚至可能对我没有用处。
是否有“社区”最佳实践（方法、工具、创作工具等）来帮助将文档研究成文件格式？
同意V，只是抛出一些想法。
通常会说，（当然）必须将孔清楚地表示为黑色或灰色。如“不知道”或“几种可能性”。
除了公开分发的文件格式规范之外，我发现 RFC 使用的风格是我经常适应的风格。一切都取决于上下文，使用诸如此处所示的增强巴科斯-诺尔形式之类的东西。
使用真值表和逻辑表达式来断言明确性。
另外还有例如3GPP等也可以学习。
如果你想使用良好的 ASCII 风格，使用像asciiflow这样的工具来 绘制流程图等。我发现使用 ASCII 经常可以帮助我编写更清晰的文档并将图表拆分为更易于理解的层。也许人们也可以从phrack中学到一些东西 。
如果不是纯文本，那么 LaTeX 因为它非常适合组织文档。将每个部分分成自己包含的文件。像索引等一样，在各部分周围进行洗牌变得容易。而且该产品在纸上看起来很棒。– 这当然也可以通过纯文本以某种方式完成。
与任何方法一样 (I) 总是使用 Git 并通过简短的简洁注释非常频繁地提交。
过去，我对文件格式的逆向工程工作记录在源代码中，即010 Editor 二进制模板。如果您了解 C，这将是非常具有描述性的，但它有其局限性，有时在尝试表达某些更奇特的概念时可能会变得有点复杂。该工具的另一个问题是较大文件上较大脚本的速度较慢，并且缺乏脚本和二进制模板（例如插件）之外的扩展机制。
提到的增强 BNF 的一个广泛使用的替代方案是ASN.1（永久链接）。我更喜欢 BER 编码（请参阅维基百科文章的上一个链接），但您的里程可能会有所不同。
对于图形表示，我使用了 LaTeX（带有bytefield、PDF）和 Visio。
像@0xC0000022L 一样，我倾向于首先在源文件中记录，或者在可以立即在工具中重用的东西中（与纯文本文档不同）。
通用方法是使用具有注释或描述结构的能力的十六进制编辑器
我想不出比框图、伪代码实现和可能的参考实现更“标准”的东西。
以此处的 FIPS 标准或 LUKS 标准文档为例。它们提供了功能的基本叙述、伪代码，在 OGG/OGV 的情况下甚至提供了完整的参考实现。在我看来，您拆开的标准应该以与您设计的标准相同的方式记录。有些字段可能是“未知的”或“似乎很神奇，就离开吧”。
我不认为你会找到比这更标准的东西。如果你不介意发布文档和解析器，github/bitbucket/etc 很棒。其他一些文件格式问题指向 Wotsit.org（我在那里查看），因此提交链接也可能是一件好事。