id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,os,architecture,failure,difficulty,testcase,blockedby,blocking,related
3977,Support double-byte encodings (Chinese/Japanese/Korean) on Windows,shelarcy,batterseapower,"localeEncoding uses the console code page for text file encoding/decoding for single-byte encoding environment on Windows. But GHC.IO.Encoding.CodePage.Table doesn't have double-byte encodings (Chinese/Japanese/Korean), now. Its current state often causes problem on double-byte encoding environment.

 * http://hackage.haskell.org/trac/hackage/ticket/658
 * http://hackage.haskell.org/trac/hackage/ticket/659

I know we can solve problem by using hSetEncoding with utf8 or othere UTF-* encodings. But it's not good solution.

According to previous Windows patch, GHC.IO.Encoding.CodePage.Table doesn't support double-byte encodings because Windows' shared library support doesn't work.

 * http://www.haskell.org/pipermail/cvs-libraries/2009-September/011289.html
 * http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=packages/base;a=commitdiff;h=20090913022126-9f663-2bb505cf915b18313bf41a25853d9d13d7444feb.gz

{{{
Currently we do not support double-byte encodings (Chinese/Japanese/Korean), since
including those codepages would increase the table size to 400KB.  It will be
straightforward to implement them once the work on library DLLs is finished.
}}}

I think Windows' shared library support works now. Because #3879 is closed.

So, how about add supporting double-byte encodings (Chinese/Japanese/Korean) on Windows?",feature request,new,low,7.8.1,libraries/base,6.13,,,shelarcy@…,Windows,Unknown/Multiple,Incorrect result at runtime,Unknown,,,,#5754