2464Re: Unicode conversion bug?
- May 1, 2008On 02/05/08 03:29, T.P.S.Nakagawa wrote:
> This is Nakagawa, Japanese user on unix and Windows XP SP2.The BOM is a valid codepoint, ZERO-WIDTH NO-BREAK SPACE; however its use
> ( 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?
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.
The church is near but the road is icy; the bar is far away but I will
-- Russian Proverb
You received this message from the "vim_multibyte" maillist.
For more information, visit http://www.vim.org/maillist.php
- << Previous post in topic Next post in topic >>