Bug 2040 – Add codepage handling to core library

I need to deal with non-unicode docs a lot. The current D library makes this unpleasant; either I need to track down and use iconv + D wrapper or code up the conversions myself. While I applaud the choice to make everything in D unicode, the real world is still out there. As a systems language especially, D should have the facilities to handle other codepage input and output natively. Java includes these abilities well-integrated with the IO package. D should do this as well. Perhaps this code might belong to std.utf. Or perhaps there should be a deeper package hierarchy, like std.text.convert.

Check out std.encoding. Currently, support for specific codepages is not built in (apart from ASCII, Latin-1 and Windows-1252), but class EncodingScheme has a register mechanism which allows you to add any arbitrary encoding scheme. If you would like a /specific/ codepage built into the library, let us know.

[email protected] wrote: > http://d.puremagic.com/issues/show_bug.cgi?id=2040 > > > > > > ------- Comment #1 from [email protected] 2008-04-26 14:33 ------- > Check out std.encoding. > > Currently, support for specific codepages is not built in (apart from > ASCII, Latin-1 and Windows-1252), but class EncodingScheme has a > register mechanism which allows you to add any arbitrary encoding > scheme. This is a recent addition, I see. It's very welcome. > If you would like a /specific/ codepage built into the library, let us know. The scenario is processing random web pages. To do that, you need a significant collection of encodings in the wild, so there isn't any one particular encoding I'd ask for.

Recommend closing this. Its very old, there is no bug reported, there is no sample code, not very specific.

I agree, this likely will not happen, and it's also very out of date. Closing, if you still think we need this, make the case with latest library in mind.