Talk:Gzip

message: AdvanceCOMP and 7-zip use a DEFLATE implementation which produces gzip-compatible files with better compression ratios than gzip itself, at the cost of more processor time.
I removed this because 7-zip does not produce gzip-compatible files. Even using the deflate method, 7-zip files cannot be decompressed with gzip. If you contend otherwise, please post the required commands to compress a file with 7-zip and then decompress it with gzip.
I used: '7za a test.7z test.bin' then 'mv test.7z test.gz' then 'gunzip test.gz' and gunzip reported: "gunzip: test.gz: not in gzip format". '7za l -slt test.7z' reports "Method = Deflate".
I don't know anything about AdvanceCOMP. If you can verify that an AdvanceCOMP-compressed file can be decompressed using gzip, feel free to re-add the part about that program, but please clarify whether *all* or just *some* AdvanceCOMP archives are gzip-compatible, if so. Ramorum (talk) 07:37, 17 February 2008 (UTC)
replies: text: Hello Ramorum, did you try using the -t switch?  This should select the container format;  eg. -t7z, -tzip, -tgz (the last should produce gzip encapsulated DEFLATE) using the internal DEFLATE implementation.  —Sladen (talk) 15:39, 17 February 2008 (UTC)
thread_title: AdvanceCOMP/7-zip

message: There's an excellent concise discussion of the specific techniques used in gzip in the book Managing Gigabytes, section 2.6, pp.78–79. It even includes some important implementation details not in the RFC. I'll add some info from there once I've dealt with the more fundamental Ziv-Lempel articles. Dcoetzee 19:37, 9 May 2008 (UTC)
thread_title: Good source

message: perhaps some discussion of the rsyncable option, which occasionally resets the compressor so that an early change can still leave later sections identical after compression (for smaller deltas), might be worthwhile. I don't know enough to do it myself.  —Preceding unsigned comment added by 216.106.175.189 (talk) 19:04, 3 June 2008 (UTC)
thread_title:  --rsyncable option 

message: Why are there so many links on RFC 1950, RFC 1951 and so on? Wouldn't one of each be enough? They are somewhat confusing, especially in the "other uses" section.Gerdschoenle (talk) 10:30, 2 August 2010 (UTC)
replies: text: These links are generated by MediaWiki. If you dislike some particular link, be bold and rewrite its wikitext as “RFC 1950” and so on. Incnis Mrsi (talk) 18:17, 2 August 2010 (UTC)
thread_title:  Many links are confusing 

message: As I did some research on HTTP Compression, I came over this and the other articles (zlib, DEFLATE,...). They offer redundant information and everything is centered on on their historical close relation and these 3 RFCs (1950,1951,1952). I would propose a restructuring with at least the following entities (as pages or headings)
* deflate: 
** as a compression algorithm and stream format (RFC 1951) 
** the historical development of deflate, pkzip, zip, gzip, zlib
** a reference to the role of deflate in the data formats zip, gzip, zlib, png, ...
** a reference to the role of deflate in HTTP Compression
* gzip: 
** as an application 
** as a compressed container file/stream format (RFC 1952) that uses deflate by default
** a reference to the role of gzip in HTTP Compression
** a reference to the historical development (described in deflate)
* zlib: 
** as a library 
** as a compression file/stream format (RFC 1950) that uses deflate by default
** a reference to the role of zlib in HTTP Compression
** a reference to the historical development (described in deflate)
* HTTP Compression
--Voeren (talk) 08:58, 24 March 2011 (UTC)
thread_title:  Confusing structure 

message: AdvanceCOMP and 7-Zip can produce gzip-compatible files, using an internal DEFLATE implementation with better compression ratios than gzip itself—at the cost of more processor time compared to the reference implementation . Citation in not needed, because everyone can see that
 7z -si -so -tgzip -mx=9 < file > file.gz
produces smaller files than 
 gzip --best < file > file.gz
46.112.87.125 (talk) 23:42, 11 April 2011 (UTC)
thread_title:  Citation needed? 

message: This article is so full of technical speak and details that it is incomprehensible to the average reader.  This article is likely to be understood only by those who already know all the information it contains.
The "Other uses" section is confusing - I missed the part where the primary uses were discussed.
I came here trying to understand gzip's use in HTTP compression, seeking to learn which servers and browsers support it, and how it is enabled.  After re-reading the article several times, I finally found a brief couple of highly-technical sentences where I almost found the information I was looking for.
This article needs to be re-written to be understandable by a wider audience.  Perhaps all that is needed is to state the (seemingly) obvious.
-- Gilly3 (talk) 20:37, 29 December 2011 (UTC)
thread_title:  Confusing and unhelpful article 

message: When I first came across tbz in this article, I thought it was a typo and replaced it with tbz2. That change was reverted. I should have paid attention to the fact that some people seem to use tbz for bzip2-compressed tar archives (in spite of the fact that it looks more like tar + bzip than tar + bzip2, but this is beside the point). Sorry for that. However, I believe tbz2 must be mentioned: ".tbz2" generates next to 2 million hits on Google (the first ones, at least, being about tar and bzip2) and is mentioned in the bzip2 manual page.
-- FC 21 January 2012  — Preceding unsigned comment added by 82.66.64.12 (talk) 22:30, 21 January 2012 (UTC)
thread_title:  About the .tbz2 extension 

message: I came here to see what the file format for a typical (minimalistic) gzip file was. And all I got was that there's a 10 byte header + optional extra headers + 8 byte footer. Without specifying what these are! Very disappointing! Jahibadkaret (talk) 15:26, 17 March 2012 (UTC)
replies: text: I doubt it would add much to the article; anyone who needs this much detail is probably better served by the format specification (page 5), which is clearly linked in the reference section. — DataWraith (talk) 21:23, 17 March 2012 (UTC)
thread_title:  Incomplete File Format 

message: I've heard it said that zlib is the most popular software in the world (Richard Hipp suggests it's more popular than SQLite at the 29:15 mark of his interview on episode 201 of the changelog on https://changelog.com/201/ ). Does anyone have anything that could back this up?
80.194.75.37 (talk) 07:29, 12 June 2016 (UTC)
thread_title:  Most used software in the world? 

message: I don't know the story behind gzip.org, but it was last updated 2003-07-27, more than 14 years ago. The newest version listed there is 1.2.4 from 1993, and none of the source download links works, the server doesn't exist anymore. After searching for alternative implementations, it seems as the GNU version at  is the canonical version. I suggest that the second infobox is merged into the primary infobox, and only the gnu.org URL is used there. There's still a link to the original gzip page at gzip.org in External Links, so nothing of value is lost. -- Sunny256|✎ 14:53, 16 September 2017 (UTC)
thread_title:  Mark gzip.org as obsolete? 

message: Hello fellow Wikipedians,
I have just modified one external link on Gzip. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20141101212919/http://compressionratings.com/comp.cgi?7-zip+9.12b++bzip2+1.0.5++gzip+1.3.3+-5 to http://compressionratings.com/comp.cgi?7-zip+9.12b++bzip2+1.0.5++gzip+1.3.3+-5
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 21:07, 26 October 2017 (UTC)
thread_title:  External links modified