SharePoint Online support for # and % in file names

[Aaron Robertson-Hodder]

I am trying to update a desktop app to support the use of # and % in file names for SharePoint Online. I have successfully modified some of the code to use the new CSOM methods that take a ResourcePath parameter.

However, we also make use of the REST endpoints to access files in SharePoint and I am unable to find any guidance as to how/when these will support the new characters. At this point we use GetFileByServerRelativeUrl to determine if a file already exists in a location. In CSOM a new method (GetFileByServerRelativePath) has been added, but I can find no such method or documentation about how we should handle these characters in REST Urls. 

This is made especially difficult now that it's now impossible to know whether a Url containing %20 is an encoded space, or a % followed by the number 20! My understanding is that if I can get the file using CSOM I can know which it is (or I don't have to care) because of the new path properties, but if I'm trying to get a file by name using REST I cannot see any way to achieve this. 

Can someone please advise if I'm missing something or when/if this will be possible using REST. I'd rather not move all my code to CSOM but at this point I'm not sure I have much choice.

I'd also like to know if there is a way other than accessing the tenant property SpecialCharactersStateInFileFolderNames (which I think requires more permissions than an average user would have) to know if the characters are supported. I'd rather not have to add a failed server round trips just to find out.

There seems to be a very limited amount of detailed information around these issues despite the fact that we're past the point where most tenants will have this feature enabled.

Thanks in advance for any information provided!

[#2]

Interesting question I would like also to know the answer. Adding here @Vesa Juvonen

[#3]

I'm probably not of much use for the CSOM problem in reference to '#' characters etc. I know it's a problem since when I'm building node projects from a one-drive folder it generates a bunch of # folders for node modules and this causes sync issues with One-Drive. I heard from someone else in my team that they're supposedly adding '#' support for file-systems but I'm sure someone else can verify when and if this is happening/has happended.

What I can say is that you can trust URL encoding. A filename with the name 'File%20Name' would appear as 'File%2520Name' as % is encoded to %25. Just encode and decode and you should end up with something reliable. Also # is encoded as %23.

[#4]

Thanks for your reply Charles, but it's not that simple. I have three files in a SharePoint Document Library, named "test%file.jpg", "test%20file.jpg" and "test file.jpg".

Using REST and the GetFileByServerRelativeUrl method the only file I can access is "test file". If I try and access "test%20file.jpg" without encoding I get the results for "test file.jpg" which makes sense.

However, if I encode the % (so using "test%2520file.jpg") I still get the results for "test file.jpg". No matter what permutation of encoding I use, I cannot access either of the files with % in the name.

[#5]

Testing this myself now, I am unable to upload any files containing a '%' so I can't run through this exact scenario but I know that all three of those filenames you suggest are unique as long as they're encoded and then decoded. Can I ask where you have the ability to upload a file with a '%' in the name?

Either way, if you are making a call to the endpoint for 'test%2520file' it should absolutely return 'test%20file' and if that is not the case then SharePoint may not be behaving as expected. Maybe some double encoding might be a work around? I'm not sure If SP tries to parse any other forms of encoding when using the REST service.

[#6]

You will only be able to if support for these characters is enabled in your tenant. See the following link for details:

https://blogs.technet.microsoft.com/wbaer/2017/04/06/new-support-for-and-in-sharepoint-online-and-on...

[#7]

Oh fantastic thanks, I read somewhere recently the feature had been released. I'll get onto our global admin to enable it as soon as we've verified it's production ready.

I'd love to have a go at replicating the issue; once I can so I'll get back to you after some investigating. This is very relevant to our clients too as we have a lot of cloud migrations that we perform.

[#8]

I just stumbled across this today. There are REST versions of the ...Path methods. The date says it was early November but maybe it didn't hit search when I was originally looking...