I just learned about a special Unicode character--U+202E: Right-to-Left Override--that forces programs to display text in reverse order. The link for more information is: howtogeek.com/127154/how-hac ... xtensions/.
The article describes how this character can be used to disguise malicious files so they appear benign. They give the example of a file with the name "Awesome Song uploaded by [U+202e]3pm.SCR" that actually displays as "Awesome Song uploaded by RCS.mp3" so that one thinks they are playing an MP3 file while there are actually invoking a script file.
Does Directory Opus (version 10) automatically ignore this character?
If not, is there a way that I can instruct Directory Opus to ignore this character? (Preferably showing the character but ignoring the reversal?)
There isn't currently an option to ignore it, although it is something we've been thinking about.
However, you can configure Opus to display the file extensions in a separate column (either in addition to or instead of displaying them in the main Name column that's up to you) which can be used to mitigate the issue.
I agree with Origami1212 that it would be useful to have an option for Opus to ignore special Unicode characters when displaying filenames in listers. Ideally, the list would be user-definable; alternatively, the list could black out all zero-width unicode characters. Another option - for maximum flexibility - would be to allow users to install a regular expression search/replace sequence that would be executed on all filenames displayed in the listers. I prefer this latter option for its power and flexibility, and because I think it fits the ultra-customizable spirit of Opus throughout the program.
Of course, when pressing F2 to rename a file, or when copying the filename to the clipboard, or when referencing the filename with a {} placemarker, the original name should still be used, with the zero-width characters included.
Well, to be truthful, I'm not sure offhand. But the Right-To-Left Override is not the only special character that can manipulate the order of the output. There's also a Right-to-Left-Mark (0x200F), and a Right-To-Left Embedding character (0x202B), and a Pop Directional Formatting char (0x202C), and all of these can potentially be used to trick the user to things in ways unexpected. As a general rule, zero-width characters are not there to display a glyph, but rather to manipulate the text from an external standpoint; hence, I suggested the idea to provide an option to block them all.