How is Windows directory names and registry names case-insensitive?

  • Thread starter Thread starter Elder Hyde
  • Start date Start date
E

Elder Hyde

I mean, are they culturally case-insensitive, or, how to put this,
invariantly culturally case-insensitive (duh!). In other words, if what
I'm putting in a Hashtable are directory names or registry key name,
should I use the DefaultInvariants of hashcodeprovider and comparer, or
just the Defaults?

Thanks!
Elder
 
Hi Elder,

When I have to deal with strings in a case insensitive way, I always use
str.ToUpper() as hashtable key. I find this simpler (and thus safer) than
working with hashcodeprovider, case insensitive comparer, etc.

Bruno.
 
Hi Bruno,

The thing is that I do want to preserve the case if possible. It's a bit
like Windows explorer--it remembers the case, but if you try to create
another directory with the same name and different case it'll reject
you, whereas ToUpper() destroys the original casing.

In other words, what I'm wondering about is this (taken from .NET
developer's guide):

"The following code example demonstrates how the result of a
case-insensitive String.Compare operation performed on the strings
"FILE" and "file" differs depending on culture. The comparison returns
true if the Thread.CurrentCulture property is set to "en-US" (English in
the United States). The comparison returns false if CurrentCulture is
set to "tr-TR" (Turkish in Turkey)."

So, I can assume from here that although one using the American English
Windows can *not* create directory "FILE" and "file" at the same level,
they can create FILE and file if they're using the Turkish Windows? If
that's the case, I cannot use the DefaultInvariants can I? I have to use
Default, or else in Turkey someone who wants to create "FILE" and "file"
may not be able to.

Thanks
Elder
 
Hi Elder,

To preserve the case, I do the following: I use the ToUpper() as key but I
use the original string as value in my hashtable. Sometimes, the value is a
bit richer (a small object) but I include the original string in the value.
This way I get case independent lookup but I still have the original string
once the lookup has been performed.

I think that the Turkish problem is due to the "dotless i" (U0131). This is
a lowercase character that does not have its own uppercase variant. Instead,
it becomes "I" (U0049) in uppercase, just like the normal i (U0069). I don't
know how the Turkish Windows handles this special case. It should not allow
file (normal) and FILE together, it should not allow file (dotless) and FILE
together either because FILE is the upcase version of file (dotless), but
will it allow file (normal) and file (dotless) together? You have to test
it, or ask a Turkish friend.

Bruno.
 
I overlooked one thing: the Turkish code set has an "uppercase I with dot
above". So, the upcasing/downcasing rules are:

latin i (U0069) <--> uppercase I with dot above (U0130)
dotless i (U0131) <--> latin uppercase I (U0049)

This explains why the uppercase version of "file" is not "FILE" but "FI(with
dot above)LE".

But still, I don't know how Turkish Windows handles filenames that contain
these strange characters.

Bruno.
 
I'm not sure that installing a Turkish version of Windows will get you
anywhere either. I would not do it!

Take care,

Bruno.
 
Hi Bruno,

OK thanks :) Darn I don't have any Turkish friend. I really should get
out more and travel to Turkey instead of coding all weekend long like
this ;)

Cheers
Elder
 
Back
Top