With Unzip I can unzip ZIP files protected with a password, that do not contain any files with ä, ö, ü in file names.
With Ditto I can unpack ZIP filled protected with a password and containing files with ä, ö, ü in file names. But Ditto doesn't allow me to pass the password via a Shell action.
As a matter of fact, even this doesn't work for me (I'm not prompted to insert the PW):
This works for me on macOS 10.14.6 Mojave with Keyboard Maestro 10.2.
# This works in Keyboard Maestro...
cd '/Users/chris/test_directory/Keyboard_Maestro_Test_Folder/DITTO_TESTS/test'
unzip -P 'YourPassword' Tëst_Ärchive.zip
Note that the archive file name contains umlauts, and at least one file name within the archive contains umlauts.
There might be a way to echo a password into the ditto command, but since this works I'm not going to spend the time.
Note also that you can use the macOS Archive utility for this task if you have to.
Are these zips you've created or are they from elsewhere, like a Windows user?
Otherwise, grab a copy of Stuffit Expander (free), which will cope with almost anything you throw at it. You can then call it in your macro with an AppleScript action:
tell application "StuffIt Expander"
expand myFile password "myPass0rd"
end tell
...and you can pass the file and password form KM in the usual way. Much easier (and more secure) than trying to use the expect utility to feed a password to ditto in a shell script.
Alas, Stuffit won't open the ZIP files, that indeed were created by a Windows user:
I found that the Archive Utility actually opens the ZIP files. A 'ä' in a file name is converted to a curly quotation mark, but I can fix that via a macro.
The question is:
Can the Archive Utility be controlled by Keyboard Maestro, even when a password needs to be passed?
This is sounding more and more like a Unicode character issue. Out of interest, if you extract the files then open Terminal and type ls (there's a space after the s), drag a file with and accented name on to the Terminal window, type | hexdump -C (there's a space before the "pipe" character) and hit Return -- what's the output? Then try the same for a file with a different accented character.
The worry is that all the "odd" characters will be ?, so it won't be a "simple" S'n'R if you want to preserve file names...
Would have been easier in a code block, but you can see on the second line
00000010 70 2f 45 72 67 61 cc 88 6e...
...where 61 is a, 6e is n, leaving the cc 88 in-between. Looking up0xCC 0x88 gives us U+0308 which you can see is the "Combining Diaeresis" and is fine on the Mac.
But it's probable that unzipping on Windows then transferring to the Mac is also allowing character conversion at one point or another. I should have been more clear -- you need to unpack the password-protected zip with Archive Utility then hexdump the name, so we can see why it is giving you ? rather than ä.
Doing the same as before, 67 is g, 6e is n so the bits in-between are your accented u -- e2 80 9e. Looking up that triplet will get you U+201E, the "Double Low-9 Quotation Mark" -- which is what you are seeing.
I'm guessing it's Windows character encoding that is handled cleanly when you transfer the unzipped file from PC to Mac, but not when you unzip it directly on the Mac. You might be able to build a table that you can use to convert the "odd" characters back to what you want with KM search-and-replace actions...
NOTE – you may get better performance out of The Unarchiver than from the macOS Archive Utility. I haven't tested it in a while, but I used it in preference to the AU for many years and may go back to it when I have system hardware with more space again.
