The inverse of the canonical string encoding is used in the following places:
It is always allowed to store a string value into any metadata field, no matter what the type of the field is. The actual data stored is the result of applying the canonical string decode operation to the incoming string value.
On a virtual view lookup operation, the canonical string decode operation is used on the supplied filename to derive the actual metadata values to look up, given their string representations in the filename.
The decode operation is allowed to accept incoming string values that would never be a legal output for an encode operation. Some examples of this include:
decodeBinary of an odd number of hex digits. The convention is to left-justify the supplied digits in the binary value. For example, the string "b0a" corresponds to the binary literal [b0a0].
decodeDate of a non-standard date format.
A double value encoded with a non-canonical number of digits. For example, .00145E20 instead of 1.45E17.
If you take a value V and encode it into a string S, and then perform the canonical decode operation on S to get a new value V’. Does V always equal V’? The answer is yes in most cases, but not always.
What is actually guaranteed is the weaker statement that if encode(V) = S and if decode(S)=V’, then encode(V’) is also equal to S.