emojis, DOS 8.3 filename

Started by Waexto, March 29, 2019, 10:46:20 PM

Previous topic - Next topic

Phil Harvey

I spent 30 minutes trying, but failed to generate a folder name containing an emoji in my VirtualBox Windows 10 running on Mac.  The only technique I found was to press WIN-; or WIN-., but this didn't work in the virtual environment with a Mac keyboard (the right command key is supposed to be the WIN key, but it failed to bring up the emoji panel).

So it will be difficult for me to test this.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

obetz

Quote from: Phil Harvey on August 13, 2019, 07:58:53 AM
I spent 30 minutes trying, but failed to generate a folder name containing an emoji in my VirtualBox Windows 10 running on Mac.  The only technique I found was to press WIN-; or WIN-.,

I usually copy/paste such characters from other sources like https://unicode.org/charts/ or https://en.wikipedia.org/wiki/Unicode_block

You can also create the files on a different system and copy them to the VM.

You can try to extract the attached ZIP file in the VM

Oliver

Phil Harvey

Thanks Oliver.  I had tried that, but the emoji character didn't survive through the zip process using the available "zip" command on the Mac.

I put your folder inside a folder called "emoji" and ran this command:

exiftool -artist=me -r emoji

Everything works as expected.  The file is added and the name retains the emoji.  An "_original" file is created with the emoji in the name.

It also works with -overwrite_original added.  But it gives this error when I use -overwrite_original_in_place:


Error opening /home/phil/Desktop/emoji/Emoji_SMP_XXX_folder/Emoji_SMP_XXX_file.jpg

(where XXX are box-looking characters in the command window)

So, basically I get exactly the opposite of what Herb observed.  This is normal for Windows, really, and probably has to do with some system settings somewhere.  This makes it really hard to troubleshoot/fix because it looks like the results are different on different systems.  :(

I never got the error about "No support for unicode surrogates".


Edit:  Oops.  I was running in a Cygwin shell.   I see the problem when I run in cmd.exe.  Now I can try to figure out if I can fix this...
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

obetz

Quote from: Phil Harvey on August 13, 2019, 12:28:33 PM
Thanks Oliver.  I had tried that, but the emoji character didn't survive through the zip process using the available "zip" command on the Mac.

SMP characters not being supported by Mac zip confirms my aversion using silly characters for file names.

Oliver

Phil Harvey

I've just released ExifTool 11.62 with a patch to prevent it from writing files with surrogate characters in their names unless either the file is being renamed or the -overwrite_original_in_place option is used.

The problem was that ExifTool falls back to using the standard i/o library if Win32::FindFile gives an error, and apparently the standard library accesses these files using 8.3 filenames, and when ExifTool renamed the file to add the "_original" suffix, this 8.3 filename got burned in.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

herb

Hello Phil,

Thanks again for looking into this problem and thanks for the corrected version of Exiftool 11.62.
A short test showed that everything is working fine.

Sorry that my answer to your correction comes so late; but I was on a trip with friends and we decided not to have internet.

Please do not misunderstand, but I have an additional small request:
Inside the test directory I had 2 files with different file-extensions - a.jpg and a.jpg_original - and I got from Exiftool.
Warning: [Win32::FindFile] No support for unicode surrogates - F:/Work_Eixm/Emotics/dirtest
Not writing F:/Work_Eixm/Emotics/dirtest/P11982~1.JPG_original
Use -overwrite_original_in_place to write files with Unicode surrogate characters
Not writing F:/Work_Eixm/Emotics/dirtest/P11982~2.JPG
Use -overwrite_original_in_place to write files with Unicode surrogate characters

But Exiftool was asked only to work with extension .jpg and so for me it would be better to avoid the warning about file a.jpg_original.

Please allow also the following hint:
On my Windows 7 system I use Babelmap.exe from http://www.babelstone.co.uk/Software/BabelMap.html to copy a unicode character.
Babelmap supports unicode up to version 12.01.

Thanks in advance
Best regards
Herb

Phil Harvey

Hi Herb,

Quote from: herb on August 19, 2019, 10:08:26 AM
But Exiftool was asked only to work with extension .jpg and so for me it would be better to avoid the warning about file a.jpg_original.

Right.  Thanks.  I'll fix this in the next release.

And thanks for the Babelmap hint.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

herb

Hello Phil,

thanks for the new version containing the requested enhancement.


Best regards
Herb