# Fool proof rename file from tag
**URL:** https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169
**Category:** Mac
**Created:** [June 29, 2024, 4:13pm UTC](https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169 "2024-06-29T16:13:46Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@npx](https://community.mp3tag.de/u/npx)
#### Post date: [June 29, 2024, 4:13pm UTC](https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169/1 "2024-06-29T16:13:46Z")
I am looking for an advanced solution to rename files based on tags. I know there are the $validate()/$replace() functions to clean file names from characters which may cause trouble with a file system. I do have artists in my collection with names including characters like + \* “ # $ & , ( ) - . % and so on. It's annoying, but these characters can sort-of be expected and it’s possible to handle with said functions.
But it gets complicated - for example the well-known artist Four Tet has a side project, check out this Discogs page (and also the naming of the albums):
[https://www.discogs.com/artist/6400214-ꉺლஇ-ꉺლ](https://www.discogs.com/artist/6400214-%EA%89%BA%E1%83%9A%E0%AE%87-%EA%89%BA%E1%83%9A)
VERY FUNNY, Four Tet. 🤬 😂 This is on a whole different level. I have noticed some inferior file systems (for example Exfat which I sometimes need to use) are unable to read/copy files with weird names so I want to have a kind of strict a-z + 0-9 + \_ file naming convention to not have my data broken.
It’s not just this artist by the way, some artists have characters such as “ē“, and they too create trouble for me.
As I understand it validate() only checks whichever characters I tell it to check. Does anyone have any smart tips on how I could do this for characters so weird that I can never anticipate them? It would be nice with a script that guarantees just basic, plain, file system friendly characters.
If this is not possible I would like to suggest it being implemented as a sort of safety feature in the Mp3tag base code.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 29, 2024, 4:18pm UTC](https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169/2 "2024-06-29T16:18:19Z")
> [@npx](#):
>
> As I understand it validate() only checks whichever characters I tell it to check
This is not true.
See the documentation:
> **[Scripting Functions – Mp3tag Documentation](https://docs.mp3tag.de/scripting/#string-functions)**
>
> Documentation on Mp3tag's scripting functions. Mp3tag is the universal Tag Editor.
`$validate(x,y)` returns the given file name/path x with all invalid characters `/?*"<>|:` replaced by the string y.
---
### Author:  [@npx](https://community.mp3tag.de/u/npx)
#### Post date: [June 29, 2024, 4:31pm UTC](https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169/3 "2024-06-29T16:31:26Z")
Thanks for the reply. So this means that characters such as (̸̢̛̼̞̭͋ͅ)̸͚̰͛̔̾̀̿͒͂v̴̢͚͚͎ȯ̶̞̮͖̑̈́)̸̳̥̰̜̥̺̐ͅ)̴͎̜͍̱̋̌͋̓̾̚ ̷̨ʅ͡͡͡͡͡͡͡͡͡͡͡(ʅ͡͡͡͡͡͡͡͡͡͡͡(Ɵʅ͡͡͡͡͡͡͡͡͡͡͡(̸̢̛̼̞̭͋ͅ)̸͚̰͛̔̾̀̿͒͂:̴͓̞̑̌̂̆̊͋̀:̸͎̟̯̂̓̌:̶̢͙͙͕̠̩͆(̷̮͍͚̫͚͂̍)̵̳̗̊(Ɵʅ͡͡͡͡͡͡͡͡͡͡͡(̸̢̛̼̞̭͋ͅ)̸͚̰͛̔̾̀̿͒͂v̴̢͚͚͎ȯ̶̞̮͖̑̈́)̸̳̥̰̜̥̺̐ͅ)̴͎̜͍̱̋̌͋̓̾̚ ̷̨ʅ͡͡͡͡͡͡͡͡͡͡͡ (from my example) are also included in the invalid characters?
I thought it was only the ones listed (/?\*"\<\>|:).
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 29, 2024, 4:43pm UTC](https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169/4 "2024-06-29T16:43:13Z")
It is not correct that $validate() only remove/replaces the characters that you tell it to treat.
As far as I can tell you get an error message if you use these characters.
THe only way around it, would be to replace these characters.
The string that you supplied starts with
```auto
U+0028 : LEFT PARENTHESIS
U+200B : ZERO WIDTH SPACE [ZWSP]
U+0338 : COMBINING LONG SOLIDUS OVERLAY {long slash overlay}
U+200B : ZERO WIDTH SPACE [ZWSP]
U+0322 : COMBINING RETROFLEX HOOK BELOW
U+200B : ZERO WIDTH SPACE [ZWSP]
U+031B : COMBINING HORN
U+200B : ZERO WIDTH SPACE [ZWSP]
U+033C : COMBINING SEAGULL BELOW
U+200B : ZERO WIDTH SPACE [ZWSP]
U+031E : COMBINING DOWN TACK BELOW
U+200B : ZERO WIDTH SPACE [ZWSP]
U+032D : COMBINING CIRCUMFLEX ACCENT BELOW
U+200B : ZERO WIDTH SPACE [ZWSP]
U+034B : COMBINING HOMOTHETIC ABOVE
U+200B : ZERO WIDTH SPACE [ZWSP]
U+0345 : COMBINING GREEK YPOGEGRAMMENI {iota subscript}
U+200B : ZERO WIDTH SPACE [ZWSP]
U+0029 : RIGHT PARENTHESIS
U+200B : ZERO WIDTH SPACE [ZWSP]
U+0338 : COMBINING LONG SOLIDUS OVERLAY {long slash overlay}
U+200B : ZERO WIDTH SPACE [ZWSP]
U+035A : COMBINING DOUBLE RING BELOW
U+200B : ZERO WIDTH SPACE [ZWSP]
U+0330 : COMBINING TILDE BELOW
U+200B : ZERO WIDTH SPACE [ZWSP]
U+035B : COMBINING ZIGZAG ABOVE
U+200B : ZERO WIDTH SPACE [ZWSP]
U+0314 : COMBINING REVERSED COMMA ABOVE {Greek dasia, rough breathing mark}
U+200B : ZERO WIDTH SPACE [ZWSP]
U+033E : COMBINING VERTICAL TILDE {yerik}
U+200B : ZERO WIDTH SPACE [ZWSP]
U+0300 : COMBINING GRAVE ACCENT {Greek varia}
U+200B : ZERO WIDTH SPACE [ZWSP]
U+033F : COMBINING DOUBLE OVERLINE
```
and I assume that the zero width space ZWSP character is the problem
If I remove these, then the string looks like this:
̸̢̛̼̞̭͋ͅ)̸͚̰͛̔̾̀̿͒͂v̴̢͚͚͎ȯ̶̞̮͖̑̈́)̸̳̥̰̜̥̺̐ͅ)̴͎̜͍̱̋̌͋̓̾̚ ̷̨ʅ͡͡͡͡͡͡͡͡͡͡͡(ʅ͡͡͡͡͡͡͡͡͡͡͡(Ɵʅ͡͡͡͡͡͡͡͡͡͡͡(̸̢̛̼̞̭͋ͅ)̸͚̰͛̔̾̀̿͒͂:̴͓̞̑̌̂̆̊͋̀:̸͎̟̯̂̓̌:̶̢͙͙͕̠̩͆(̷̮͍͚̫͚͂̍)̵̳̗̊(Ɵʅ͡͡͡͡͡͡͡͡͡͡͡(̸̢̛̼̞̭͋ͅ)̸͚̰͛̔̾̀̿͒͂v̴̢͚͚͎ȯ̶̞̮͖̑̈́)̸̳̥̰̜̥̺̐ͅ)̴͎̜͍̱̋̌͋̓̾̚ ̷̨ʅ͡͡͡͡͡͡͡͡͡͡͡
and that can be used as a filename.
Edit: I just checked $validate() in the Windows environment and that creates a valid filename.
---
### Author:  [@npx](https://community.mp3tag.de/u/npx)
#### Post date: [June 29, 2024, 4:50pm UTC](https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169/5 "2024-06-29T16:50:04Z")
Thanks again, now I understand what you meant in your first comment and of course you are right. I formulated my question weirdly.
Thank you for taking the time to research these characters as well.
You are right I need to avoid these characters in my use case. While for example APFS or Ext4 can handle them, Exfat can't.
I just thought maybe there is SOME way to have a script reject any set of characters that are not truly fool-proof to not have to manually correct things. I understand that Mp3tag itself is file system agnostic. It would just be neat with some type of basic protection. But all this is way over my character encoding knowledge.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 29, 2024, 4:54pm UTC](https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169/6 "2024-06-29T16:54:13Z")
> [@npx](#):
>
> It would just be neat with some type of basic protection
The basic protection is more or less there as you get an error message that WIndows does not accept such a filename. I agree that it would be nicer to have a function that removes such characters automatically.
---
### Author:  [@npx](https://community.mp3tag.de/u/npx)
#### Post date: [June 29, 2024, 5:02pm UTC](https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169/7 "2024-06-29T17:02:01Z")
I failed to mention I use the Mac version. MacOS does not warn about it. Hence my frustration, I get problems in a later stage when I copy to an Exfat drive.
I guess the idea of some sort of fix is still relevant for the Windows version though.
(I moved it to the Mac section.)
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 29, 2024, 5:03pm UTC](https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169/8 "2024-06-29T17:03:59Z")
> [@npx](#):
>
> MacOS does not warn about it.
If you would change the files directly on the
> [@npx](#):
>
> Exfat drive
I am pretty sure that you would also get an error message.
---
### Author:  [@npx](https://community.mp3tag.de/u/npx)
#### Post date: [June 29, 2024, 5:05pm UTC](https://community.mp3tag.de/t/fool-proof-rename-file-from-tag/65169/9 "2024-06-29T17:05:16Z")
This is true, but I would never use Exfat for other purposes than as a bridge between different OS:es, it is a terribly flawed file system otherwise. Slow, unstable, no journaling, etc.