Thanks for the bug report @jet10000! We'll take a look.

@thebengeu @jet10000 @alaister
As per now for both objectName and bucketName , supabase only allow s3 safe characters as per AWS guideline here

 // only allow s3 safe characters and characters which require special handling for now
 // https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html

S3 supports UTF-8 characters in filenames. However, at the moment, we are very strict with which filenames we allow.
I think this is a valid use case to add support for different languages in filenames.

One option is to update the isValidKey function https://github.com/supabase/storage-api/blob/9480891af024396c58045578d16c91778aae67d2/src/utils/index.ts#L76-L80 to allow everything aside from the characters outlined in https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html#object-key-guidelines-avoid-characters

I would love support for å,ä,ö.

Love from Sweden

Hi, opendal meets a similiar problem in apache/opendal#2190 that we have a test case (which passed on most storage platforms from s3, gcs, azalob to hdfs) like the following:

let path = format!("{} !@#$%^&()_+-=;',.txt", uuid::Uuid::new_v4());

Does this case make sense to you? I'm willing to help fix this. I believe that all URL-unsafe characters should be percent-encoded, and the server-side should handle the job of decoding them.

I would love support for ´ I can't use words with accents in my images, which is very common in Spanish.

Also ÖÄÜ in german

I could understand that the isValidKey function looks like because it would be safe if the system accepts only the alphabet.
As I'm Korean, there is no good way to safely convert from the Korean characters(hangul) to alphabet. It would be same for the Japanese characters and Chinese characters too.
Are there any specific reasons for the function's regex? If the function accepts the encoded characters from encodeURIComponent function, it would be great.

MacOS generates screenshot names that don't match the pattern in isValidKey. For example, "Screenshot 2024-01-24 at 12.25.39 AM".

Ops! This issue seems easy to fix but have last for 2 year's. Unbelievable!

hi everyone

My solution is base64 encoding when uploading file, demo: https://github.com/ThaddeusJiang/supabase-helpers/blob/main/backup_storage_buckets.ts#L71-L73

This is a big pretty big oversight. At the very least it would be nice if this was documented somewhere

You can upload files using any name (e.g. base64, thx @ThaddeusJiang ), store the original file name in a different table, and then use it when generating the public link:

const {
  data: { publicUrl },
} = supabase.storage
  .from('my_bucket')
  .getPublicUrl(internalFileName, { download: originalFileName })

Source (for URL access): https://supabase.com/docs/guides/storage/serving/downloads#downloading
The supabase-js docs unfortunately do not mention this yet: https://supabase.com/docs/reference/javascript/storage-from-getpublicurl

As a non-english supabase developer, it is painfull that I can not upload assets other than alphabeta filenames. I hope the supabase teams take this issue with priority, as this issue has not fixed after two years and so many people complains on it.

As this blog post says that Supabase Storage is now S3 compatible. I think only supporting a subset of s3 valid characters for object names is not fully compatible with s3.

came here to see that we cant store UTF-8 as filename... crazy. Not even ISO-8859-1 because german umlauts are easily in there as well. The only hope i guess is the new metadata feature which should arrive soon in the JS lib. Proposals like creating a db table for storing filenames is a non-starter becasue the syncing of storage and db tables is virtually impossible.

I would like to use special characters in names as well. Trying to name images by the patient name and here in Balkans it's common to have čšžć in the first or last name.

Seems odd to me that this hasn't already been addressed.

Another case: A user tried to upload a file with a backtick and it threw an InvalidKey error.

Are there any news on this? I have it even fail on characters like a %, which is not even unicode

Bug report

When upload "望舌诊病.pdf"

Describe the bug

supabase really should study the products from China, this is the product using supabase, but solved the problem of file name. How supabase was unable to solve the problem. Then request and copy it! The address is https://memfiredb.com/

@renjiali It's good for you to fix this problem, but please send a pull request to the upstream project instead of spamming in this issue.

I could understand that the isValidKey function looks like because it would be safe if the system accepts only the alphabet. As I'm Korean, there is no good way to safely convert from the Korean characters(hangul) to alphabet. It would be same for the Japanese characters and Chinese characters too. Are there any specific reasons for the function's regex? If the function accepts the encoded characters from encodeURIComponent function, it would be great.

I've posted the comment to know that there is any conflicts if I change the function isValidKey to accept encodeURIComponent. I'm pretty sure that there is some reason for not accepting it because Supabase team seems to be quite reasonable.

And @renjiali, please DO NOT SPAM. If there is any comment added on this issue, the watchers get the mail for each of the comments.

@renjiali This is a space for helping and working with users of Supabase, it is not a place for politics or insulting users. Your comment has been hidden and marked as abuse now and, if this is reported again, you will be blocked from posting to this community. Please be considerate

For anyone else who is running into this issue, here is my snippet for converting filenames to base64 and back in the browser:

function base64ToBytes(base64) {
    const binString = atob(base64);
    return Uint8Array.from(binString, (m) => m.codePointAt(0));
}

function bytesToBase64(bytes) {
    const binString = Array.from(bytes, (byte) =>
        String.fromCodePoint(byte),
    ).join("");
    return btoa(binString);
}

const convertFileNameToBase64 = (name) => {
    return bytesToBase64(new TextEncoder().encode(name));
}
const convertBase64ToFileName = (encoded) => {
    return new TextDecoder().decode(base64ToBytes(encoded));
}

Given the amount of attention and requests for this issue to be addressed, I'm surprised that it still hasn't been addressed even after 2 years. I understand that the restriction might be due to security reasons, but it's essentially locking out any non-English speaker (or anyone not building an app in English) from using Supabase for their apps. Even though I'm an English speaker the app I'm currently building is mainly for non-English speakers and their filenames is certainly not gonna be in English so having to force to change their filenames every time before uploading it will be frustrating both me and the users which means I might ultimately have to switch to a different backend service down the road😔.

@albas99 an easy solution would be to hex-encode the filename before uploading. The restriction is from the S3 spec, Supabase support confirmed this to me.

if you wanna have a very close representation of your passed non-latin filename, you could use something like this i suppose: https://www.npmjs.com/package/remove-accents

@alaister Please help us to solve this issue🙏

Hey this is the regex im using in my template

const safeFilename = filename.replace(/[^0-9a-zA-Z!\-_.*'()]/g, '_');