> Guess I was wrong with some of the above: > All of them, whose _decompressed_ data is more than just any raw data > (i.e. all archives which can have multiple files, or so) > can have their own (un)official mime type. >
If an application stores information about the original file (like it's filename) rather than just act without thought on a data stream, then it's more than just an encoding. > Especially > application/x-gtar-compressed tgz taz > however not (don't know about the others). > tgz and taz should be added to application/x-tar (in addition to .tar), as > they're both tar archives just with an gzip/compress Content-Encoding. > Correct, but not so simple. Expecting a program/person to recognize .gz and meaning gzipped is more reasonable than expecting it/them to reliably recognize that some (but not all) extensions ending with a "z" are also such. After that, we're left with the fact that tar will not process a tgz or taz file without an added option on the command line. Thus, it must map to a different type to get opened in a different way. I gather newer version of tar can recognize some file extensions but I don't know to what degree and apparently not by analyzing the data stream itself (which is important should the data be coming from stdin). There's also something to be said for backwards compatibility. > You already do this nicely with svgz, which is just an gzipped svg and > which you map to the svg mime type. > Presumably because the application can natively handle both formats. That mapping was asked for by someone else. Brian [email protected] ----------------------------------------------------------------------------------------- Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
