summaryrefslogtreecommitdiffstatshomepage
path: root/content/22
diff options
context:
space:
mode:
authorWolfgang Müller2024-09-28 18:25:58 +0200
committerWolfgang Müller2024-09-28 18:25:58 +0200
commit5d157de0a6330566cf8a86ed28b65867ad61a329 (patch)
treef83719ada40cb0aae8c8c10490a5a2db750a064d /content/22
parentef19c6f5a58bc878f95c405b5d185afb8aa2c577 (diff)
downloadzunzuncito-5d157de0a6330566cf8a86ed28b65867ad61a329.tar.gz
content: Add post: "MIME type subclassing and its consequences"
Diffstat (limited to 'content/22')
-rw-r--r--content/22/index.md52
1 files changed, 52 insertions, 0 deletions
diff --git a/content/22/index.md b/content/22/index.md
new file mode 100644
index 0000000..c3ece23
--- /dev/null
+++ b/content/22/index.md
@@ -0,0 +1,52 @@
++++
+date = 2024-09-28T18:23:12+02:00
+title = "MIME type subclassing and its consequences"
+
+[taxonomies]
+tags = ["TIL"]
+
+[extra]
+related = []
++++
+
+The freedesktop.org [shared MIME-info database
+spec](https://specifications.freedesktop.org/shared-mime-info-spec/latest) says
+the following in [section
+2.11](https://specifications.freedesktop.org/shared-mime-info-spec/latest/ar01s02.html#subclassing):
+
+> A type is a subclass of another type if any instance of the first type is
+> also an instance of the second. For example, all `image/svg+xml` files are
+> also `application/xml`, `text/plain` and `application/octet-stream` files.
+> Subclassing is about the format, rather than the category of the data (for
+> example, there is no 'generic spreadsheet' class that all spreadsheets
+> inherit from).
+>
+> Some subclass rules are implicit:
+> - All `text/*` types are subclasses of `text/plain`.
+> - All streamable types (ie, everything except the `inode/*` types) are subclasses of application/octet-stream.
+
+So far so good; this makes intuitive sense and seems sensible enough. There is
+an interesting consequence of this rule when the MIME-info database is used by
+desktop systems for file associations, however: **An application associated with
+`application/octet-stream` will automatically be associated with all streamable
+types as well.**
+
+This means that if you associate `application/octet-stream` with your text
+editor, your desktop system will also suggest you open video and audio files
+with that same text editor. This behaviour can be quite surprising, especially
+if the association was added automatically when a file was opened through the
+"Open with..." dialog.
+
+What is even more confusing if you don't happen to know the subclassing rule is
+the fact that `~/.config/mimeapps.list` and applications interfacing with this
+file will not even list the editor as associated with any audio or video files.
+You might just skip over the entry it has for `application/octet-stream`, not
+realizing its significance. Perhaps you even assume (understandably) that
+`application/octet-stream` only specifies any file of "unknown" type.
+User-facing documentation on desktop systems (if it even exists) does not
+discuss this behaviour.
+
+Whilst looking into this I found an older KDE bug report with some [interesting
+thoughts](https://bugs.kde.org/show_bug.cgi?id=425154#c2) on how to explain this
+behaviour to the end user, but sadly as far as I have seen none of these have
+made it into the system setting's file association dialog.