Let me start off with tried-and-true approaches, then point out some more recent approaches.
approaches that I have seen work with binary files
A long time ago, people expanded the old and the new versions of a binary file into temporary "text" files (every byte expanded to 3 bytes: 2 hex digits and a newline). Then run these two "text" files through an old version of "diff" (that definitely couldn't handle binary files) to make a patch file. Then we transmitted that "text" patch file over communication lines that were not yet 8-bit-clean. On the receive end, one expanded the old binary file into a temporary text version, then patched that old text file, and then compressed the new text file back into a binary file (compressing each pair of hex digits into one byte, and throwing away the newlines and any carriage returns that might have crept in).
More recently, I have been using rsync (or some utility built on top of it such as Unison). It handles arbitrary binary files just fine. I generally do a live update, with Unison running on my local machine and rsync running on the file server, talking back and forth to each other.
No matter how a patch file is generated, you can use any data compression utility to compress that file.
approaches that, as far as I know, ought to work with binary files
I hear that some tools based on rsync -- "rdiff" and "rdiff-backup" and "duplicity" -- allow you create a patch file. Then a person who receives that patch file can use it to update their old binary file to a new binary file.
The Wikipedia claims that recent versions of the standard "diff" and "patch" utilities support binary files. Have you tried that?
cutting-edge research in executable file compression
If you are interested in cutting-edge research on making the delta file as small as possible when updating executable files, you'll want to check out "How Courgette works" by Stephen Adams 2009 at The Chromium Projects.
Among other things, the computer that receives the patch "disassembles" the old application, converting all absolute addresses and offsets into symbols; then patches the disassembled code; then "reassembles" the patched code into the new version of the application.
I was looking for some binary diff tools for very large files (one LVM logical volume and its snapshots, because LVM doesn't support snapshot of snapshot yet) and xdelta works for me.
发布评论
评论（2）
让我从经过验证的方法开始，然后指出一些更新的方法。
我见过的处理二进制文件的方法
很久以前，人们将二进制文件的旧版本和新版本扩展为临时“文本”文件（每个字节扩展为 3 个字节：2 个十六进制数字）和换行符）。
然后通过旧版本的“diff”（肯定无法处理二进制文件）运行这两个“文本”文件来制作补丁文件。
然后我们通过还不是 8 位干净的通信线路传输该“文本”补丁文件。
在接收端，将旧的二进制文件扩展为临时文本版本，然后修补旧的文本文件，然后将新的文本文件压缩回二进制文件（将每对十六进制数字压缩为一个字节，并丢弃换行符和任何可能潜入的回车符）。
最近，我一直在使用 rsync （或在其之上构建的一些实用程序，例如 Unison ）。
它可以很好地处理任意二进制文件。
我通常会进行实时更新，Unison 在本地计算机上运行，rsync 在文件服务器上运行，彼此来回通信。
无论补丁文件是如何生成的，您都可以使用任何数据压缩实用程序来压缩该文件。
据我所知，应该使用二进制文件的方法
StackOverflow：“如何为二进制差异输出文件创建 PATCH 文件”
建议使用bsdiff。
另一个StackOverflow问题暗示“ vimdiff”似乎可以充分处理任意字节。
StackOverflow：“有用的二进制差异工具” 提到了一些其他的二进制差异工具。
我听说一些基于 rsync 的工具 - “rdiff” 和 “rdiff-backup ”和“口是心非”——允许您创建补丁文件。
然后，收到该补丁文件的人可以使用它将旧的二进制文件更新为新的二进制文件。
维基百科声称标准“diff”和“patch”实用程序的最新版本支持二进制文件。
你尝试过吗？
可执行文件压缩的前沿研究
如果您对更新可执行文件时使增量文件尽可能小的前沿研究感兴趣，您将需要查看
“西葫芦的工作原理”
作者：Stephen Adams，2009 年，Chromium 项目。
除此之外，接收补丁的计算机“反汇编”旧的应用程序，将所有绝对地址和偏移量转换为符号；然后修补反汇编代码；然后将修补后的代码“重新组装”到应用程序的新版本中。
Let me start off with tried-and-true approaches, then point out some more recent approaches.
approaches that I have seen work with binary files
A long time ago, people expanded the old and the new versions of a binary file into temporary "text" files (every byte expanded to 3 bytes: 2 hex digits and a newline).
Then run these two "text" files through an old version of "diff" (that definitely couldn't handle binary files) to make a patch file.
Then we transmitted that "text" patch file over communication lines that were not yet 8-bit-clean.
On the receive end, one expanded the old binary file into a temporary text version, then patched that old text file, and then compressed the new text file back into a binary file (compressing each pair of hex digits into one byte, and throwing away the newlines and any carriage returns that might have crept in).
More recently, I have been using rsync (or some utility built on top of it such as Unison).
It handles arbitrary binary files just fine.
I generally do a live update, with Unison running on my local machine and rsync running on the file server, talking back and forth to each other.
No matter how a patch file is generated, you can use any data compression utility to compress that file.
approaches that, as far as I know, ought to work with binary files
StackOverflow: "how to crate a PATCH file for the binary difference output file"
suggests using bsdiff.
Another StackOverflow question implies that "vimdiff" seems to handle arbitrary bytes adequately.
StackOverflow: "Useful Binary Diff Tool" mentions a few other binary difference tools.
I hear that some tools based on rsync -- "rdiff" and "rdiff-backup" and "duplicity" -- allow you create a patch file.
Then a person who receives that patch file can use it to update their old binary file to a new binary file.
The Wikipedia claims that recent versions of the standard "diff" and "patch" utilities support binary files.
Have you tried that?
cutting-edge research in executable file compression
If you are interested in cutting-edge research on making the delta file as small as possible when updating executable files, you'll want to check out
"How Courgette works"
by Stephen Adams 2009 at The Chromium Projects.
Among other things, the computer that receives the patch "disassembles" the old application, converting all absolute addresses and offsets into symbols; then patches the disassembled code; then "reassembles" the patched code into the new version of the application.
尝试xdelta。
我正在为非常大的文件（一个 LVM 逻辑卷及其快照，因为 LVM 还不支持快照的快照）寻找一些二进制差异工具，并且 xdelta 对我有用。
Try xdelta.
I was looking for some binary diff tools for very large files (one LVM logical volume and its snapshots, because LVM doesn't support snapshot of snapshot yet) and xdelta works for me.