Converting to/from a string without regard to culture

  • Thread starter Thread starter John Brown
  • Start date Start date
J

John Brown

Hi there,

Does anyone know how to go about reading/writing a type to a file in a
language (culture) independent way. For instance, let's say you're dealing
with the native "System.Drawing.Size" type on an English version of Windows.
You use the "TypeConverter" for this structure to generate the string, say,
"50, 75" which you then store in a file (or perhaps a DB). Now, the same
value might later be read back in from this file on a Japenese version of
Windows (or more accurately on a thread where the culture is set to
Japanese). Let's say the comma (",") is actually a period (".") in Japanese
however though I'm just making this up for demonstration purposes. How do
you now convert the original value "50, 75" into a "Size" object given that
the system presumably won't recognize the comma anymore (only a period).
Conversely, how do you convert a "Size" object back to a culture-independent
string (in this case using a comma) so that it can be processed on the
original English machine again. Or maybe this isn't as complicated as I'm
making it out to be. I'm just not sure how to use the "TypeConverter" class
to write my string in a consistent way given that it has to be read back in
on a thread running with a different "CutlureInfo". Can anyone provide any
insight on the matter. Thanks very much.
 
Does anyone know how to go about reading/writing a type to a file in a
language (culture) independent way. For instance, let's say you're dealing
with the native "System.Drawing.Size" type on an English version of
Windows. You use the "TypeConverter" for this structure to generate the
string, say, "50, 75" which you then store in a file (or perhaps a DB).
Now, the same value might later be read back in from this file on a
Japenese version of Windows (or more accurately on a thread where the
culture is set to Japanese). Let's say the comma (",") is actually a
period (".") in Japanese however though I'm just making this up for
demonstration purposes. How do you now convert the original value "50, 75"
into a "Size" object given that the system presumably won't recognize the
comma anymore (only a period). Conversely, how do you convert a "Size"
object back to a culture-independent string (in this case using a comma)
so that it can be processed on the original English machine again. Or
maybe this isn't as complicated as I'm making it out to be. I'm just not
sure how to use the "TypeConverter" class to write my string in a
consistent way given that it has to be read back in on a thread running
with a different "CutlureInfo". Can anyone provide any insight on the
matter. Thanks very much.
Click to expand...

Ok, I'm thinking that I need to call
"TypeConverter.ConvertToInvariantString()" to write the value and
"TypeConverter.ConvertFromInvariantString()" to read it back in. However,
once read back in using the latter function, I then need to pass the value
to "TypeConverter.ConvertToString()" if I actually want to display it (since
I assume "ConvertToString()" is culture-sensitive). Conversely, if a user
enters the string in some field during data-input, I would need to convert
it using "TypeConverter.ConvertFromString()" and then pass this back to
"TypeConverter.ConvertToInvariantString()" before writing it to file again.
Is this correct? Thanks.
 
John Brown said:
Does anyone know how to go about reading/writing a type to a file in a
language (culture) independent way. For instance, let's say you're dealing
with the native "System.Drawing.Size" type on an English version of Windows.
You use the "TypeConverter" for this structure to generate the string, say,
"50, 75" which you then store in a file (or perhaps a DB). Now, the same
value might later be read back in from this file on a Japenese version of
Windows (or more accurately on a thread where the culture is set to
Japanese). Let's say the comma (",") is actually a period (".") in Japanese
however though I'm just making this up for demonstration purposes. How do
you now convert the original value "50, 75" into a "Size" object given that
the system presumably won't recognize the comma anymore (only a period).
Click to expand...

Have you tested this assumption? I would hope that TypeConverter was
already culture-independent, but I haven't tried it.
Conversely, how do you convert a "Size" object back to a culture-independent
string (in this case using a comma) so that it can be processed on the
original English machine again. Or maybe this isn't as complicated as I'm
making it out to be. I'm just not sure how to use the "TypeConverter" class
to write my string in a consistent way given that it has to be read back in
on a thread running with a different "CutlureInfo". Can anyone provide any
insight on the matter. Thanks very much.
Click to expand...

I'd say the first thing to do is to make sure there's actually a
problem. Try exactly the situation you fear will fail.
 
The comma you are talking about is actually part of the language, C#, it is
a list separator, and therefore it's got nothing to do with localization!
 
Thanks for the feedback...
Have you tested this assumption? I would hope that TypeConverter was
already culture-independent, but I haven't tried it.
Click to expand...

I can't find any documenation that clarifies the situation but I'm fairly
certain that it isn't (culturally-independent). How could it be for instance
when commas and other types of punctuation can differ from one culture to
another (which is readily apparent simply by looking at regional settings in
the control panel). Moreover, customized type conversions may be influenced
by locality and that's something you can never escape. Finally, a quick look
at some of the "TypeConverter()" functions clearly indicates that culture
does come into play but I can't pin down the precise rules.
I'd say the first thing to do is to make sure there's actually a
problem. Try exactly the situation you fear will fail.
Click to expand...

You can't accurately test this however without actually installing a
localized version of Windows or possibly using the Windows MUI (Multi User
Interface) pack which really isn't a (completely) accurate test IMO. The MUI
pack isn't available through normal retail channels in any case. I'd like to
know what the rules actually say rather than just relying on ad hoc tests.
Anyway. thanks again for the feedback.
 
Can CultureInfo.InvariantCulture property help you to achieve required
result?
Click to expand...

Maybe (probably perhaps) but I'm still looking into the matter as mentioned
in my initial follow-up post. I think
"TypeConverter.ConvertToInvariantString()" and cousins are probably the key.
 
Size size = new Size(1,2);
TypeConverter typeConverter = TypeDescriptor.GetConverter(typeof(Size));
String text = typeConverter.ConvertToInvariantString(size);
size = (Size)typeConverter.ConvertFromInvariantString(text);

Which is jus short-hand for:
text = typeConverter.ConvertToString(null, CultureInfo.InvariantCulture,
size);
size = (Size)typeConverter.ConvertFromString(null,
CultureInfo.InvariantCulture, text);
 
Size size = new Size(1,2);
TypeConverter typeConverter = TypeDescriptor.GetConverter(typeof(Size));
String text = typeConverter.ConvertToInvariantString(size);
size = (Size)typeConverter.ConvertFromInvariantString(text);

Which is jus short-hand for:
text = typeConverter.ConvertToString(null, CultureInfo.InvariantCulture,
size);
size = (Size)typeConverter.ConvertFromString(null,
CultureInfo.InvariantCulture, text);
Click to expand...

Ok, thanks. It appears that the use of "InvariantCulture" is probably the
key so at least I can go from here.
 
John Brown said:
I can't find any documenation that clarifies the situation but I'm fairly
certain that it isn't (culturally-independent). How could it be for instance
when commas and other types of punctuation can differ from one culture to
another (which is readily apparent simply by looking at regional settings in
the control panel). Moreover, customized type conversions may be influenced
by locality and that's something you can never escape. Finally, a quick look
at some of the "TypeConverter()" functions clearly indicates that culture
does come into play but I can't pin down the precise rules.
Click to expand...

My mistake - I'd somehow thought you were talking about a serializer.
However, it certainly does look like the ConvertToInvariantString calls
are what you're after.
You can't accurately test this however without actually installing a
localized version of Windows or possibly using the Windows MUI (Multi User
Interface) pack which really isn't a (completely) accurate test IMO. The MUI
pack isn't available through normal retail channels in any case. I'd like to
know what the rules actually say rather than just relying on ad hoc tests.
Anyway. thanks again for the feedback.
Click to expand...

Well, just changing the culture of the current thread and seeing
whether you can still retrieve the data accurately would be a good test
to start with, I'd say. I completely understand about wanting more than
tests though :)
 
Back
Top