What you actually want to do, is first decode the string and then encode it again. Don't bother trying to patch an encoded string.
Any encoding is only worth its salt if it can be decoded easily, so reuse that logic to make your life easier. And your software less bug-prone.
Now, if you are unsure of whether the string is encoded or not - the problem will most certainly not be the string itself, but the ecosystem that produced the string. Where did you get it from? Who did it pass through before it got to you? Do you trust it?
If you really have to resort to creating a magic-fix-weird-data function, then consider building a table of "encodings" and their corresponding characters:
& -> &
€ -> €
< -> <
// etc.
Then, first decode all encountered encodings according to the table and later reencode the whole string. Sure, you might get more efficient methods when fumbling without decoding first. But you won't be sane next year. And this is your carrier, right? You need to stay right in the head! You'll loose your mind if you try to be too clever. And you'll lose your job when you go mad. Sad things happen to people who let maintaining their hacks destroy their minds...
EDIT: Using the .NET library, of course, will save you from madness:
I just tested it, and it seems to have no problems with decoding strings with just ampersands in them. So, go ahead:
string magic(string encodedOrNot)
{
var decoded = HttpUtility.HtmlDecode(encodedOrNot);
return HttpUtility.HtmlEncode(decoded);
}
EDIT#2: It turns out, that the decoder HttpUtility.HtmlDecode
will work for your purpose, but the encoder will not, since you don't want angle brackets (<
, >
) to be encoded. But writing an encoder is really easy:
define encoder(string decoded):
result is a string-builder
for character in decoded:
if character in encoding-table:
result.append(encoding-table[character])
else:
result.append(character)
return result as string
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…