blocks|key|802843|text|模型的序列化(如果您进入MVC)难道不是另一种方式吗？我更喜欢在语言(或标准库)中使用东西，而不是在可能的情况下使用自己的东西。我能看到的唯一问题是，文件大小可能比您想要的要大。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|802844|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Would serialization of the model (if you are into MVC) not be another way? I'd prefer to use things in the language (or standard libraries) rather then roll my own if possible. The only issue I can see with that is that the file size may be larger than you want.

blocks|key|2068354|text|您可以使用zip+(rar+/+7z+/+tar.gz+/.)图书馆。很多是存在的，大多数都经过了很好的测试，这可能会节省你一些时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2068355|不过，可能没那么有趣。|2068356|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You could use a zip (rar / 7z / tar.gz / ...) library. Many exists, most are well tested and it'll likely save you some time. 

Possibly not as much fun though.

blocks|key|2068452|text|(+1)这看上去正常吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2068453|看上去相当正常。但是，如果您要发明自己的格式，而不仅仅是使用Java序列化，那么您应该有一个很好的理由。你有什么好的理由(在某些情况下确实存在)？使用XStream的标准原因之一是使结果具有可读性，二进制格式会立即丢失。您有充分的理由使用二进制格式而不是人类可读的格式吗？关于人类可读性好(坏)的原因，请参见这个问题。|offset|length|2068454|把所有东西都放在一个签名的罐子里不是更容易吗。已经有标准Java库和工具可以这样做了，您可以获得压缩和验证。|2068455|2)您将用什么作为分隔符，以及如何确定它？|2068456|而不是分隔符，我会显式地在块之前存储每个块的长度。这也同样容易，如果分隔符是自己出现的，那么就避免了它的转义。|2068457|3)在这种情况下计算MD5的正确方法是什么？|2068458|有一个这里的示例代码，它看起来很明智。|2068459|4)关于这个问题，你建议读些什么？|2068460|关于序列化的主题？我读过关于Java序列化、JSON和XStream序列化的文章，所以我理解了每种序列化的优缺点，特别是人类可读的文件的好处。我还会查看一种典型的文件格式，例如Microsoft的文件格式，以了解每个字节在过去的日子里可能做出的设计决策，以及它们是如何被扩展的。例如：WAV文件格式。|2068461|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/developer/technicalArticles/Programming/serialization/|1|https://stackoverflow.com/questions/568671|2|http://java.sun.com/docs/books/tutorial/deployment/jar/apiindex.html|3|http://java.sun.com/docs/books/tutorial/deployment/jar/|4|http://www.java2s.com/Tutorial/Java/0490__Security/MD5MessageDigestyourmessage.htm|5|http://www.json.org/|6|http://ccrma.stanford.edu/courses/422/projects/WaveFormat/^0|0|U|7|0|4A|4|1|0|Q|7|2|Y|2|3|0|0|0|0|3|7|4|0|0|M|4|5|3Y|7|6|0^^$0|@$1|2|3|4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1E|8|@]|9|@$D|1F|E|1G|1|1H]|$D|1I|E|1J|1|1K]]|A|$]]|$1|F|3|G|5|6|7|1L|8|@]|9|@$D|1M|E|1N|1|1O]|$D|1P|E|1Q|1|1R]]|A|$]]|$1|H|3|I|5|6|7|1S|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1T|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1U|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1V|8|@]|9|@$D|1W|E|1X|1|1Y]]|A|$]]|$1|P|3|Q|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|20|8|@]|9|@$D|21|E|22|1|23]|$D|24|E|25|1|26]]|A|$]]|$1|T|3|-4|5|6|7|27|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10]]|11|$5|W|X|Y|A|$Z|12]]|13|$5|W|X|Y|A|$Z|14]]|15|$5|W|X|Y|A|$Z|16]]|17|$5|W|X|Y|A|$Z|18]]|19|$5|W|X|Y|A|$Z|1A]]|1B|$5|W|X|Y|A|$Z|1C]]]]

1) Does this look sane? 

It looks fairly sane. However, if you are going to invent your own format rather than just using <a href="http://java.sun.com/developer/technicalArticles/Programming/serialization/" rel="nofollow noreferrer">Java serialization</a> then you should have a good reason. Do you have any good reasons (they do exist in some cases)? One of the standard reasons for using XStream is to make the result human readable, which a binary format immediately loses. Do you have a good reason for a binary format rather than a human readable one? See <a href="https://stackoverflow.com/questions/568671">this question</a> for why human readable is good (and bad).

Wouldn't it be easier just to put everything in a signed jar. There are already <a href="http://java.sun.com/docs/books/tutorial/deployment/jar/apiindex.html" rel="nofollow noreferrer">standard Java libraries</a> and <a href="http://java.sun.com/docs/books/tutorial/deployment/jar/" rel="nofollow noreferrer">tools</a> to do this, and you get compression and verification provided.

2) What would you use for a delimiter and how determine it? 

Rather than a delimiter I'd explicitly store the length of each block before the block. It's just as easy, and prevents you having to escape the delimiter if it comes up on its own. 

3) The right way to calculate MD5 in this case? 

There is <a href="http://www.java2s.com/Tutorial/Java/0490__Security/MD5MessageDigestyourmessage.htm" rel="nofollow noreferrer">example code here</a> which looks sensible.

4) What would you suggest to read on the subject? 

On the subject of serialization? I'd read about the Java serialization, <a href="http://www.json.org/" rel="nofollow noreferrer">JSON</a>, and XStream serialization so I understood the pros and cons of each, especially the benefits of human readable files. I'd also look at a classic file format, for example from Microsoft, to understand possible design decisions from back in the days that every byte mattered, and how these have been extended. For example: <a href="http://ccrma.stanford.edu/courses/422/projects/WaveFormat/" rel="nofollow noreferrer">The WAV file format</a>.

blocks|key|538406|text|本码可能是走的路。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|538407|这是丹尼尔·斯皮瓦克(+Daniel+)的优秀的实施。|538408|不幸的是，bencode规范不支持utf8，这对我来说是一个展示障碍。|538409|稍后可能会出现这种情况，但目前xml似乎是一个更好的选择(+blobs序列化为Map)。|538410|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Bencode|1|http://www.codecommit.com/blog/java/bencode-stream-parsing-in-java^0|0|2|0|0|L|5|1|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|12|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]|R|$5|M|N|O|C|$P|S]]]]

<a href="http://en.wikipedia.org/wiki/Bencode" rel="nofollow noreferrer">Bencode</a> could be the way to go.

Here's an <a href="http://www.codecommit.com/blog/java/bencode-stream-parsing-in-java" rel="nofollow noreferrer">excellent implementation</a> by Daniel Spiewak.

Unfortunately, bencode spec doesn't support utf8 which is a showstopper for me.

Might come to this later but currently xml seems like a better choice (with blobs serialized as a Map).

blocks|key|2068573|text|也许您可以解释一下，这比使用现有的文件格式(如JAR+)更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2068574|大多数这种类型的标准文件格式只使用CRC作为其计算速度更快。如果您想要防止有意修改，MD5更合适。|2068575|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Perhaps you could explain how this is better than using an existing file format such as JAR.

Most standard files formats of this type just use CRC as its faster to calculate. MD5 is more appropriate if you want to prevent deliberate modification.

blocks|key|803123|text|看上去像INsane。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|803124|为什么要发明一种新的文件格式？|unordered-list-item|803125|为什么只试图阻止愚蠢的用户更改文件？|803126|为什么使用二进制格式(很难压缩)？|803127|为什么要使用在接收时不能解析的格式？(接收者必须接收整个文件，然后才能对文件进行操作。)|803128|XML已经是一种可压缩的序列化格式。因此，您正在序列化序列化格式。|803129|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|Q|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|R|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|S|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|T|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|N|$]]

It looks INsane.

<ul>
<li>why invent a new file format?</li>
<li>why try to prevent only stupid users from changing file?</li>
<li>why use a binary format ( hard to compress ) ?</li>
<li>why use a format that cannot be parsed while being received? (receiver has to receive entire file before being able to act on the file. ) </li>
<li>XML is already a serialization format that is compressable. So you are serializing a serialized format.</li>
</ul>

blocks|key|2068687|text|让我们看看这应该是非常简单的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2068688|前提条件：
0。应该是跨平台
1.要持久化的信息包括单个POJO+&任意byte[](实际上，POJO将其名称存储在String[]中)
2.只需要顺序访问
3.检查数据一致性的一种方法
4.应该是小而快的
5.应防止使用存档%2B记事本的普通用户修改数据|blockquote|2068689|你猜怎么着，你已经有了，它已经内置在平台里了：对象序列化|offset|length|2068690|如果您需要减少线路中发送的数据量，并提供自定义序列化(例如，您只可以为给定对象发送1,2,3次而不使用属性名称或不使用任何类似的属性，并以相同的顺序读取它们)，则可以使用此“隐藏特征”|2068691|如果您真的需要它在“文本纯文本”，您也可以编码它，它需要几乎相同的字节数量。|2068692|例如，这个bean：|2068693|import+java.io.*;
public+class+SimpleBean+implements+Serializable++{+
++++private+String+website+=+"http://stackoverflow.com";
++++public+String+toString()+{+
++++++++return+website;
++++}
}|code-block|syntax|javascript|2068694|可以这样代表：|2068695|rO0ABXNyAApTaW1wbGVCZWFuPB4W2ZRCqRICAAFMAAd3ZWJzaXRldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0ABhodHRwOi8vc3RhY2tvdmVyZmxvdy5jb20=|2068696|见这个答案|2068697|此外，如果你需要一个健全的协议，你也可以检查普罗托布夫，谷歌的内部交换格式。|2068698|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/javase/6/docs/technotes/guides/serialization/index.html|1|https://stackoverflow.com/questions/15496/hidden-features-of-java/142676#142676|2|https://stackoverflow.com/questions/134492/how-to-serialize-an-object-into-a-string/134918#134918|3|http://code.google.com/p/protobuf/^0|0|0|N|5|0|0|2E|6|1|0|0|0|0|0|0|0|5|2|0|M|5|3|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1G|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|1H|8|@]|9|@$G|1I|H|1J|1|1K]]|A|$]]|$1|I|3|J|5|6|7|1L|8|@]|9|@$G|1M|H|1N|1|1O]]|A|$]]|$1|K|3|L|5|6|7|1P|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|O|3|P|5|Q|7|1R|8|@]|9|@]|A|$R|S]]|$1|T|3|U|5|6|7|1S|8|@]|9|@]|A|$]]|$1|V|3|W|5|Q|7|1T|8|@]|9|@]|A|$R|S]]|$1|X|3|Y|5|6|7|1U|8|@]|9|@$G|1V|H|1W|1|1X]]|A|$]]|$1|Z|3|10|5|6|7|1Y|8|@]|9|@$G|1Z|H|20|1|21]]|A|$]]|$1|11|3|-4|5|6|7|22|8|@]|9|@]|A|$]]]|12|$13|$5|14|15|16|A|$17|18]]|19|$5|14|15|16|A|$17|1A]]|1B|$5|14|15|16|A|$17|1C]]|1D|$5|14|15|16|A|$17|1E]]]]

Let's see this should be pretty straightforward.
<blockquote>
Prerequisites:
0. should be cross-platform
1. information to be persisted includes a single POJO &amp; arbitrary byte[]s (files actually, the POJO stores it's names in a String[])
2. only sequential access is required
3. should be a way to check data consistency
4. should be small and fast
5. should prevent an average user with archiver + notepad from modifying the data
</blockquote>
Well guess what, you pretty much have it already, it's built-in the platform already:<a href="http://java.sun.com/javase/6/docs/technotes/guides/serialization/index.html" rel="nofollow noreferrer">Object Serialization</a>
If you need to reduce the amount of data sent in the wire and provide a custom serialization ( for instance you can sent only 1,2,3 for a given object without using the attribute name or nothing similar, and read them in the same sequence, ) you can use this somehow <a href="https://stackoverflow.com/questions/15496/hidden-features-of-java/142676#142676">&quot;Hidden feature&quot;</a>
If you really need it in &quot;text plain&quot; you can also encode it, it takes almost the same amount of bytes.
For instance this bean:
<pre><code>import java.io.*;
public class SimpleBean implements Serializable { 
 private String website = &quot;http://stackoverflow.com&quot;;
 public String toString() { 
 return website;
 }
}
</code></pre>
Could be represented like this:
<pre><code>rO0ABXNyAApTaW1wbGVCZWFuPB4W2ZRCqRICAAFMAAd3ZWJzaXRldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0ABhodHRwOi8vc3RhY2tvdmVyZmxvdy5jb20=
</code></pre>
<a href="https://stackoverflow.com/questions/134492/how-to-serialize-an-object-into-a-string/134918#134918">See this answer</a>
Additionally, if you need a sounded protocol you can also check to <a href="http://code.google.com/p/protobuf/" rel="nofollow noreferrer">Protobuf</a>, Google's internal exchange format.

blocks|key|2068728|text|我同意，这听起来并不像你需要一种新的格式，或二进制格式。如果您真的想要二进制格式，为什么不首先考虑其中一种：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2068729|二进制XML+(，Bnux)|unordered-list-item|2068730|赫斯|2068731|google数据包缓冲区|2068732|但是除此之外，许多文本格式也应该工作得很好(或者更好)；更容易调试，广泛的工具支持，压缩的大小与二进制(二进制压缩很差，信息论表明，对于相同的有效信息，相同的压缩率--这在我的测试中是正确的)。|2068733|因此，或许还应考虑：|2068734|Json运行良好；通过base64+(例如，http://jackson.codehaus.org/)提供二进制支持|offset|length|2068735|XML也不算太糟糕；高效的流解析器，有些具有base64支持(http://woodstox.codehaus.org/，“类型化访问API”，在base64下)|2068736|听起来你只是想自己做点什么。作为一种爱好，这没什么不对的，但如果是这样的话，你就需要把它当作一种爱好。这很可能不是您正在构建的系统的要求。|2068737|entityMap|0|LINK|mutability|MUTABLE|url|http://jackson.codehaus.org/|1|http://woodstox.codehaus.org/^0|0|0|0|0|0|0|M|S|0|0|V|T|1|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|15|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|16|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|17|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|18|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|19|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1A|8|@]|9|@$O|1B|P|1C|1|1D]]|A|$]]|$1|Q|3|R|5|D|7|1E|8|@]|9|@$O|1F|P|1G|1|1H]]|A|$]]|$1|S|3|T|5|6|7|1I|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]|12|$5|X|Y|Z|A|$10|13]]]]

I agree in that it doesn't really sound like you need a new format, or a binary one.
If you truly want a binary format, why not consider one of these first:

<ul>
<li>Binary XML (fast infoset, Bnux)</li>
<li>Hessian</li>
<li>google packet buffers</li>
</ul>

But besides that, many textual formats should work just fine (or perhaps better) too; easier to debug, extensive tool support, compresses to about same size as binary (binary compresses poorly, and information theory suggests that for same effective information, same compression rate is achieved -- and this has been true in my testing).

So perhaps also consider:

<ul>
<li>Json works well; binary support via base64 (with, say, <a href="http://jackson.codehaus.org/" rel="nofollow noreferrer">http://jackson.codehaus.org/</a>)</li>
<li>XML not too bad either; efficient streaming parsers, some with base64 support (<a href="http://woodstox.codehaus.org/" rel="nofollow noreferrer">http://woodstox.codehaus.org/</a>, "typed access API" under 'org.codehaus.stax2.typed.TypedXMLStreamReader').</li>
</ul>

So it kind of sounds like you just want to build something of your own. Nothing wrong with that, as a hobby, but if so you need to consider it as such.
It likely is not a requirement for the system you are building.

I want to come up with a binary format for passing data between application instances in a form of POFs (Plain Old Files ;)).

Prerequisites:

<ol>
<li>should be cross-platform</li>
<li>information to be persisted includes a single POJO &amp; arbitrary byte[]s (files actually, the POJO stores it's names in a String[])</li>
<li>only sequential access is required</li>
<li>should be a way to check data consistency</li>
<li>should be small and fast</li>
<li>should prevent an average user with archiver + notepad from modifying the data</li>
</ol>

Currently I'm using DeflaterOutputStream + OutputStreamWriter together with InflaterInputStream + InputStreamReader to save/restore objects serialized with XStream, one object per file. Readers/Writers use UTF8.
Now, need to extend this to support the previously described.
My idea of format:

<pre><code>{serialized to XML object}
{delimiter}
{String file name}{delimiter}{byte[] file data}
{delimiter}
{another String file name}{delimiter}{another byte[] file data}
...
{delimiter}
{delimiter}
{MD5 hash for the entire file}
</code></pre>

<ol>
<li>Does this look sane?</li>
<li>What would you use for a delimiter and how would you determine it?</li>
<li>The right way to calculate MD5 in this case?</li>
<li>What would you suggest to read on the subject?</li>
</ol>

TIA.

Developing a (file) exchange format for java

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我想提出一种二进制格式，以POF的形式在应用程序实例之间传递数据(Plain；)。前提条件：应该是跨平台要持久化的信息包括单个POJO &任意byte[](实际上，POJO将其名称存储在String[]中)只需要顺序访问。应该是检查数据一致性的一种方法。应该又小又快应该防止使用存档+记事本的普通用户修改数据。目前，我正...

问为java开发(文件)交换格式
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为java开发(文件)交换格式EN