System type: Window 10
ExifTool version: 12.74
Specific command line:
C:\Programs\exiftool\exiftool.exe "G:\Video\IMPORTANT꞉ 'Watch this first'.mp4"
Console output:
No matching files
The special character in question is a colon replacement, Modifier Letter Colon - U+A789 (꞉). I've also tested with the Fullwidth Question Mark - U+FF1F (？), Low Asterisk - U+204E (⁎), and Division Slash - U+2215 (∕). The next two gave the same response and the first. The last one gave the response:
Error: File not found - <file name>
I'm certain the files are present in the specified location.
PS C:\> dir g:\video
Directory: G:\Video
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 10/14/2022 10:35 AM 456636682 'A⁎C⁎E Procdures'.mp4
-a--- 8/26/2019 4:54 PM 106373907 'Strat∕End Shift Procedures'.mp4
-a--- 12/26/2023 3:51 PM 112858407 'What are your next steps？'.mp4
-a--- 1/23/2024 11:02 AM 12720953 IMPORTANT꞉ 'Watch this first'.mp4
See How to work around Windows' restricted characters (https://mythofechelon.co.uk/blog/2020/3/6/how-to-work-around-windows-restricted-characters) for the complete list
Special characters in Windows file names are problematic.
Reading point 1. in FAQ 10 (https://exiftool.org/faq.html#Q10) and the WINDOWS UNICODE FILE NAMES section of the application documenation (https://exiftool.org/exiftool_pod.html#WINDOWS-UNICODE-FILE-NAMES) may help.
- Phil
I'm not sure I understood the doco correctly. Given the command:
C:\Programs\exiftool\exiftool.exe -charset filename=UTF8 "G:\Video\IMPORTANT꞉ 'Watch this first'.mp4"
I'm still getting the output:
No matching files
The WINDOWS UNICODE FILE NAMES (https://exiftool.org/exiftool_pod.html#WINDOWS-UNICODE-FILE-NAMES) section does indicate it's better to use an argsfile. Fair enough. Creating a tags file for the file in question: IMPORTANT꞉ 'Watch this first'.args with the mp4 file (with special character) as the sole line. Issuing the updated command...
C:\Programs\exiftool\exiftool.exe -charset FileName=UTF8 -@ "G:\Video\IMPORTANT꞉ 'Watch this first'.args"
results in
Error opening arg file G:\Video\IMPORTANT? 'Watch this first'.args
So, not even the args file can have special characters. Not ideal as these are used extensively and my final goal is to update the tags on all these files. To try and work through this (for understanding purposes), I created: IMPORTANT.args with just the original file on a single line. The command
C:\Programs\exiftool\exiftool.exe -charset FileName=UTF8 -@ "G:\Video\IMPORTANT.args"
kicks out all the tags as expected. Am I missing something with the in the FAQ or is my understanding of -charset wrong?
The issue is getting a file name entered on the command line to ExifTool without it getting mangled. This is heavily dependent on your command shell settings. We don't even know what shell you are using (CMD or PowerShell?). And what character set are you using in your shell? Did you try setting it to UTF8 with chcp 65001 ?
- Phil
Related: FAQ #18 (https://exiftool.org/faq.html#Q18).
In my case, those options never did work, but this StackOverflow answer (https://stackoverflow.com/questions/57131654/using-utf-8-encoding-chcp-65001-in-command-prompt-windows-powershell-window/57134096#57134096) fixed the problem for me. Unfortunately, it also has the side effect of changing the fonts of some older programs and causing problems with their GUIs. . If you use that option, you'll have to test it and see if the problems are acceptable.
Thanks StarGeek. I was hoping you would chime in... I looked quickly for your StackOverflow reference but didn't find it. I've added it now to FAQ 19.
- Phil
As is typical, my attempt to relay the issue with as minimal fuss as possible (i.e., making the smallest test case) changed the conditions of the problem. FWIW, I was using Powershell 7 in my "testing", but the original issue was actually occurring in .NET 8 code written in C# (within LINQPad, if that matters). This code is using a wrapper which starts a new process for ExifTool. The in/out processing was already in UTF-8, but the arguments for the process needed the additional -charset filename=UTF8 to allow it to correctly handle these files. I'm still doing more testing in the original working environment.