在java http客户端中压缩非二进制数据
我计划在从 java 客户端发送到服务器（在本例中为 java servlet）时使用 java.util.zip 来压缩 http post 数据。 这是减少数据负载的最佳方法吗？
我应该使用 gzip 作为压缩算法吗？
I plan to use java.util.zip to compress http post data when sending it from a java client to the server(java servlet in this case).
is this the best approach for reducing data load?
should I use gzip as the compression alg?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
可能，使用简单的算法可以相当容易地压缩基于标签的数据。
对于每个唯一的标签或属性名称，分配 ID，用 ID 替换标签，将 ID 和标签名称存储在单独的文件中，然后压缩为 zip。
然后，只需将您的标签 ID 替换为从 zip 解压后在单独文件中获得的标签名称即可。
（您不必使用两个文件，您可以在同一个文件中执行此操作）
您还可以对标签或属性内的单个“单词”执行此方法。
这比仅仅压缩它需要更多的时间，但对于具有大量重复文本的中型到大型文件，它可以节省大量要传输的数据。
我不知道“http post data”中定义了什么，但如果它只是标签，类似的算法可能会起作用。
Possibly, Tag based data can be compressed fairly easily using a simple algorithm.
For every unique tag or attribute name, assign ID, replace tags with ID, store ID and tag name in separate file, then compress to zip.
Then simply replace your tag ID's with the tag names you get in the separate file after you decompress from zip.
(You don't HAVE to use two files, you can do it in the same file)
You can also do this method for individual 'Words' inside of the tags or attributes.
This takes a bit more time than just zipping it, but for medium to large files with a lot of repeated text, it saves a decent amount of data to be transfered.
I am not aware of what is defined in 'http post data', but if its just tags, a similar algorithm might work.
HTTP 的两个标准压缩内容编码值是 gzip 和 deflate。
我在使用 Java 服务器上的 deflate 时遇到了 IE 8 的问题，并切换到了 gzip。我没有时间进一步调查，但当时我的印象是：(a) 需要的不仅仅是 Java
DeflaterOutputStream的简单输出，例如一些额外的包装，或者 (b) ）需要设置一些选项以确保正确的互操作性。根据我的经验，gzip 对于文本内容的压缩效果非常好，并且我一直在使用
Content-Type: gzip和GZIPOutputStream在 IE、FF 和 Chrome 上没有任何问题年。Two standard compression Content-Encoding values for HTTP are gzip and deflate.
I had problems with IE 8 using deflate from a Java server and switched to gzip. I didn't have time to investigate further, but I had the impression at the time that either (a) more than the simple output of the Java
DeflaterOutputStreamwas required, like some extra wrappering, or (b) there were options that needed to be set in order to ensure correct interoperability.In my experience gzip compresses extremely well for text content and I have been working with
Content-Type: gzipand aGZIPOutputStreamwith no problems against IE, FF and Chrome for a number of years.