补丁文件的正确 mime 类型
有人知道补丁文件的“正确”mime 类型是什么吗？我一直在使用 application/octet-stream 因为我在 iana.org。 application/octet-stream 是否正确，或者是否有其他更适合的内容？为什么没有 application/patch 类型？
显然，一个可能的答案是 text/plain，但我见过许多补丁文件，其中包含非纯文本的数据。如果您知道所有内容都是文本，那么 text/plain 是最佳选择，还是在所有补丁文件中保持一致更好？
我应该说我主要考虑的上下文是将 mime-type 设置为颠覆处理行结尾的线索（svn:mime-type 和 svn:eol-style< /代码>）。问题是补丁文件可能会同时修补使用 eol 样式本机 和非本机 的文件，这可能会导致应用补丁时出现行结束奇怪的情况结帐后。
Anybody know what the "proper" mime-type for patch files would be? I have been using application/octet-stream because I don't see anything better at iana.org. Is application/octet-stream correct, or is there something else that fits better? Why is there no application/patch type?
Obviously, one possible answer is text/plain, but I have seen many patch files which include data which is not purely text. Is text/plain the best choice if you know for a fact all content is text, or is it better to be consistent across all patch files?
I should say the context I am mainly thinking about this in is setting mime-type as a clue to subversion about handling line-endings (svn:mime-type and svn:eol-style). The issue is that a patch file may patch both files which use eol-style native as well as non-native, which can lead to line-ending weirdness when applying a patch post-checkout.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我也找不到权威版本。这里有一些其他的可能性：
text/x-difftext/x-patchapplication/x-patch对于它的价值，Trac（具有良好 svn 支持的票证跟踪器）使用
text/x-patch进行差异。 git.kernel.org 和 GitHub 使用text/plain。I couldn't find an authoritative version either. Here's some other possibilities:
text/x-difftext/x-patchapplication/x-patchFor what it's worth, Trac (a ticket tracker with good svn support) uses
text/x-patchfor diffs. git.kernel.org and GitHub usetext/plain.如果您的补丁仅包含文本，我更喜欢
text/plain而不是text/x-patch或text/x-diff。 IMO，text/x-patch或-diff更适合此目的，并且是 一些项目，但text/plain的主要原因是兼容性。在Gmail中，如果附件是
text/plain，当您点击它时，它会自动弹出文档预览；但它不适用于text/x-patch或text/x-diff。另一个例子是Mailman（流行的邮件列表管理软件）的存档界面：它 使用text/plain显示文本，但 不与text/x-patch。如果您的补丁包含二进制数据，我会使用
application/octet-stream，不是因为它是正确的，而是因为它会为您省去一些行结尾的麻烦。If your patch only contains text, I would prefer
text/plainovertext/x-patchortext/x-diff. IMO,text/x-patchor-diffis more suitable for this purpose, and is recommended by some projects, but the main reason fortext/plainis compatibility.In Gmail if the attachment is
text/plain, when you click it it will automatically pop up a document preview; but it will not fortext/x-patchortext/x-diff. Another example is the archive interface of Mailman (a popular mailing list management software): it shows the text withtext/plain, but does not withtext/x-patch.If your patch contains binary data, I would use
application/octet-stream, not because it is correct but it will save you some trouble from line endings.我很好奇你为什么要将补丁文件签入 SVN。除此之外，我会假设您是否有可能检查二进制补丁文件以使用 application/octet-stream。
我不确定如果你混合它们会发生什么......文本为文本，八位字节为二进制......这也可能吗？
I'm curious why you are checking in patch files to SVN. That aside, I would go with the assumption that if you have the possibility of checking binary patch files to use application/octet-stream.
I'm not sure what would happen if you mixed them... text for text, octet for binary... that might also be possible?