Support any character in filenames using encoding

Some characters aren’t supported in file names (e.g. “:”), hence in note titles. The proposal is to support them by using percent encoding.

Use case or problem

I’d really like to use characters such as “:” in note titles but I can’t.

Proposed solution

Support any character in file names by using percent encoding for commonly unsupported characters (“:”, “/”, "", “?”, “%”…).

  • Platform specific character constraints on filename wouldn’t leak as constraints on note titles
  • It would be transparent to users as they would only see decoded titles in the UI.
  • Even if users look at actual file names, percent encoding is used for URLs so it should be familiar to them.

We could have several options:

  1. enable/disable: if disabled, platform constraints on filenames apply
  2. encode spaces: percent encode spaces (e.g. space becomes %20) even if they are supported in filenames. Not having spaces is useful for scripting.
  3. encode non ascii: encode every non ascii character. Best compatibility across systems

Current workaround (optional)

Currently I’m using aliases for real note names. So I have:

  • actual filename: short version of the title without the special chars
  • alias: the real title of the note
  • h1: the real title once again

Now that we have the “inline title” feature, I’d like to have a single source of truth for the title and to remove the alias and h1 (less extra work, good!). The most convenient way would be to still use file names by allowing all characters into them.

Note that it isn’t at odd with this other top proposal:

We could still support a “title” metadata to override using the filename as note title source, e.g. for users using ids as file names.

Related feature requests (optional)

9 Likes

Another bold idea is to only use percent encoding for filenames and to make filenames completely invisible in the Obsidian UI. Apps like Notion adopt similar ideas so there is no restriction on file titles.

1 Like

Changing a note name by pasting from clipboard; there is a “:” in the clipboard. Current behavior is to flash a red warning and then revert to earlier note name; would prefer if there were an option to similar delete any forbidden characters (perhaps with a warning) and use what remains.

7 Likes

I name notes the name of the text which may have special characters in. I don’t care to preserve them, so I replace them with a dash manually. Would be nice if this was done automatically with a little toast/flash message that notifies the user that the file name is invalid.

12 Likes

I’d like to slightly modify this: there should be an option to replace a forbidden character with another. For example, replace any forbidden character in a title with “-”.

2 Likes

I’ve been using Obsidian to take notes for a research topic and I’ve been putting the article title as the title/filename of my notes. Many articles have unacceptable characters in them ( : ) is a common one.

If I hit return, the title/filename reverts to untitled. It makes it difficult to edit. (Repaste, then try to edit it, or paste somewhere else, edit, recopy, repaste…) I’m wishing there was an option to auto remove or replace invalid characters.

(Ultimately, I’m not concerned if those characters are there in the title/filename or not, but needing to edit/fix the filename each time is a little annoying.)

10 Likes

Somewhat related:

2 Likes

I like this request. I think Obsidian should replace illegal characters in the title with a space or maybe a user-defined character.

3 Likes

I particularly like to use ‘:’ in my titles so would +1 in support of this

Would be better if the special characters could be in preserved somehow. Mark them automatically in the filename, but then read them in so the special character is in the tag. Would make it much easier to e.g. use a scientific papers title as a a tag, and ensure that you find it again in the future.

2 Likes

I would follow the web standard. %## for whatever is the illegal character. Make it an auto-swap.

4 Likes

Adding my +1 for this. I’m in the process of importing a lot of PDFs into my vault and looking to copy the titles into the filename, but I’m having to manually change “:” to “-” and it’s quite tedious.

I’d vote for a user-defined character as replacement (with the option of leaving it empty so Obsidian would simply leave out illegal characters).

Reason being: I run into this most often with colons (“:”). On Linux, this is a perfectly legal character in file names, albeit not in MacOS and Windows. So, many years ago, I got into the habit of using an underscore instead, to symbolize “here is something”. (For multibyte systems like UTF-8: on a character basis, not based on bytes.)

I think this would be helpful in situations where a user inadvertently or even intentionally starts or worse yet edits a note name to begin with a period.

The current behavior is to allow this naming to be committed, but then immediately the file is unrecognizable by Obsidian. This could go unnoticed and the file could be lost within a vault while not actually being lost.

The worst part is that, assuming they did not notice the disappearance upon committing the name and they have update internal links enabled, there will be no links left within the vault for the user to realize it went missing.

As I type this, I am beginning to believe this warrants a bug report, even though Obsidian is simply following instructions.

Thanks.

1 Like

The alternative is to webify the name so “That #$#@ fox” becomes “That%20…%20fox.md” (middle details omitted)

2 Likes

Agree. I accidentally included a period character at the start of a note name, which appeared to commit but was wiped from my Vault (and it would seem my computer). I accept that this was user error/stupidity but I paid a high price and lost a lot of information for that one careless act.

Sorry to hear that! The good news is that I strongly believe that the file should still be in the vault folder, but Obsidian just no longer sees it. If you can’t find it using Windows Explorer, maybe report back here. It really should still be there. I would recommend also looking at the File Recovery plugin as a backup plan, but you shouldn’t need it in this case. Good luck! Keep us posted!

Considering a file is created by double clicking on a link to its filename, [[filename]], and with reference to replacing forbidden symbols such as space or capital letters in the filename with user specified characters such as underscore or lower case respectively, there is no plugin yet to do this automatically, right?

Thanks

Why does the title on the interface have to match the file name? Can’t we just let people write whatever they want then parse it and write a compatible filename?

It doesn’t have to match. It’s a design decision to follow the filesystem for future proofness of your notes.