Supplying an encoded URI containing %20 in IOS causes a 'failed to open zip file'

[Jaymes Bearden]

Describe the bug
In Expo native, I have bundled a series of zip files with my application that are to be unpacked at runtime. These files are expo bundled, provided/loaded as require('my-local.zip') and locally resolved with expo-asset "resolveAsync" which supplies a file:// pointing to a "localUri". In Android, everything works great. In IOS; however, the zip file's localUri resolves to file:///var/mobile/Containers/Data/Application/.../Library/Application%20Support/.expo-internal/... (Note the %20). If you check for this file with expo-file-system FileSystem.getInfoAsync, this file correctly exists and is readable/writeable. If you attempt to unzip this local file uri, it will fail.

If you take this file URI and replace %20 with a space , the zip file correctly unzips as expected. Is it possible that the normalizeFilePath function can check/replace %20 with a space or perhaps do a URI decode on the supplied path? Or should we be doing this ourselves?

Expected behavior
A ZIP file from a URI containing URI encoding on IOS should unzip to the supplied destination.

Environment:

• Device: iPad Air 4th gen
• OS: iPadOS
• OS Version: 16.6
• Package Version: 6.0.9

Potential Solution
Adjust the normalizeFilePath as follows:

const normalizeFilePath = (path) => {
  const filePath = path.startsWith("file://") ? path.slice(7) : path;
  return filePath.replace('%20', ' '); // or decodeURI(filePath) ?
}

Additional context
If we should be providing normalized file uris, can the documentation be updated to indicate this?