I think that yes, it's still safe, depending on how the "hashing" works.
You're not really talking about a salt value, since it is unknown. The scenario you describe fits a MAC better IMO. MACs require the input data (your single character) and a secret (your unknown "salt") and are designed to be safe despite the plaintext input data being known (since they are usually used to authenticate messages, where both the MAC and the plaintext message is known).
To be secure against attack, you can't just use a plain hash, such as
value = sha256(character || secret)
This wouldn't be safe. But if you use a primitive such as HMAC, it should be:
mac = hmac_sha256(character, secret)
Your requirements, if I understood correctly, are that it should be impossible for someone without the secret to determine, given
mac1 = hmac_sha256('0', secret)
mac2 = hmac_sha256('1', secret)
mac62 = hmac_sha256('z', secret)
which mac goes with which input character, and what the secret is.
MAC's guarantee that with a given input, such as '0', and mac1, there is no better attack on secret than brute-force, even if the secret is reused many times. So your secret is safe.
The question that remains is whether you can determine which input character belongs to mac1, mac2 etc if you are not in possession of the secret.
I think that's equally impossible, but I can't see how to prove the equivalence of that with the message integrity guarantees MACs make, so even though I don't think I am, I might be wrong.
I have some reasons for my beliefs:
Ideally, for hash functions, if you change a single bit in the message, that should influence all bits of the hash value. If I understand the way hmacs are calculated correctly, then that also goes for the secret, e.g. the secret influences every single bit in the mac output. So if there was a way to determine which mac belonged to which input without the secret, I think that would mean hmac is leaking information about the secret, and there should therefore exist a better than brute-force method to attack the secret.
But really you should ask a cryptographer, so crypto.stackexchange.com might be a better place to get a good answer.