Support double-byte encodings (Chinese/Japanese/Korean) on Windows
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 (closed) is closed.
So, how about add supporting double-byte encodings (Chinese/Japanese/Korean) on Windows?
Trac metadata
| Trac field | Value |
|---|---|
| Version | 6.12.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | shelarcy@gmail.com |
| Operating system | |
| Architecture |