RE: Subject: Re: 32'nd bit & UTF-8

From: Arcane Jill (
Date: Mon Jan 24 2005 - 02:18:03 CST

  • Next message: Peter Constable: "RE: I Heart Huckabees"

    I, too, have also managed to create Windows filenames containing U+FFFF,
    Windows filenames containing unpaired surrogates, etc.

    I have also managed to store two files in the the same (Windows) directory, one
    called "ss" and the other called "ß" (U+00DF). This violates the principle that
    "ss" and "ß" are supposed to be equivalent in a case-insensitive system.

    Windows was quite happy to handle those files after the event, including
    copying them from place to place. Even the directory containing "ss" and "ß"
    could be dragged from a FAT16 filesystem to an NTFS filesystem without

    However - I *do not* believe that this behavior on the part of Windows is
    correct. It is broken, and should be fixed. Filenames /should/ be made of
    characters. Not opaque octets. Not opaque 16-bit words. This behaviour is
    broken. Period.


    -----Original Message-----
    From: []On Behalf
    Of Lars Kristan
    Sent: 22 January 2005 10:54
    Subject: RE: Subject: Re: 32'nd bit & UTF-8

    Then Windows should NOT allow creation of such filenames. But, hell, it surely
    allows unpaired surrogates (Windows is still pretty much UCS-2). And it also
    allows U+FFFF. Well, it looks like filenames on Windows are not really text,
    they are binary data. Not that I believe that, but I've been told to process
    UNIX filenames as binary data. Guess the same is then true for Windows
    filenames. Nice.


    This archive was generated by hypermail 2.1.5 : Mon Jan 24 2005 - 11:21:22 CST