On 24/Sep/2010 06:13, Robert Muir wrote:
> On Fri, Sep 24, 2010 at 1:06 AM, Tim Ellison <t.p.elli...@gmail.com> wrote:
>
>> On 24/Sep/2010 05:28, Robert Muir wrote:
>>> On Fri, Sep 24, 2010 at 12:10 AM, Tim Ellison <t.p.elli...@gmail.com>
>> wrote:
>>>> Thanks. Seems strange since it could obviously produce some 'unusual'
>>>> results. In this case, computing a hashCode, it likely doesn't matter
>>>> if the result is a bogus string.
>>>>
>>>>
>>> Do you have an example where the result would be unusual for a filename?
>> I'm not thinking it would be unusual for being interpreted as file path
>> (e.g. it won't introduce a '/' or anything like that) but that the
>> result would not be the lowercase equivalent in the locale that the user
>> created the filename.
>
>
> but case-sensitive filenames (such as windows) don't use locale-dependent
> comparisons?
> they implement locale-independent case-folding. for example if i have a
> file "σ.txt", I cannot create "ς.txt". (I just tried)
> Both of these files are already in lowercase.
Ah ok, I didn't realize that windows did that.
> The interesting question is: how does hashCode() relate? Because a hashcode
> based upon String.toLowerCase(Locale.ENGLISH) would return different
> hashcodes for these two filenames, but with UCharacter.foldCase(), it would
> be the same.
System.out.println(new File("σ.txt").hashCode());
System.out.println(new File("ς.txt").hashCode());
prints out
889962580
890776533
on both Harmony and the RI.
Regards,
Tim
