Ramifications of removing encodeNameReplacement for dot (.)

Question

Sitecore has a number of encodeNameReplacements in config OOTB, I fully understand what they are and what they do since I have previously posted about it.

The issue we have is we have a number of compressed (software) files, which are of the format filename-something.tar.gz. By default, when the files are uploaded Sitecore takes only the last part of the file (.gz) as the extension and then see's the dot in the rest of the filename (filename-something.tar) and this fails default ItemNameValidation regex (at this point the file is internally renamed to filenamesomethingtar.gz instead of a complete failure, but still not acceptable to us). Following a Sitecore Support ticket we updated this setting to allow dots in the filename...

The issue is the encodeNameReplacements kick in:

<encodeNameReplacements>
  ...
  <replace mode="on" find="." replaceWith=",-d-,"/>
  ...
</encodeNameReplacements>

With this in place, the media url is being generated as filename-something,-d-,tar.gz

I could remove this replacement, but is this likely to raise other issues elsewhere in Sitecore backend?

EDIT:

We are running Sitecore 8.1 Update-3

As I said, I understand how the encoding and decoding works and the ,-d-, is set by the encodeNameReplacement setting I mentioned (which also applies to media url generation since Sitecore 7.2). But some of these values are valid URL characters. I can only assume they were added for a particular reason in the first place, namely to get around some issues in the back-end system. Removing this setting will require extensive testing of standard Sitecore features which we would like to avoid. I'm confident nothing in our own code will not break, not so much about Sitecore's so am trying to understand this so we can minimize issues.

Answer 1

From what I can find - the encodeNameReplacements are only used in MainUtil.DecodeName, MainUtil.EncodeName and MainUtil.EncodePath - These are used in both resolving url's and building them. So if the encoding is not there or if it encoded to something different it should still work ok. I could not find anything that explicitly set ,-d-, in the Url. Everything goes through one of those 3 methods.

If you go with removing the encoding completely and are running v7.2u1 or earlier, you may need to set the relaxedUrlToFileSystemMapping attribute to true so that IIS doesn't try to map it to a valid Windows file path. This was updated in v7.2u2 and later.

<httpruntime relaxedUrlToFileSystemMapping="true" />