Loading ...
Sorry, an error occurred while loading the content.

1014Re: Filename encodings under Win32

Expand Messages
  • Camillo Särs
    Oct 14, 2003
      Bram Moolenaar wrote:
      > Glenn Maynard wrote:
      >>It's certainly useful to be able to have multilingual filenames, but
      >>Windows makes it so hard that people really wanting to do that probably
      >>need a new OS.
      > So, what you suggest is to keep using the ordinary file system
      > functions. But we must make sure that the file name is then in the
      > active codepage encoding.

      While that may sound attractive at first, I would strongly dissuade from
      that solution. I consider it to be a myth that using multilingual
      filenames on Windows is hard. Under NT, it's should be a breeze for any
      application that is even slightly Unicode-aware. When you decide to make
      changes in Vim, it makes sense to look to the future and try to go the
      "Unicode" way. XP Home Edition is gaining ground - fast.

      Win9x is a mess, because it's just a version of DOS on hormones, and thus
      is solidly entrenched in the single code page per application world. Using
      the current code page should suffice there, though.

      > This is still complicated, but probably requires less changes than using
      > Unicode functions for all file access.

      Why? I don't get it. You don't need to use Unicode functions for anything
      except stuff that accepts strings. The current implementation is wrong,
      because it feeds "encoding" text to ANSI functions. If you change it, I
      don't see why doing a conversion to Unicode would be any different than a
      conversion to ANSI, other than the fact than converting to ANSI is riskier.

      <http://www.microsoft.com/globaldev/> contains a lot of useful info. Quote:

      "All Win32 APIs that take a text argument either as an input or output
      variable have been provided with a generic function prototype and two
      definitions: a version that is based on code pages or ANSI (called "A") to
      handle code page-based text argument and a wide version (called "W ") to
      handle Unicode."

      For 9x, you might be interested in the "Microsoft Layer for Unicode"

      > I only foresee trouble when 'encoding' is set to a non-Unicode
      > codepage different from the active codepage and using
      > a filename that contains non-ASCII characters.
      > Perhaps this situation is too weird to take into account?

      As long as you know the correct code page, you can use Windows APIs to
      convert correctly. They take the code page as an argument.

      Camillo Särs <+ged+@...> ** Aim for the impossible and you
      <http://www.iki.fi/+ged> ** will achieve the improbable.
      PGP public key available **
    • Show all 29 messages in this topic