如何将二进制文件转换为 ascii 以进行源代码管理？
我非常清楚，在一般情况下，这里的答案是“你不知道”。我之所以问这个问题，是因为 SAP 的一位 PM 问我为什么 Crystal Report 的 TXT 输出不能满足我的需求。过去，我见过二进制文件（特别是 .doc，iirc）的转换器可以与 Subversion（或者可能是 TortoiseSVN）顺利配合，将文件转换为 ASCII 并返回，以便合并/分支/协调实际上起作用。我希望能够指着它们说“这就是我需要的”，但我很遗憾我是否还记得上次找到它们的谷歌搜索。谁能帮我减轻一点痛苦并为我指明正确的方向？谢谢。
I'm all too well aware that the answer here, in the general case, is "you don't." The reason I'm asking is that a PM at SAP is asking me why a TXT output of a Crystal Report doesn't meet my needs. In the past, I've seen converters for binary files (.doc in particular, iirc) that worked smoothly with Subversion (or maybe TortoiseSVN) to convert the files to ASCII and back so that merging/branching/reconciling actually worked. I'd like to be able to point at them and say "This is what I need", but I'm darned if I can remember the Google search that pulled them up last time. Can anyone save me a little pain and point me in the right direction? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当使用SVN时，你可以使用属性来告诉他它是二进制的。如果您确实想要，我想到的第一个解决方案（但不是非常有效）是使用 uuencode / uudecode。
When using SVN you could use properties to tell him that it is binary. In case you really want, the first solution that came to my mind (but not a very efficient) is to use uuencode / uudecode.
好吧，二进制或 ASCII 之间的区别并不大，而是您是否需要面向行的差异/冲突解决方案。即使是像 UTF-8 XML 这样的非 ASCII 解决方案也可能有所帮助（并且会带来与同一级别上的元素排序有关的“有趣”问题）。
编码二进制文件的最标准方法可能是 base64 编码。各种形状和风格的实施都很容易获得。当然，它会增加文件的大小，而且我敢打赌，如果发生更改，SVN 只能保留文件的前缀，因为更改点之后的后续编码数据将完全不同。
Well, it's not so much the difference between binary or ASCII, but rather if a line-oriented diff/conflict resolution is what you need. Even a non-ASCII solution like UTF-8 XML could help (and brings "interesting" problems with regard to ordering of elements on the same level).
The most standard way of encoding binaries is probably base64 encoding. Implementations are readily available in all shapes and flavours. Of course it'll increase the size of the file, and I'd bet that SVN can only ever preserve the prefix of the file if there's a change, as the subsequent encoded data after the point of change will be completely different.