The SLAR on System.Text.ASCIIEncoding


The SLAR on System.Text.ASCIIEncoding


 


Continuing in the series on sharing some of the information in the .NET Framework Standard Library Annotated Reference Vol 1 here are some of the annotations on the ASCIIEncoding class.


 


Brad Abrams:Regrettably, the ASCIIEncoding class does not follow the standard naming


convention: it should really be called AsciiEncoding. We settled on the naming


convention for abbreviations too late in the cycle to fix this.


 


Brian Grunkemeyer:    We hope that users will not choose ASCII for persisting data in files when they


can control the file format. We have fully shifted to Unicode, and our recommended


text transfer format is UTF-8, which is as compact as ASCII for US English text, yet


also supports all Unicode characters.


 


Jeff Richter: Normally, there is no need for your application code to construct an Encodingderived


object (such as ASCIIEncoding). Instead, you normally obtain an Encodingderived


object by calling one of Encoding class’s static, read-only properties. Here is an


example:


ASCIIEncoding asciiEncoding = Encoding.ASCII;


This is more efficient because it returns a reference to a single ASCIIEncoding object


rather than creating new ASCIIEncoding objects.

Comments (5)

  1. MartinJ says:

    Any chance that more encoding will be added? I hate to say it, but sometimes we need to interact with other (read: legacy) file systems. One of the more popular formats would be EBCDIC (sp?). It would be nice to not have to develop our own implementation that might not be 100% correct. For some reason, I doubt that we’re the only one that has to deal with this format.

    -MartinJ

  2. Doug McClean says:

    In regards to Jeff Richter’s comment, which I had been wondering about, what is meant by "normally"? Are there thread-safety concerns?

    Also, why expose the ASCIIEncoding class at all if it is just a means to implement Encoding and doesn’t broaden the interface? Couldn’t we just have the public static properties on Encoding instantiate and return classes that were private to mscorlib? Seems like that would eliminate any confusion and help create a pit of success.

  3. 小说 says:

    Good ,that is I had been wondering about.

  4. shawns [ms] says:

    Re: other encodings – To get other encodings, including EBCDIC encodings, call Encoding.GetEncoding() with the encoding name, such as ebcdic-cp-gb or IBM285. Encodings are primarily useful for legacy files, so there are no plans to extend the coverage to include new Encodings. Some encodings are reasonably trivial, but others have mutliple implimentations depending on the provider, so I’d recommend UTF-8 for interchange.

    Re: thread-safety. Encoding.ASCII or Encoding.GetEncoding() (without specifying a fallback in Whidbey) provides a reference to a single object. Encoding objects do not themselves have any state (unless you change the fallbacks in Whidbey). Encoding.GetBytes and Encoding.GetChars are thread safe if used without specifying alternate fallbacks.

    In Whidbey if you construct or clone an Encoding with a fallback, then you will have a new object, not a reference, and then it will continue to be thread safe unless you have multiple threads that change the Encoder/Decoder fallbacks.

    Once you have an Encoding, you can get an Encoder or Decoder from that Encoding, which do have state, and you’ll have to make sure to share them carefully if you use them from multiple threads

Skip to main content