Talk:List of filename extensions

Talk:List of file formats (alphabetical); Keep this!

Why name it Windows * ? The file name extensions are for all OS, we hope. Good to have a complete set arranged alphabetically. In fact, I would like to see additions to this set, with links to the associations and companies that do most with the extensions. --Steve Irick. —Preceding unsigned comment added by 75.48.78.4 (talk) 00:53, 28 February 2009 (UTC)

.mpa

.mpa also seems to be an extension used by the Palm Desktop application. Is there any concensus reason that use should not also be listed here? -Onceler (talk) 22:16, 3 July 2009 (UTC)

Proposal of massive merge

Talk:Windows file types for details. —Nethac DIU ([[User talk:Nethac DIU|¿?), wuz heer about 01:03, 19 March 2010 (UTC)

Merge/Deletion discussion

This is a useful page - I have a bookmark directly to it - so why on Earth is it marked for deletion? Paul Taylor (talk) 19:15, 7 February 2009 (UTC)

It is useful and should not be merged with Windows file types. I just added an extension pertaining only to Linux. Redrabbit2 (talk) 22:39, 11 August 2009 (UTC)

No, but maybe the other way around. List of file formats (alphabetical) has the clear purpose given in the name. Windows file types is a small subset and I'm not quite sure what its purpose is, does not Windows recognize more file types? List of file formats (alphabetical) does have the disadvantage of being very long. Maybe it should be broken down into one article per letter or group of letters as the similar article in the German wikipedia. http://de.wikipedia.org/wiki/Liste_der_Dateinamenserweiterungen --Theosch (talk) 04:07, 26 August 2009 (UTC)

Rad50

Any discussion of the file suffix, or extension, should include reference to Digital Eqpts, Rad50 notation, which is why the great body of extensions are limited to three characters. Rad50, or more properly RAD50 was an encoding scheme to put 3 characters into 16 bits. 26 letters, 10 digits, and sufficient other characters, excluding i believe the period (.), slash (/) and bs (\\), since they are part of the filename delimiters, and hence could NOT be part of the suffix are the 50 potential suffix characters (if not part of the name). So 50^3rd/ 2 (somehow) = 62500, which fits in a 16 bit binary.

Windows is merely a "johnny-come-lately" adopter of this scheme as well. Applemcg (talk) 01:31, 27 August 2009 (UTC)User:applemcg

I agree that RADIX-50₈ should be mentioned in the filename extension article. The popularity of that encoding on early computers is almost certainly the reason that extensions were limited to no more than three characters from a small character set "for compatibility" for many decades. And so I agree that RADIX-50 should be mentioned in the file extension article. --DavidCary (talk) 21:38, 20 June 2015 (UTC)

Removal of the warnings

This discussion has been lingering for more than a year, therefore I have just stripped the "please merge with the windows article" warning.

BTW, while every article should be properly sourced, I found the warning against the lack of source slightly inappropriate because of the copyvio justification: copyright does not cover lists of facts nor small excerpts a few words long. Since the article has some sources anyway, I removed the "please cite properly" alertbox as well. Regards, Comte0 (talk) 13:22, 11 April 2010 (UTC)

Fair enough BUT the deletion discussion linked above specifically states that the merge should take place, this is effectively a condition of the article being kept and so the merge warning should remain. Polyamorph (talk) 14:56, 12 April 2010 (UTC)

Merging with list of file formats, perhaps; with Windows file types, certainly not... Comte0 (talk) 12:23, 18 April 2010 (UTC)

Yes, ok my mistake. Polyamorph (talk) 12:29, 18 April 2010 (UTC)

Archives

Where on wikipedia are the archives to this talk page going? I cannot see an index and there are no links to the archived pages despite what the icon says. Cluebot seems to be archiving this page faily regularly but is not providing any links to see the archived threads. Polyamorph (talk) 17:47, 12 April 2010 (UTC)

I added an archive box that actually links to the archived pages and disabled cluebot from archiving this page. In the future bot archives (using a more reliable archive bot such as MiszaBot) should only be done after sufficient consensus and testing. I personally can't see a need for bot archiving on this page as talk threads are relatively infrequent. Polyamorph (talk) 18:03, 12 April 2010 (UTC)

Only the first archive was relevant, I have reintegrated the other very small one on this talk page. Comte0 (talk) 13:09, 18 April 2010 (UTC)

Then the pages need to be deleted. I have reinstated the links. They are vital for users to see the full history of threads on this page. If we want to delete the archive pages and merge into a more suitable one then we can do this but will need an admin to delete the surplus subpages created by cluebot. Cheers, Polyamorph (talk) 13:13, 18 April 2010 (UTC)

I will put the subpages up for speedy and reinstate your merge of content into this page which I didn't mean to undo. Cheers, Polyamorph (talk) 13:17, 18 April 2010 (UTC)

Well, english is not my mother tongue, and I was too late in writing a proper answer to explain I was intending to follow WP:PROD. Sorry about that :) Comte0 (talk) 13:22, 18 April 2010 (UTC)

No its fine, it was my mistake for not realising you'd merged the archive content back in here! Sorry! I'm adding {{speedy}} to the subpages, hopefully an admin will accept that, if not we'll have to try {{prod}}. At the end of the day these archives should never have been created and we both agree on that so all is fine. Cheers :) —Preceding unsigned comment added by Jdrewitt (talk • contribs) 13:29, 18 April 2010

Done. Snowolf ^{How can I help?} 15:07, 18 April 2010 (UTC)

Case sensitivity

Most file types are shown upper case. I think because it started with Windows and looks neat. However, on platforms with case senstitive file systems like unix it makes a difference, whether an extension is uppercase or lowercase. In fact, most extensions are lowercase on such systems.

We could ignore this, but e.g compiling a .c file would invoke the C compiler while .C would invoke the C++ compiler. I think the names should be converted to lower case where it is known to be safe. Marcel Müller (talk) 08:16, 6 June 2010 (UTC)

Under unix, you do not double click on a file and expect the proper program to be magically invoked, you invoke the program passing the file as an argument. For instance, to compile a C file, you invoke the compiler like this: cc file.c, or cc file.C: the file can be named any way you want and the extension is not important. The split program indeed produces lower case extension, but I do not feel it's that important either. Regards, Comte0 (talk) 12:48, 6 June 2010 (UTC)

Hum. Looking it up further, the difference between .c and .C is a special case, at least for gcc, and probably for other c compilers, it should be noted in the article. Comte0 (talk) 13:06, 6 June 2010 (UTC)

To respond belatedly, there are multiple reasons that they should definitely be (and remain) lower-case by default. Mainly, per MOS:CAPS: do not capitalize anything unless it is almost always capitalized in reliable sources. Here, the OP's reason is also additionally compelling. There are proportionally very few instances where the case makes a difference, but when it does, we have occasional instances of mandatorily capitalized extensions in *n*x, in a vast sea of normally lower-cased extensions, so we clearly need to use LC for most of them, and UC only for the rare ones that require it.  — SMcCandlish ☏ ¢ 😼  07:24, 30 August 2020 (UTC)

does anyone have any objections to moving forward with changing the capitalization to lowercase? Binarycat64 (talk) 00:02, 1 February 2022 (UTC)

Size split?

Split - Article is over 100 kB and should be split. Thoughts? Suggestions?--Jax 0677 (talk) 02:28, 16 December 2012 (UTC)

I think that this is one that should have had a letter per page, we can safely assume that the article will expand in the future. Best to do it properly now than have to keep on tinkering. Op47 (talk) 20:50, 8 February 2013 (UTC)

Duplication

Please see post on possible duplication at Talk:List_of_file_formats#Duplication Rui ''Gabriel'' Correia (talk) 00:19, 10 January 2014 (UTC)

Unix-related problems

There are at least two problems related to Unix file types.

1. Unix file names are case sensitive. BLAH.TXT and blah.txt are two separate files, for example. This especially applies to the fact that a .Z file and a .z file are not the same thing, even in terms of the formats and the commands to make them.

2. Unix commands are also case sensitive. As of the creation of this section, the file listing for the above file types, which mistakenly lists .z and .Z as interchangeable, mentions non-existent PACK and COMPRESS commands, using the format that DOS commands use. The program for making .Z files is always referred to as compress, using the all-lowercase format of every other Unix command.

I will probably eventually correct at least some of these pages (especially since ALL CAPS has become equivalent to yelling after the Internet became widespread). --Evice (talk) 14:13, 26 October 2014 (UTC)

Bogus lists

The lists appear to be bogus, a random unsourced collection of wannabe file-extensions. How about limiting the lists to existing pages including redirects? E.g., the two entries for JOB don't match my (Windows) idea of an ancient at command .job. –Be..anyone (talk) 22:53, 11 April 2016 (UTC)

Cleanup and Criteria

This list has no inclusion criteria and has precious few references. I propose we establish inclusion criteria here. A file extension will be included in this list only if:

1. More than one notable application or service supports the file format as described.
   1. A notable application or service has an article here on Wikipedia itself
2. The support or definition of that file format is externally documented, and a usable reference is included to that documentation.

Can we build consensus around these criteria and clean up the list? -- Mikeblas (talk) 15:49, 28 August 2020 (UTC)

I strongly support the criteria. Cleanup is really desperately needed. The list is a complete mess, with a huge number of obscure extensions that are unsourced and nobody knows whether they even exist. This is unacceptable. This was a concern in the deletion discussion as well. The article was kept, but "on the condition that all of them need sources attached to them after", noting that "the page(s) are badly in need of clear inclusion criteria".—J. M. (talk) 16:02, 28 August 2020 (UTC)

Thanks, JM. That AfD is why I'm here! -- Mikeblas (talk) 17:00, 28 August 2020 (UTC)

This sounds like a good plan. All lists of this sort need inclusion criteria or they attract spam, nonsense, trivia, and other cruft.  — SMcCandlish ☏ ¢ 😼  07:20, 30 August 2020 (UTC)

@J. M.: and @SMcCandlish:: Since we've got agreement about the criteria, we should codify it in the article headers. How does this text sound?

This is a list of notable file extensions. File extensions listed here are used by multiple notable applications or services, and represent documented file formats.

-- Mikeblas (talk) 21:06, 12 September 2020 (UTC)

Looks good to me. But the 3DS example is indeed interesting. Does your definition include reverse-engineered formats, too? I think there could be many well-known formats with unofficial, reverse-engineered specifications.—J. M. (talk) 21:39, 12 September 2020 (UTC)

Yeah -- there are a lot of judgement calls. For now, I'm trying to chop extensions which are un-referenced and not notable -- straight out. Non-notable is also readily identifiable; but then that leaves us with "maybe notable" and/or "maybe referenced". I'm leaving those for a subsequent pass. After a pass this way, the lists will have far less clutter and therefore be a bit easier to reason about. For reverse-engineering, I think if the reversed specification is published, then it's good -- someone is writing about it, obviously independently of the primary source, and that's toward notability, right?

I've been injecting references for formats that I can find, and leaving those that I'm pretty sure I can find. It can always be fixed, but the pruning is already quite noticeable. Please do feel free to jump in if you have time, or give feedback or ... ! -- Mikeblas (talk) 03:01, 13 September 2020 (UTC)

Something like this. It's not that the extension itself needs to be notable, but at least one of the applications that use the format should be, if the format is not. Various heavily used applications (Word, Illustrator, etc.) use multiple formats, and readers are apt to try to figure out what they are, but most are not formats that will themselves have articles.  — SMcCandlish ☏ ¢ 😼  14:35, 15 September 2020 (UTC)

Cleanup

I have started the cleanup work. .3ds is already an interesting problem; seems like this file format has been reverse engineered a bit, but I'm not comfortable using those documents as references. Are official documents available? Searching around autodesk.com didn't get me anything. -- Mikeblas (talk) 18:28, 12 September 2020 (UTC)

As above, I guess I'm actually leaning toward the reverse-engineering work being an independent source that goes to notability. Is there precedent for this pattern? -- Mikeblas (talk) 03:03, 13 September 2020 (UTC)

It would probably qualify as independent sourcing, as long as there's non-trivial coverage in some source other than that of the reverse-engineer's self-publication. E.g., the .ESP/.ESM format used by Gamebryo Engine games (mostly from Bethesda/Zenimax) was only partially documented, but has long been figured out in great detail by the coding teams behind tools like xEdit, and the format facts have since been verified and repeated by others like UESP (which has an editorial board who carefully review content; it is not an open public wiki), by the Wrye Bash project, by the STEP project, etc., etc. But if I personally published a claim to have reverse-engineered some new format, that's just self-published (WP:SPS) material if you only find it on my personal website or Discord feed.  — SMcCandlish ☏ ¢ 😼  15:49, 15 September 2020 (UTC)

Cleanup Progress

More than half-way done, I think. I've left some unreferenced entries that seem like they might be viable, but I haven't researched yet. Lots of references added, and masses deleted. Any feedback or comments, concerns? -- Mikeblas (talk) 15:47, 25 September 2020 (UTC)

OK, I'm putting a button on this effort and calling it done. I've deleted lots of unreferenced, non-notable entries and added dozens of references. I've left behind things that are apparently notable, but they still really do need real references. I'll update the headers for each of the pages presently. -- Mikeblas (talk) 14:19, 5 November 2020 (UTC)

Make TOC into a template?

Currently, the table of contents seems to have been copy-pasted across each of the different sup-pages, often with notable differences.

Would it be a good idea to make a template just for this list? I'm not super familiar with the standards for making new templates, but also the current state is a bit of a mess. Binarycat64 (talk) 00:07, 1 February 2022 (UTC)

I think that would be helpful! -- Mikeblas (talk) 14:56, 8 September 2022 (UTC)

I've made the ToC itself a template, but not the "see also" links. -- Mikeblas (talk) 18:32, 8 September 2022 (UTC)

add nsp and nsz

please, thanks 2804:388:4110:6441:1:0:B76F:4D1E (talk) 10:35, 11 November 2024 (UTC)