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

2464Re: Unicode conversion bug?

Expand Messages
  • Tony Mechelynck
    May 1, 2008
      On 02/05/08 03:29, T.P.S.Nakagawa wrote:
      > This is Nakagawa, Japanese user on unix and Windows XP SP2.
      > ( Windows Japanese version's native character set is cp932 )
      > I found same problem 30 April, another way.
      > ( I did'n t read this ML usually )
      > I found.
      > Windows notepad can read no-bomb UTF-8 file, but if edited or created
      > file is saved with bomb.
      > By unicode consocium standard, UTF-8 file can added bomb.
      > but UTF-8 not need bomb.
      > Vim use libiconv by FSF.
      > I search on unix platform, `man iconv_open`, libiconv don't know
      > UTF-8 with bomb. Then, libiconv can't detect UTF-8 with bomb.
      > this is problem of libiconv, not Vim, by strict logic.
      > In this reason, In my vimrc set filencodings sorted earlier UTF-8 than cp932
      > but notepad saved file detected cp932.
      > On justice way, We have to patch to libiconv, add UTF-8 bomb.
      > But Can't save this weak point by Vim side?

      The BOM is a valid codepoint, ZERO-WIDTH NO-BREAK SPACE; however its use
      in that capacity is now deprecated (ZERO-WIDTH NON-JOINER is preferred
      IIUC). Still, if any software accepts UTF-8 files "only" if there is no
      BOM in them, that software cannot be called UTF-8-compliant.

      I don't know which libiconv you are using, but my version of Vim (which
      has +iconv and a GTK2/Gnome2 GUI) accepts the BOM with no problem, not
      only in UTF-16/UTF-32 but also in UTF-8.

      Best regards,
      The church is near but the road is icy; the bar is far away but I will
      walk carefully.
      -- Russian Proverb

      You received this message from the "vim_multibyte" maillist.
      For more information, visit http://www.vim.org/maillist.php
    • Show all 25 messages in this topic