diff --git a/samples/snippets/cpp/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/CPP/isprops.cpp b/samples/snippets/cpp/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/CPP/isprops.cpp index f8ae5f7d459..ebf4fb0df75 100644 --- a/samples/snippets/cpp/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/CPP/isprops.cpp +++ b/samples/snippets/cpp/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/CPP/isprops.cpp @@ -167,7 +167,6 @@ CodePage identifier and name BrDisp BrSave MNDisp MNSave 1-Byte Re 57009 x-iscii-ma False False False False False True 57010 x-iscii-gu False False False False False True 57011 x-iscii-pa False False False False False True -65000 utf-7 False False True True False True 65001 utf-8 True True True True False True */ diff --git a/samples/snippets/csharp/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/CS/isprops.cs b/samples/snippets/csharp/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/CS/isprops.cs index 00b93e9077f..1c5db2fe5a8 100644 --- a/samples/snippets/csharp/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/CS/isprops.cs +++ b/samples/snippets/csharp/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/CS/isprops.cs @@ -169,7 +169,6 @@ 57008 x-iscii-ka False False False False False Tr 57009 x-iscii-ma False False False False False True 57010 x-iscii-gu False False False False False True 57011 x-iscii-pa False False False False False True -65000 utf-7 False False True True False True 65001 utf-8 True True True True False True */ diff --git a/samples/snippets/visualbasic/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/VB/isprops.vb b/samples/snippets/visualbasic/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/VB/isprops.vb index 9e3c9617230..a85ea61aaa8 100644 --- a/samples/snippets/visualbasic/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/VB/isprops.vb +++ b/samples/snippets/visualbasic/VS_Snippets_CLR_System/system.Text.Encoding.IsProps/VB/isprops.vb @@ -170,7 +170,6 @@ End Class '57009 x-iscii-ma False False False False False True '57010 x-iscii-gu False False False False False True '57011 x-iscii-pa False False False False False True -'65000 utf-7 False False True True False True '65001 utf-8 True True True True False True ' ' diff --git a/xml/System.Text/Encoding.xml b/xml/System.Text/Encoding.xml index b5799b5fea4..54d98e9e40b 100644 --- a/xml/System.Text/Encoding.xml +++ b/xml/System.Text/Encoding.xml @@ -68,173 +68,176 @@ , see [Character Encoding in .NET](/dotnet/standard/base-types/character-encoding). - Note that is intended to operate on Unicode characters instead of arbitrary binary data, such as byte arrays. If you must encode arbitrary binary data into text, you should use a protocol such as uuencode, which is implemented by methods such as . +Encoding is the process of transforming a set of Unicode characters into a sequence of bytes. In contrast, decoding is the process of transforming a sequence of encoded bytes into a set of Unicode characters. For information about the Unicode Transformation Formats (UTFs) and other encodings supported by , see [Character Encoding in .NET](/dotnet/standard/base-types/character-encoding). - .NET provides the following implementations of the class to support current Unicode encodings and other encodings: +Note that is intended to operate on Unicode characters instead of arbitrary binary data, such as byte arrays. If you must encode arbitrary binary data into text, you should use a protocol such as uuencode, which is implemented by methods such as . -- encodes Unicode characters as single 7-bit ASCII characters. This encoding only supports character values between U+0000 and U+007F. Code page 20127. Also available through the property. +.NET provides the following implementations of the class to support current Unicode encodings and other encodings: -- encodes Unicode characters using the UTF-7 encoding. This encoding supports all Unicode character values. Code page 65000. Also available through the property. +- encodes Unicode characters as single 7-bit ASCII characters. This encoding only supports character values between U+0000 and U+007F. Code page 20127. Also available through the property. -- encodes Unicode characters using the UTF-8 encoding. This encoding supports all Unicode character values. Code page 65001. Also available through the property. +- encodes Unicode characters using the UTF-7 encoding. This encoding supports all Unicode character values. Code page 65000. Also available through the property. -- encodes Unicode characters using the UTF-16 encoding. Both little endian and big endian byte orders are supported. Also available through the property and the property. +- encodes Unicode characters using the UTF-8 encoding. This encoding supports all Unicode character values. Code page 65001. Also available through the property. -- encodes Unicode characters using the UTF-32 encoding. Both little endian (code page 12000) and big endian (code page 12001) byte orders are supported. Also available through the property. +- encodes Unicode characters using the UTF-16 encoding. Both little endian and big endian byte orders are supported. Also available through the property and the property. - The class is primarily intended to convert between different encodings and Unicode. Often one of the derived Unicode classes is the correct choice for your app. +- encodes Unicode characters using the UTF-32 encoding. Both little endian (code page 12000) and big endian (code page 12001) byte orders are supported. Also available through the property. - Use the method to obtain other encodings, and call the method to get a list of all encodings. +The class is primarily intended to convert between different encodings and Unicode. Often one of the derived Unicode classes is the correct choice for your app. - The following table lists the encodings supported by .NET Framework and .NET Core. It lists each encoding's code page number and the values of the encoding's and properties. A check mark in the **.NET Framework support** and **.NET Core support** columns indicates that the code page is natively supported by that .NET implementation, regardless of the underlying platform. For .NET Framework, the availability of other encodings listed in the table depends on the operating system. For .NET Core, other encodings are available by using the class or by deriving from the class. +Use the method to obtain other encodings, and call the method to get a list of all encodings. + +### List of encodings + +The following table lists the encodings supported by .NET. It lists each encoding's code page number and the values of the encoding's and properties. A check mark in the **.NET Framework support**, **.NET Core support**, or **.NET 5.0 and later support** column indicates that the code page is natively supported by that .NET implementation, regardless of the underlying platform. For .NET Framework, the availability of other encodings listed in the table depends on the operating system. For .NET Core and .NET 5.0 and later, other encodings are available by using the class or by deriving from the class. > [!NOTE] > Code pages whose property corresponds to an international standard do not necessarily comply in full with that standard. -|Code page|Name|Display name|.NET Framework support| .NET Core support | -|---------|----|------------|----------------------|-------------------| -|37|IBM037|IBM EBCDIC (US-Canada)||| -|437|IBM437|OEM United States||| -|500|IBM500|IBM EBCDIC (International)||| -|708|ASMO-708|Arabic (ASMO 708)||| -|720|DOS-720|Arabic (DOS)||| -|737|ibm737|Greek (DOS)||| -|775|ibm775|Baltic (DOS)||| -|850|ibm850|Western European (DOS)||| -|852|ibm852|Central European (DOS)||| -|855|IBM855|OEM Cyrillic||| -|857|ibm857|Turkish (DOS)||| -|858|IBM00858|OEM Multilingual Latin I||| -|860|IBM860|Portuguese (DOS)||| -|861|ibm861|Icelandic (DOS)||| -|862|DOS-862|Hebrew (DOS)||| -|863|IBM863|French Canadian (DOS)||| -|864|IBM864|Arabic (864)||| -|865|IBM865|Nordic (DOS)||| -|866|cp866|Cyrillic (DOS)||| -|869|ibm869|Greek, Modern (DOS)||| -|870|IBM870|IBM EBCDIC (Multilingual Latin-2)||| -|874|windows-874|Thai (Windows)||| -|875|cp875|IBM EBCDIC (Greek Modern)||| -|932|shift_jis|Japanese (Shift-JIS)||| -|936|gb2312|Chinese Simplified (GB2312)|✓|| -|949|ks_c_5601-1987|Korean||| -|950|big5|Chinese Traditional (Big5)||| -|1026|IBM1026|IBM EBCDIC (Turkish Latin-5)||| -|1047|IBM01047|IBM Latin-1||| -|1140|IBM01140|IBM EBCDIC (US-Canada-Euro)||| -|1141|IBM01141|IBM EBCDIC (Germany-Euro)||| -|1142|IBM01142|IBM EBCDIC (Denmark-Norway-Euro)||| -|1143|IBM01143|IBM EBCDIC (Finland-Sweden-Euro)||| -|1144|IBM01144|IBM EBCDIC (Italy-Euro)||| -|1145|IBM01145|IBM EBCDIC (Spain-Euro)||| -|1146|IBM01146|IBM EBCDIC (UK-Euro)||| -|1147|IBM01147|IBM EBCDIC (France-Euro)||| -|1148|IBM01148|IBM EBCDIC (International-Euro)||| -|1149|IBM01149|IBM EBCDIC (Icelandic-Euro)||| -|1200|utf-16|Unicode|✓|✓| -|1201|unicodeFFFE|Unicode (Big endian)|✓|✓| -|1250|windows-1250|Central European (Windows)||| -|1251|windows-1251|Cyrillic (Windows)||| -|1252|Windows-1252|Western European (Windows)|✓|| -|1253|windows-1253|Greek (Windows)||| -|1254|windows-1254|Turkish (Windows)||| -|1255|windows-1255|Hebrew (Windows)||| -|1256|windows-1256|Arabic (Windows)||| -|1257|windows-1257|Baltic (Windows)||| -|1258|windows-1258|Vietnamese (Windows)||| -|1361|Johab|Korean (Johab)||| -|10000|macintosh|Western European (Mac)||| -|10001|x-mac-japanese|Japanese (Mac)||| -|10002|x-mac-chinesetrad|Chinese Traditional (Mac)||| -|10003|x-mac-korean|Korean (Mac)|✓|| -|10004|x-mac-arabic|Arabic (Mac)||| -|10005|x-mac-hebrew|Hebrew (Mac)||| -|10006|x-mac-greek|Greek (Mac)||| -|10007|x-mac-cyrillic|Cyrillic (Mac)||| -|10008|x-mac-chinesesimp|Chinese Simplified (Mac)|✓|| -|10010|x-mac-romanian|Romanian (Mac)||| -|10017|x-mac-ukrainian|Ukrainian (Mac)||| -|10021|x-mac-thai|Thai (Mac)||| -|10029|x-mac-ce|Central European (Mac)||| -|10079|x-mac-icelandic|Icelandic (Mac)||| -|10081|x-mac-turkish|Turkish (Mac)||| -|10082|x-mac-croatian|Croatian (Mac)||| -|12000|utf-32|Unicode (UTF-32)|✓|✓| -|12001|utf-32BE|Unicode (UTF-32 Big endian)|✓|✓| -|20000|x-Chinese-CNS|Chinese Traditional (CNS)||| -|20001|x-cp20001|TCA Taiwan||| -|20002|x-Chinese-Eten|Chinese Traditional (Eten)||| -|20003|x-cp20003|IBM5550 Taiwan||| -|20004|x-cp20004|TeleText Taiwan||| -|20005|x-cp20005|Wang Taiwan||| -|20105|x-IA5|Western European (IA5)||| -|20106|x-IA5-German|German (IA5)||| -|20107|x-IA5-Swedish|Swedish (IA5)||| -|20108|x-IA5-Norwegian|Norwegian (IA5)||| -|20127|us-ascii|US-ASCII|✓|✓| -|20261|x-cp20261|T.61||| -|20269|x-cp20269|ISO-6937||| -|20273|IBM273|IBM EBCDIC (Germany)||| -|20277|IBM277|IBM EBCDIC (Denmark-Norway)||| -|20278|IBM278|IBM EBCDIC (Finland-Sweden)||| -|20280|IBM280|IBM EBCDIC (Italy)||| -|20284|IBM284|IBM EBCDIC (Spain)||| -|20285|IBM285|IBM EBCDIC (UK)||| -|20290|IBM290|IBM EBCDIC (Japanese katakana)||| -|20297|IBM297|IBM EBCDIC (France)||| -|20420|IBM420|IBM EBCDIC (Arabic)||| -|20423|IBM423|IBM EBCDIC (Greek)||| -|20424|IBM424|IBM EBCDIC (Hebrew)||| -|20833|x-EBCDIC-KoreanExtended|IBM EBCDIC (Korean Extended)||| -|20838|IBM-Thai|IBM EBCDIC (Thai)||| -|20866|koi8-r|Cyrillic (KOI8-R)||| -|20871|IBM871|IBM EBCDIC (Icelandic)||| -|20880|IBM880|IBM EBCDIC (Cyrillic Russian)||| -|20905|IBM905|IBM EBCDIC (Turkish)||| -|20924|IBM00924|IBM Latin-1||| -|20932|EUC-JP|Japanese (JIS 0208-1990 and 0212-1990)||| -|20936|x-cp20936|Chinese Simplified (GB2312-80)|✓|| -|20949|x-cp20949|Korean Wansung|✓|| -|21025|cp1025|IBM EBCDIC (Cyrillic Serbian-Bulgarian)||| -|21866|koi8-u|Cyrillic (KOI8-U)||| -|28591|iso-8859-1|Western European (ISO)|✓|✓| -|28592|iso-8859-2|Central European (ISO)||| -|28593|iso-8859-3|Latin 3 (ISO)||| -|28594|iso-8859-4|Baltic (ISO)||| -|28595|iso-8859-5|Cyrillic (ISO)||| -|28596|iso-8859-6|Arabic (ISO)||| -|28597|iso-8859-7|Greek (ISO)||| -|28598|iso-8859-8|Hebrew (ISO-Visual)|✓|| -|28599|iso-8859-9|Turkish (ISO)||| -|28603|iso-8859-13|Estonian (ISO)||| -|28605|iso-8859-15|Latin 9 (ISO)||| -|29001|x-Europa|Europa||| -|38598|iso-8859-8-i|Hebrew (ISO-Logical)|✓|| -|50220|iso-2022-jp|Japanese (JIS)|✓|| -|50221|csISO2022JP|Japanese (JIS-Allow 1 byte Kana)|✓|| -|50222|iso-2022-jp|Japanese (JIS-Allow 1 byte Kana - SO/SI)|✓|| -|50225|iso-2022-kr|Korean (ISO)|✓|| -|50227|x-cp50227|Chinese Simplified (ISO-2022)|✓|| -|51932|euc-jp|Japanese (EUC)|✓|| -|51936|EUC-CN|Chinese Simplified (EUC)|✓|| -|51949|euc-kr|Korean (EUC)|✓|| -|52936|hz-gb-2312|Chinese Simplified (HZ)|✓|| -|54936|GB18030|Chinese Simplified (GB18030)|✓|| -|57002|x-iscii-de|ISCII Devanagari|✓|| -|57003|x-iscii-be|ISCII Bengali|✓|| -|57004|x-iscii-ta|ISCII Tamil|✓|| -|57005|x-iscii-te|ISCII Telugu|✓|| -|57006|x-iscii-as|ISCII Assamese|✓|| -|57007|x-iscii-or|ISCII Oriya|✓|| -|57008|x-iscii-ka|ISCII Kannada|✓|| -|57009|x-iscii-ma|ISCII Malayalam|✓|| -|57010|x-iscii-gu|ISCII Gujarati|✓|| -|57011|x-iscii-pa|ISCII Punjabi|✓|| -|65000|utf-7|Unicode (UTF-7)|✓|✓| -|65001|utf-8|Unicode (UTF-8)|✓|✓| +|Code page|Name|Display name|.NET Framework support| .NET Core support | .NET 5.0 and later support | +|---------|----|------------|----------------------|-------------------|----------------------------| +|37|IBM037|IBM EBCDIC (US-Canada)|||| +|437|IBM437|OEM United States|||| +|500|IBM500|IBM EBCDIC (International)|||| +|708|ASMO-708|Arabic (ASMO 708)|||| +|720|DOS-720|Arabic (DOS)|||| +|737|ibm737|Greek (DOS)|||| +|775|ibm775|Baltic (DOS)|||| +|850|ibm850|Western European (DOS)|||| +|852|ibm852|Central European (DOS)|||| +|855|IBM855|OEM Cyrillic|||| +|857|ibm857|Turkish (DOS)|||| +|858|IBM00858|OEM Multilingual Latin I|||| +|860|IBM860|Portuguese (DOS)|||| +|861|ibm861|Icelandic (DOS)|||| +|862|DOS-862|Hebrew (DOS)|||| +|863|IBM863|French Canadian (DOS)|||| +|864|IBM864|Arabic (864)|||| +|865|IBM865|Nordic (DOS)|||| +|866|cp866|Cyrillic (DOS)|||| +|869|ibm869|Greek, Modern (DOS)|||| +|870|IBM870|IBM EBCDIC (Multilingual Latin-2)|||| +|874|windows-874|Thai (Windows)|||| +|875|cp875|IBM EBCDIC (Greek Modern)|||| +|932|shift_jis|Japanese (Shift-JIS)|||| +|936|gb2312|Chinese Simplified (GB2312)|✓||| +|949|ks_c_5601-1987|Korean|||| +|950|big5|Chinese Traditional (Big5)|||| +|1026|IBM1026|IBM EBCDIC (Turkish Latin-5)|||| +|1047|IBM01047|IBM Latin-1|||| +|1140|IBM01140|IBM EBCDIC (US-Canada-Euro)|||| +|1141|IBM01141|IBM EBCDIC (Germany-Euro)|||| +|1142|IBM01142|IBM EBCDIC (Denmark-Norway-Euro)|||| +|1143|IBM01143|IBM EBCDIC (Finland-Sweden-Euro)|||| +|1144|IBM01144|IBM EBCDIC (Italy-Euro)|||| +|1145|IBM01145|IBM EBCDIC (Spain-Euro)|||| +|1146|IBM01146|IBM EBCDIC (UK-Euro)|||| +|1147|IBM01147|IBM EBCDIC (France-Euro)|||| +|1148|IBM01148|IBM EBCDIC (International-Euro)|||| +|1149|IBM01149|IBM EBCDIC (Icelandic-Euro)|||| +|1200|utf-16|Unicode|✓|✓|✓| +|1201|unicodeFFFE|Unicode (Big endian)|✓|✓|✓| +|1250|windows-1250|Central European (Windows)|||| +|1251|windows-1251|Cyrillic (Windows)|||| +|1252|Windows-1252|Western European (Windows)|✓|||| +|1253|windows-1253|Greek (Windows)|||| +|1254|windows-1254|Turkish (Windows)|||| +|1255|windows-1255|Hebrew (Windows)|||| +|1256|windows-1256|Arabic (Windows)|||| +|1257|windows-1257|Baltic (Windows)|||| +|1258|windows-1258|Vietnamese (Windows)|||| +|1361|Johab|Korean (Johab)|||| +|10000|macintosh|Western European (Mac)|||| +|10001|x-mac-japanese|Japanese (Mac)|||| +|10002|x-mac-chinesetrad|Chinese Traditional (Mac)|||| +|10003|x-mac-korean|Korean (Mac)|✓||| +|10004|x-mac-arabic|Arabic (Mac)|||| +|10005|x-mac-hebrew|Hebrew (Mac)|||| +|10006|x-mac-greek|Greek (Mac)|||| +|10007|x-mac-cyrillic|Cyrillic (Mac)|||| +|10008|x-mac-chinesesimp|Chinese Simplified (Mac)|✓||| +|10010|x-mac-romanian|Romanian (Mac)|||| +|10017|x-mac-ukrainian|Ukrainian (Mac)|||| +|10021|x-mac-thai|Thai (Mac)|||| +|10029|x-mac-ce|Central European (Mac)|||| +|10079|x-mac-icelandic|Icelandic (Mac)|||| +|10081|x-mac-turkish|Turkish (Mac)|||| +|10082|x-mac-croatian|Croatian (Mac)|||| +|12000|utf-32|Unicode (UTF-32)|✓|✓|✓| +|12001|utf-32BE|Unicode (UTF-32 Big endian)|✓|✓|✓| +|20000|x-Chinese-CNS|Chinese Traditional (CNS)|||| +|20001|x-cp20001|TCA Taiwan|||| +|20002|x-Chinese-Eten|Chinese Traditional (Eten)|||| +|20003|x-cp20003|IBM5550 Taiwan|||| +|20004|x-cp20004|TeleText Taiwan|||| +|20005|x-cp20005|Wang Taiwan|||| +|20105|x-IA5|Western European (IA5)|||| +|20106|x-IA5-German|German (IA5)|||| +|20107|x-IA5-Swedish|Swedish (IA5)|||| +|20108|x-IA5-Norwegian|Norwegian (IA5)|||| +|20127|us-ascii|US-ASCII|✓|✓|✓| +|20261|x-cp20261|T.61|||| +|20269|x-cp20269|ISO-6937|||| +|20273|IBM273|IBM EBCDIC (Germany)|||| +|20277|IBM277|IBM EBCDIC (Denmark-Norway)|||| +|20278|IBM278|IBM EBCDIC (Finland-Sweden)|||| +|20280|IBM280|IBM EBCDIC (Italy)|||| +|20284|IBM284|IBM EBCDIC (Spain)|||| +|20285|IBM285|IBM EBCDIC (UK)|||| +|20290|IBM290|IBM EBCDIC (Japanese katakana)|||| +|20297|IBM297|IBM EBCDIC (France)|||| +|20420|IBM420|IBM EBCDIC (Arabic)|||| +|20423|IBM423|IBM EBCDIC (Greek)|||| +|20424|IBM424|IBM EBCDIC (Hebrew)|||| +|20833|x-EBCDIC-KoreanExtended|IBM EBCDIC (Korean Extended)|||| +|20838|IBM-Thai|IBM EBCDIC (Thai)|||| +|20866|koi8-r|Cyrillic (KOI8-R)|||| +|20871|IBM871|IBM EBCDIC (Icelandic)|||| +|20880|IBM880|IBM EBCDIC (Cyrillic Russian)|||| +|20905|IBM905|IBM EBCDIC (Turkish)|||| +|20924|IBM00924|IBM Latin-1|||| +|20932|EUC-JP|Japanese (JIS 0208-1990 and 0212-1990)|||| +|20936|x-cp20936|Chinese Simplified (GB2312-80)|✓||| +|20949|x-cp20949|Korean Wansung|✓||| +|21025|cp1025|IBM EBCDIC (Cyrillic Serbian-Bulgarian)|||| +|21866|koi8-u|Cyrillic (KOI8-U)|||| +|28591|iso-8859-1|Western European (ISO)|✓|✓|✓| +|28592|iso-8859-2|Central European (ISO)|||| +|28593|iso-8859-3|Latin 3 (ISO)|||| +|28594|iso-8859-4|Baltic (ISO)|||| +|28595|iso-8859-5|Cyrillic (ISO)|||| +|28596|iso-8859-6|Arabic (ISO)|||| +|28597|iso-8859-7|Greek (ISO)|||| +|28598|iso-8859-8|Hebrew (ISO-Visual)|✓||| +|28599|iso-8859-9|Turkish (ISO)|||| +|28603|iso-8859-13|Estonian (ISO)|||| +|28605|iso-8859-15|Latin 9 (ISO)|||| +|29001|x-Europa|Europa|||| +|38598|iso-8859-8-i|Hebrew (ISO-Logical)|✓||| +|50220|iso-2022-jp|Japanese (JIS)|✓||| +|50221|csISO2022JP|Japanese (JIS-Allow 1 byte Kana)|✓||| +|50222|iso-2022-jp|Japanese (JIS-Allow 1 byte Kana - SO/SI)|✓||| +|50225|iso-2022-kr|Korean (ISO)|✓||| +|50227|x-cp50227|Chinese Simplified (ISO-2022)|✓||| +|51932|euc-jp|Japanese (EUC)|✓||| +|51936|EUC-CN|Chinese Simplified (EUC)|✓||| +|51949|euc-kr|Korean (EUC)|✓||| +|52936|hz-gb-2312|Chinese Simplified (HZ)|✓||| +|54936|GB18030|Chinese Simplified (GB18030)|✓||| +|57002|x-iscii-de|ISCII Devanagari|✓||| +|57003|x-iscii-be|ISCII Bengali|✓||| +|57004|x-iscii-ta|ISCII Tamil|✓||| +|57005|x-iscii-te|ISCII Telugu|✓||| +|57006|x-iscii-as|ISCII Assamese|✓||| +|57007|x-iscii-or|ISCII Oriya|✓||| +|57008|x-iscii-ka|ISCII Kannada|✓||| +|57009|x-iscii-ma|ISCII Malayalam|✓||| +|57010|x-iscii-gu|ISCII Gujarati|✓||| +|57011|x-iscii-pa|ISCII Punjabi|✓||| +|65000|utf-7|Unicode (UTF-7)|✓|✓|| +|65001|utf-8|Unicode (UTF-8)|✓|✓|✓| The following example calls the and methods to get the Greek (Windows) code page encoding. It compares the objects returned by the method calls to show that they are equal, and then maps displays the Unicode code point and the corresponding code page value for each character in the Greek alphabet. @@ -245,37 +248,35 @@ The UTF-16 and the UTF-32 encoders can use the big endian byte order (most significant byte first) or the little endian byte order (least significant byte first). For example, the Latin Capital Letter A (U+0041) is serialized as follows (in hexadecimal): -- UTF-16 big endian byte order: 00 41 +- UTF-16 big endian byte order: 00 41 -- UTF-16 little endian byte order: 41 00 +- UTF-16 little endian byte order: 41 00 -- UTF-32 big endian byte order: 00 00 00 41 +- UTF-32 big endian byte order: 00 00 00 41 -- UTF-32 little endian byte order: 41 00 00 00 +- UTF-32 little endian byte order: 41 00 00 00 It is generally more efficient to store Unicode characters using the native byte order. For example, it is better to use the little endian byte order on little endian platforms, such as Intel computers. The method retrieves an array of bytes that includes the byte order mark (BOM). If this byte array is prefixed to an encoded stream, it helps the decoder to identify the encoding format used. - For more information on byte order and the byte order mark, see The Unicode Standard at the [Unicode home page](https://go.microsoft.com/fwlink/?LinkId=37123). + For more information on byte order and the byte order mark, see The Unicode Standard at the [Unicode home page](https://home.unicode.org/). Note that the encoding classes allow errors to: -- Silently change to a "?" character. +- Silently change to a "?" character. -- Use a "best fit" character. +- Use a "best fit" character. -- Change to an application-specific behavior through use of the and classes with the U+FFFD Unicode replacement character. +- Change to an application-specific behavior through use of the and classes with the U+FFFD Unicode replacement character. You should throw an exception on any data stream error. An app either uses a "throwonerror" flag when applicable or uses the and classes. Best fit fallback is often not recommended because it can cause data loss or confusion and is slower than simple character replacements. For ANSI encodings, the best fit behavior is the default. - - - + ## Examples The following example converts a string from one encoding to another. > [!NOTE] -> The byte[] array is the only type in this example that contains the encoded data. The .NET Char and String types are themselves Unicode, so the call decodes the data back to Unicode. +> The `byte[]` array is the only type in this example that contains the encoded data. The .NET `Char` and `String` types are themselves Unicode, so the call decodes the data back to Unicode. :::code language="cpp" source="~/samples/snippets/cpp/VS_Snippets_CLR_System/system.Text.Encoding.Convert Example/CPP/convert.cpp" id="Snippet1"::: :::code language="csharp" source="~/samples/snippets/csharp/VS_Snippets_CLR_System/system.Text.Encoding.Convert Example/CS/convert.cs" interactive="try-dotnet" id="Snippet1"::: @@ -511,19 +512,17 @@ When selecting the ASCII encoding for your app, consider the following: -- The ASCII encoding is usually appropriate for protocols that require ASCII. +- The ASCII encoding is usually appropriate for protocols that require ASCII. -- If you requires 8-bit encoding (which is sometimes incorrectly referred to as "ASCII"), the UTF-8 encoding is recommended over the ASCII encoding. For the characters 0-7F, the results are identical, but use of UTF-8 avoids data loss by allowing representation of all Unicode characters that are representable. Note that the ASCII encoding has an 8th bit ambiguity that can allow malicious use, but the UTF-8 encoding removes ambiguity about the 8th bit. +- If you requires 8-bit encoding (which is sometimes incorrectly referred to as "ASCII"), the UTF-8 encoding is recommended over the ASCII encoding. For the characters 0-7F, the results are identical, but use of UTF-8 avoids data loss by allowing representation of all Unicode characters that are representable. Note that the ASCII encoding has an 8th bit ambiguity that can allow malicious use, but the UTF-8 encoding removes ambiguity about the 8th bit. -- Prior to the .NET Framework version 2.0, the .NET Framework allowed spoofing by ignoring the 8th bit. Beginning with the .NET Framework 2.0, non-ASCII code points fall back during decoding. +- Prior to .NET Framework version 2.0, .NET Framework allowed spoofing by ignoring the 8th bit. Beginning with .NET Framework 2.0, non-ASCII code points fall back during decoding. The object that is returned by this property might not have the appropriate behavior for your app. It uses replacement fallback to replace each string that it cannot encode and each byte that it cannot decode with a question mark ("?") character. Instead, you can call the method to instantiate an object whose fallback is either an or a , as the following example illustrates. [!code-csharp[System.Text.Encoding.ASCII#1](~/samples/snippets/csharp/VS_Snippets_CLR_System/system.text.encoding.ascii/cs/encoding.ascii2.cs#1)] [!code-vb[System.Text.Encoding.ASCII#1](~/samples/snippets/visualbasic/VS_Snippets_CLR_System/system.text.encoding.ascii/vb/encoding.ascii2.vb#1)] - - ## Examples The following example demonstrates the effect of the ASCII encoding on characters that are outside the ASCII range. @@ -588,9 +587,7 @@ [!code-vb[System.Text.Encoding.BigEndianUnicode#2](~/samples/snippets/visualbasic/VS_Snippets_CLR_System/system.Text.Encoding.BigEndianUnicode/VB/bigendianunicode1.vb#2)] The returned object has , , and properties, which yield the name "unicodeFFFE". Although the UTF-16 big endian byte order mark is hexadecimal FEFF, the name "unicodeFFFE" was chosen because the byte order mark appears as hexadecimal FFFE on little endian Windows computers. - - - + ## Examples The following example reads a text file with a UTF-16 encoding using the big endian byte order. @@ -660,8 +657,6 @@ In some cases, the value of the property corresponds to the international standard that defines that encoding. This doesn't mean that the implementation complies in full with that standard. - - ## Examples The following example retrieves the different names for each encoding and displays the encodings with one or more names that are different from . It displays but does not compare against it. @@ -1048,11 +1043,11 @@ ## Remarks The object represents an error handler that is invoked when an encoded byte sequence cannot be decoded into a character. Any one of the following handler types is supported: -- A best-fit fallback handler, which replaces bytes that cannot be decoded with some suitable replacement character. +- A best-fit fallback handler, which replaces bytes that cannot be decoded with some suitable replacement character. -- A replacement fallback handler, which replaces bytes that cannot be decoded with some arbitrary replacement character. .NET includes one replacement fallback handler, , which by default replaces bytes that cannot be decoded with a question mark ("?") character. +- A replacement fallback handler, which replaces bytes that cannot be decoded with some arbitrary replacement character. .NET includes one replacement fallback handler, , which by default replaces bytes that cannot be decoded with a question mark ("?") character. -- An exception fallback handler, which throws an exception when bytes cannot be decoded. .NET includes one exception fallback handler, , which throws a when bytes cannot be decoded. +- An exception fallback handler, which throws an exception when bytes cannot be decoded. .NET includes one exception fallback handler, , which throws a when bytes cannot be decoded. ]]> @@ -1115,11 +1110,11 @@ ## Remarks > [!WARNING] -> Different computers can use different encodings as the default, and the default encoding can change on a single computer. If you use the encoding to encode and decode data streamed between computers or retrieved at different times on the same computer, it may translate that data incorrectly. In addition, the encoding returned by the property uses best-fit fallback to map unsupported characters to characters supported by the code page. For these reasons, using the default encoding is not recommended. To ensure that encoded bytes are decoded properly, you should use a Unicode encoding, such as or . You could also use a higher-level protocol to ensure that the same format is used for encoding and decoding. +> Different computers can use different encodings as the default, and the default encoding can change on a single computer. If you use the encoding to encode and decode data streamed between computers or retrieved at different times on the same computer, it may translate that data incorrectly. In addition, the encoding returned by the property uses best-fit fallback to map unsupported characters to characters supported by the code page. For these reasons, using the default encoding is not recommended. To ensure that encoded bytes are decoded properly, you should use a Unicode encoding, such as or . You could also use a higher-level protocol to ensure that the same format is used for encoding and decoding. -### The Default property in the .NET Framework +### The Default property in .NET Framework -In the .NET Framework on the Windows desktop, the property always gets the system's active code page and creates a object that corresponds to it. The active code page may be an ANSI code page, which includes the ASCII character set along with additional characters that vary by code page. Because all encodings based on ANSI code pages lose data, consider using the encoding instead. UTF-8 is often identical in the U+00 to U+7F range, but can encode characters outside the ASCII range without loss. +In .NET Framework on the Windows desktop, the property always gets the system's active code page and creates a object that corresponds to it. The active code page may be an ANSI code page, which includes the ASCII character set along with additional characters that vary by code page. Because all encodings based on ANSI code pages lose data, consider using the encoding instead. UTF-8 is often identical in the U+00 to U+7F range, but can encode characters outside the ASCII range without loss. ## The Default property on .NET Core @@ -1181,11 +1176,11 @@ On .NET Core, the property always returns ## Remarks The object represents an error handler that is invoked when a character cannot be converted into an encoded byte sequence. Any one of the following handler types is supported: -- A best-fit fallback handler, which replaces characters that cannot be encoded with some suitable replacement character. +- A best-fit fallback handler, which replaces characters that cannot be encoded with some suitable replacement character. -- A replacement fallback handler, which replaces characters that cannot be encoded with some arbitrary replacement character. .NET includes one replacement fallback handler, , which by default replaces characters that cannot be encoded with a question mark ("?") character. +- A replacement fallback handler, which replaces characters that cannot be encoded with some arbitrary replacement character. .NET includes one replacement fallback handler, , which by default replaces characters that cannot be encoded with a question mark ("?") character. -- An exception fallback handler, which throws an exception when characters cannot be encoded. .NET includes one exception fallback handler, , which throws an when characters cannot be decoded. +- An exception fallback handler, which throws an exception when characters cannot be encoded. .NET includes one exception fallback handler, , which throws an when characters cannot be decoded. ]]> @@ -1239,8 +1234,6 @@ On .NET Core, the property always returns ## Remarks The property is intended for display. To find a name that can be passed to the method, use the property. - - ## Examples The following example retrieves the different names for each encoding and displays the encodings with one or more names that are different from . It displays but does not compare against it. @@ -1305,8 +1298,6 @@ On .NET Core, the property always returns ## Remarks Two instances of are considered equal if they correspond to the same code page and their `EncoderFallback` and `DecoderFallback` objects are equal. In particular, derived code pages all have a code page of 0 and their fallbacks are normally `null` (`Nothing` in Visual Basic .NET). Thus they are all considered equal to one another. One consequence is that when is used to populate a hash table, all derived encodings compare equal and fall into the same hash table slot. - - ## Examples The following example gets two instances of the same encoding (one by codepage and another by name), and checks their equality. @@ -1382,17 +1373,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. - -- If your app handles string inputs, you should use the string versions of the method. - -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. -- If your app must convert a large amount of data, you should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- If your app handles string inputs, you should use the string versions of the method. -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, you should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ## Examples The following example determines the number of bytes required to encode a character array, encodes the characters, and displays the resulting bytes. @@ -1459,11 +1448,12 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. -- If your app handles span of characters inputs, the span version of is recommended. +- If your app handles span of characters inputs, the span version of is recommended. + +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output span buffer is too small. For continuous encoding of a stream, this method is often the best choice. -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output span buffer is too small. For continuous encoding of a stream, this method is often the best choice. ]]> @@ -1520,17 +1510,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. - -- If your app handles string inputs, the string version of is recommended. +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app handles string inputs, the string version of is recommended. -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. - -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ## Examples The following example determines the number of bytes required to encode a string or a range in the string, encodes the characters, and displays the resulting bytes. @@ -1618,15 +1606,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some considerations for using these methods: -- Your app may need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. +- Your app may need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. -- If your app handles string inputs, you should use the string version of the method. +- If your app handles string inputs, you should use the string version of the method. -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ]]> @@ -1700,17 +1688,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. - -- If your app handles string inputs, the string version of is recommended. - -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- If your app handles string inputs, the string version of is recommended. -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ## Examples The following example determines the number of bytes required to encode three characters from a character array, encodes the characters, and displays the resulting bytes. @@ -1788,16 +1774,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. -- If your app handles string inputs, the string version of is recommended. +- If your app handles string inputs, the string version of is recommended. -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. - -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ## Examples The following example determines the number of bytes required to encode three characters from a character array, encodes the characters, and displays the resulting bytes. @@ -1872,17 +1857,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) - -- If your app handles string inputs, you should call the string version of the method. - -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- If your app handles string inputs, you should call the string version of the method. -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ## Examples The following example determines the number of bytes required to encode a character array, encodes the characters, and displays the resulting bytes. @@ -1957,17 +1940,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) -- If your app handles string inputs, you should use the string version of . +- If your app handles string inputs, you should use the string version of . -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. - -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. - -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ## Examples The following example determines the number of bytes required to encode a string or a range in the string, encodes the characters, and displays the resulting bytes. @@ -2036,13 +2017,13 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) -- If your app handles string inputs, you should use the string version of . +- If your app handles string inputs, you should use the string version of . -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ]]> @@ -2110,17 +2091,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) - -- If your app handles string inputs, you should use the string version of . +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app handles string inputs, you should use the string version of . -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. - -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ## Examples The following example determines the number of bytes required to encode three characters from a character array, encodes the characters, and displays the resulting bytes. @@ -2198,16 +2177,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) - -- If your app handles string inputs, you should use the string version of . +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app handles string inputs, you should use the string version of . -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ## Examples The following example determines the number of bytes required to encode a string or a range in the string, encodes the characters, and displays the resulting bytes. @@ -2291,15 +2269,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) -- If your app handles string inputs, you should use the string version of . +- If your app handles string inputs, you should use the string version of . -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ]]> @@ -2385,17 +2363,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) - -- If your app handles string inputs, you should use the string version of . +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app handles string inputs, you should use the string version of . -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. - -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ## Examples The following example determines the number of bytes required to encode three characters from a character array, encodes the characters, and displays the resulting bytes. @@ -2496,17 +2472,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) - -- If your app handles string inputs, you should use the string version of . - -- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- Your app might need to encode many input characters to a code page and process the characters using multiple calls. In this case, you probably need to maintain state between calls, taking into account the state that is persisted by the object being used. (For example, a character sequence that includes surrogate pairs might end with a high surrogate. The will remember that high surrogate so that it can be combined with a low surrogate at the beginning of a following call. won't be able to maintain the state, so the character will be sent to the .) -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- If your app handles string inputs, you should use the string version of . -- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. +- The Unicode character buffer version of allows some fast techniques, particularly with multiple calls using the object or inserting into existing buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports byte arrays is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible, and does throw an exception if the output buffer is too small. For continuous encoding of a stream, this method is often the best choice. ## Examples The following example determines the number of bytes required to encode a string or a range in the string, encodes the characters, and displays the resulting bytes. @@ -2607,17 +2581,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls. +- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls. -- If your app handles string outputs, you should use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. +- If your app handles string outputs, you should use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. -- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. - -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. - -- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. +- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. ## Examples The following example encodes a string into an array of bytes, and then decodes the bytes into an array of characters. @@ -2684,13 +2656,13 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls. +- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls. -- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. +- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. -- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. ]]> @@ -2761,15 +2733,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls. +- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls. -- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. +- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. -- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. -- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. ]]> @@ -2843,17 +2815,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls. - -- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. +- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls. -- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. - -- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. +- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. ## Examples The following example converts a string from one encoding to another. @@ -2955,17 +2925,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls, because byte sequences can be interrupted when processed in batches. (For example, part of an ISO-2022 shift sequence may end one call and continue at the beginning of the next call. will call the fallback for those incomplete sequences, but will remember those sequences for the next call.) - -- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. - -- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls, because byte sequences can be interrupted when processed in batches. (For example, part of an ISO-2022 shift sequence may end one call and continue at the beginning of the next call. will call the fallback for those incomplete sequences, but will remember those sequences for the next call.) -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. -- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. +- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. ## Examples The following example encodes a string into an array of bytes, and then decodes the bytes into an array of characters. @@ -3037,15 +3005,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls, because byte sequences can be interrupted when processed in batches. (For example, part of an ISO-2022 shift sequence may end one call and continue at the beginning of the next call. will call the fallback for those incomplete sequences, but will remember those sequences for the next call.) +- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls, because byte sequences can be interrupted when processed in batches. (For example, part of an ISO-2022 shift sequence may end one call and continue at the beginning of the next call. will call the fallback for those incomplete sequences, but will remember those sequences for the next call.) -- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. +- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. -- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. -- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. ]]> @@ -3112,17 +3080,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls, because byte sequences can be interrupted when processed in batches. (For example, part of an ISO-2022 shift sequence may end one call and continue at the beginning of the next call. will call the fallback for those incomplete sequences, but will remember those sequences for the next call.) - -- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. - -- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls, because byte sequences can be interrupted when processed in batches. (For example, part of an ISO-2022 shift sequence may end one call and continue at the beginning of the next call. will call the fallback for those incomplete sequences, but will remember those sequences for the next call.) -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- If your app handles string outputs, it is recommended to use the method. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. -- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. +- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. ## Examples The following example encodes a string into an array of bytes, and then decodes a range of the bytes into an array of characters. @@ -3228,15 +3194,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls, because byte sequences can be interrupted when processed in batches. (For example, part of an ISO-2022 shift sequence may end one call and continue at the beginning of the next call. will call the fallback for those incomplete sequences, but will remember those sequences for the next call.) +- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls, because byte sequences can be interrupted when processed in batches. (For example, part of an ISO-2022 shift sequence may end one call and continue at the beginning of the next call. will call the fallback for those incomplete sequences, but will remember those sequences for the next call.) -- If your app handles string outputs, the method is recommended. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. +- If your app handles string outputs, the method is recommended. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. -- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. -- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. ]]> @@ -3328,17 +3294,15 @@ On .NET Core, the property always returns Several versions of and are supported. The following are some programming considerations for use of these methods: -- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls, because byte sequences can be interrupted when processed in batches. (For example, part of an ISO-2022 shift sequence may end one call and continue at the beginning of the next call. will call the fallback for those incomplete sequences, but will remember those sequences for the next call.) +- Your app might need to decode multiple input bytes from a code page and process the bytes using multiple calls. In this case, you probably need to maintain state between calls, because byte sequences can be interrupted when processed in batches. (For example, part of an ISO-2022 shift sequence may end one call and continue at the beginning of the next call. will call the fallback for those incomplete sequences, but will remember those sequences for the next call.) -- If your app handles string outputs, the method is recommended. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. +- If your app handles string outputs, the method is recommended. Since this method must check string length and allocate a buffer, it is slightly slower, but the resulting type is to be preferred. -- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. - -- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. - -- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. +- The byte version of allows some fast techniques, particularly with multiple calls to large buffers. Bear in mind, however, that this method version is sometimes unsafe, since pointers are required. +- If your app must convert a large amount of data, it should reuse the output buffer. In this case, the version that supports output character buffers is the best choice. +- Consider using the method instead of . The conversion method converts as much data as possible and throws an exception if the output buffer is too small. For continuous decoding of a stream, this method is often the best choice. ## Examples The following example converts a string from one encoding to another. @@ -3552,7 +3516,7 @@ On .NET Core, the property always returns - The code page identifier of the preferred encoding. Possible values are listed in the Code Page column of the table that appears in the class topic. + The code page identifier of the preferred encoding. For a list of possible values, see . -or- @@ -3565,28 +3529,27 @@ On .NET Core, the property always returns ## Remarks The fallback handler depends on the encoding type of `codepage`. If `codepage` is a code page or double-byte character set (DBCS) encoding, a best-fit fallback handler is used. Otherwise, a replacement fallback handler is used. These fallback handlers may not be appropriate for your app. To specify the fallback handler used by the encoding specified by `codepage`, you can call the overload. - In the .NET Framework, the method relies on the underlying platform to support most code pages. However, the .NET Framework natively supports some encodings. For a list of code pages, see the class topic. In .NET Core, the method returns the encodings natively supported by .NET Core. On both .NET implementations, you can call the method to get an array of objects that contains information about all available encodings. + In .NET Framework, the method relies on the underlying platform to support most code pages. However, .NET Framework natively supports some encodings. For a list of code pages, see [List of encodings](/dotnet/api/system.text.encoding#list-of-encodings). In .NET Core, the method returns the encodings natively supported by .NET Core. On both .NET implementations, you can call the method to get an array of objects that contains information about all available encodings. - In addition to the encodings that are natively available on .NET Core or that are intrinsically supported on a specific platform version of the .NET Framework, the method returns any additional encodings that are made available by registering an object. If the same encoding has been registered by multiple objects, this method returns the last one registered. + In addition to the encodings that are natively available on .NET Core or that are intrinsically supported on a specific platform version of .NET Framework, the method returns any additional encodings that are made available by registering an object. If the same encoding has been registered by multiple objects, this method returns the last one registered. You can also supply a value of 0 for the `codepage` argument. Its precise behavior depends on whether any encodings have been made available by registering an object: - If one or more encoding providers have been registered, it returns the encoding of the last registered provider that has chosen to return a encoding when the method is passed a `codepage` argument of 0. -- On the .NET Framework, if no encoding provider has been registered, if the is the registered encoding provider, or if no registered encoding provider handles a `codepage` value of 0, it returns the operating system's active code page. To determine the active code page on Windows systems, call the Windows [GetACP](https://msdn.microsoft.com/library/windows/desktop/dd318070.aspx) function from the .NET Framework on the Windows desktop. +- On .NET Framework, if no encoding provider has been registered, if the is the registered encoding provider, or if no registered encoding provider handles a `codepage` value of 0, it returns the operating system's active code page. To determine the active code page on Windows systems, call the Windows [GetACP](/windows/win32/api/winnls/nf-winnls-getacp) function from .NET Framework on the Windows desktop. - On .NET Core, if no encoding provider has been registered or if no registered encoding provider handles a `codepage` value of 0, it returns the . > [!NOTE] -> Some unsupported code pages cause an to be thrown, whereas others cause a . Therefore, your code must catch all exceptions indicated in the Exceptions section. +> - Some unsupported code pages cause an to be thrown, whereas others cause a . Therefore, your code must catch all exceptions indicated in the Exceptions section. +> - In .NET 5.0 and later versions, the code page identifier `65000`, which represents UTF-7, is not supported. > [!NOTE] -> The ANSI code pages can be different on different computers and can change on a single computer, leading to data corruption. For this reason, if the active code page is an ANSI code page, encoding and decoding data using the default code page returned by `Encoding.GetEncoding(0)` is not recommended. For the most consistent results, you should use a Unicode encoding, such as UTF-8 (code page 65001) or UTF-16, instead of a specific code page. +> The ANSI code pages can be different on different computers and can change on a single computer, leading to data corruption. For this reason, if the active code page is an ANSI code page, encoding and decoding data using the default code page returned by `Encoding.GetEncoding(0)` is not recommended. For the most consistent results, you should use a Unicode encoding, such as UTF-8 (code page 65001) or UTF-16, instead of a specific code page. returns a cached instance with default settings. You should use the constructors of derived classes to get an instance with different settings. For example, the class provides a constructor that lets you enable error detection. - - ## Examples The following example gets two instances of the same encoding (one by code page and another by name), and checks their equality. @@ -3654,22 +3617,23 @@ You can also supply a value of 0 for the `codepage` argument. Its precise behavi - The code page name of the preferred encoding. Any value returned by the property is valid. Possible values are listed in the Name column of the table that appears in the class topic. + The code page name of the preferred encoding. Any value returned by the property is valid. For a list of possible values, see . Returns the encoding associated with the specified code page name. - The encoding associated with the specified code page. + The encoding associated with the specified code page. overload. -In the .NET Framework, the method relies on the underlying platform to support most code pages. However, the .NET Framework natively supports some encodings. For a list of code pages, see the class topic. In .NET Core, the method returns the encodings natively supported by .NET Core. On both .NET implementations, you can call the method to get an array of objects that contains information about all available encodings. +In .NET Framework, the method relies on the underlying platform to support most code pages. However, .NET Framework natively supports some encodings. For a list of code pages, see [List of encodings](/dotnet/api/system.text.encoding#list-of-encodings). In .NET Core, the method returns the encodings natively supported by .NET Core. On both .NET implementations, you can call the method to get an array of objects that contains information about all available encodings. - In addition to the encodings that are natively available on .NET Core or that are intrinsically supported on a specific platform version of the .NET Framework, the method returns any additional encodings that are made available by registering an object. If the same encoding has been registered by multiple objects, this method returns the last one registered. + In addition to the encodings that are natively available on .NET Core or that are intrinsically supported on a specific platform version of .NET Framework, the method returns any additional encodings that are made available by registering an object. If the same encoding has been registered by multiple objects, this method returns the last one registered. -> [!NOTE] -> The ANSI code pages can be different on different computers, or can be changed for a single computer, leading to data corruption. For the most consistent results, you should use Unicode, such as UTF-8 (code page 65001) or UTF-16, instead of a specific code page. +In .NET 5.0 and later versions, the code page name `utf-7` is not supported. +> [!NOTE] +> The ANSI code pages can be different on different computers, or they can be changed for a single computer, leading to data corruption. For the most consistent results, use Unicode, such as UTF-8 (code page 65001) or UTF-16, instead of a specific code page. returns a cached instance with default settings. You should use the constructors of derived classes to get an instance with different settings. For example, the class provides a constructor that lets you enable error detection. @@ -3739,7 +3703,7 @@ In the .NET Framework, the method rel - The code page identifier of the preferred encoding. Possible values are listed in the Code Page column of the table that appears in the class topic. + The code page identifier of the preferred encoding. For a list of possible values, see . -or- @@ -3754,29 +3718,28 @@ In the .NET Framework, the method rel ## Remarks > [!NOTE] -> Some unsupported code pages cause the exception to be thrown, whereas others cause . Therefore, your code must catch all exceptions indicated in the Exceptions section. +> - Some unsupported code pages cause the exception to be thrown, whereas others cause . Therefore, your code must catch all exceptions indicated in the Exceptions section. +> - In .NET 5.0 and later versions, the code page identifier `65000`, which represents UTF-7, is not supported. -In the .NET Framework, the method relies on the underlying platform to support most code pages. However, the .NET Framework natively supports some encodings. For a list of code pages, see the class topic. In .NET Core, the method returns the encodings natively supported by .NET Core. On both .NET implementations, you can call the method to get an array of objects that contains information about all available encodings. +In .NET Framework, the method relies on the underlying platform to support most code pages. However, .NET Framework natively supports some encodings. For a list of code pages, see [List of encodings](/dotnet/api/system.text.encoding#list-of-encodings). In .NET Core, the method returns the encodings natively supported by .NET Core. On both .NET implementations, you can call the method to get an array of objects that contains information about all available encodings. - In addition to the encodings that are natively available on .NET Core or that are intrinsically supported on a specific platform version of the .NET Framework, the method returns any additional encodings that are made available by registering an object. If the same encoding has been registered by multiple objects, this method returns the last one registered. + In addition to the encodings that are natively available on .NET Core or that are intrinsically supported on a specific platform version of .NET Framework, the method returns any additional encodings that are made available by registering an object. If the same encoding has been registered by multiple objects, this method returns the last one registered. You can also supply a value of 0 for the `codepage` argument. Its precise behavior depends on whether any encodings have been made available by registering an object: - If one or more encoding providers have been registered, it returns the encoding of the last registered provider that has chosen to return a encoding when the method is passed a `codepage` argument of 0. -- On the .NET Framework, if no encoding provider has been registered, if the is the registered encoding provider, or if no registered encoding provider handles a `codepage` value of 0, it returns the active code page. +- On .NET Framework, if no encoding provider has been registered, if the is the registered encoding provider, or if no registered encoding provider handles a `codepage` value of 0, it returns the active code page. - On .NET Core, if no encoding provider has been registered or if no registered encoding provider handles a `codepage` value of 0, it returns the encoding. > [!NOTE] -> The ANSI code pages can be different on different computers and can change on a single computer, leading to data corruption. For this reason, if the active code page is an ANSI code page, encoding and decoding data using the default code page returned by `Encoding.GetEncoding(0)` is not recommended. For the most consistent results, you should use Unicode, such as UTF-8 (code page 65001) or UTF-16, instead of a specific code page. +> The ANSI code pages can be different on different computers and can change on a single computer, leading to data corruption. For this reason, if the active code page is an ANSI code page, encoding and decoding data using the default code page returned by `Encoding.GetEncoding(0)` is not recommended. For the most consistent results, you should use Unicode, such as UTF-8 (code page 65001) or UTF-16, instead of a specific code page. - To get the encoding associated with the active code page, you can either supply a value of 0 for the `codepage` argument or, if your code is running on the .NET Framework on the Windows desktop, retrieve the value of the property. To determine the current active code page, call the Windows [GetACP](https://msdn.microsoft.com/library/windows/desktop/dd318070.aspx) function from the .NET Framework on the Windows desktop. + To get the encoding associated with the active code page, you can either supply a value of 0 for the `codepage` argument or, if your code is running on .NET Framework on the Windows desktop, retrieve the value of the property. To determine the current active code page, call the Windows [GetACP](/windows/win32/api/winnls/nf-winnls-getacp) function from .NET Framework on the Windows desktop. returns a cached instance with default settings. You should use the constructors of derived classes to get an instance with different settings. For example, the class provides a constructor that lets you enable error detection. - - ## Examples The following example demonstrates the method. @@ -3854,17 +3817,17 @@ You can also supply a value of 0 for the `codepage` argument. Its precise behavi ## Remarks -In the .NET Framework, the method relies on the underlying platform to support most code pages. However, the .NET Framework natively supports some encodings. For a list of code pages, see the class topic. In .NET Core, the method returns the encodings natively supported by .NET Core. On both .NET implementations, you can call the method to get an array of objects that contains information about all available encodings. +In .NET Framework, the method relies on the underlying platform to support most code pages. However, .NET Framework natively supports some encodings. For a list of code pages, see [List of encodings](/dotnet/api/system.text.encoding#list-of-encodings). In .NET Core, the method returns the encodings natively supported by .NET Core. On both .NET implementations, you can call the method to get an array of objects that contains information about all available encodings. - In addition to the encodings that are natively available on .NET Core or that are intrinsically supported on a specific platform version of the .NET Framework, the method returns any additional encodings that are made available by registering an object. If the same encoding has been registered by multiple objects, this method returns the last one registered. + In addition to the encodings that are natively available on .NET Core or that are intrinsically supported on a specific platform version of .NET Framework, the method returns any additional encodings that are made available by registering an object. If the same encoding has been registered by multiple objects, this method returns the last one registered. + +In .NET 5.0 and later versions, the code page name `utf-7` is not supported. > [!NOTE] -> The ANSI code pages can be different on different computers and can change on a single computer, leading to data corruption. For the most consistent results, you should use a Unicode encoding, such as UTF-8 (code page 65001) or UTF-16, instead of a specific code page. +> The ANSI code pages can be different on different computers and can change on a single computer, leading to data corruption. For the most consistent results, you should use a Unicode encoding, such as UTF-8 (code page 65001) or UTF-16, instead of a specific code page. returns a cached instance with default settings. You should use the constructors of derived classes to get an instance with different settings. For example, the class provides a constructor that lets you enable error detection. - - ## Examples The following example demonstrates the method. @@ -3926,21 +3889,19 @@ In the .NET Framework, the method rel class topic. + This method returns a list of supported encodings, uniquely distinguished by code page. For a table that lists the supported encodings, see . > [!NOTE] -> The list of supported encodings returned by the method does not include any additional encodings made available by any implementations that were registered by calls to the method. +> The list of supported encodings returned by the method does not include any additional encodings made available by any implementations that were registered by calls to the method. - On the .NET Framework, encodings 50220 and 50222 are both associated with the name "iso-2022-jp", but they are not identical. Encoding 50220 converts half-width Katakana characters to full-width Katakana characters, whereas encoding 50222 uses a shift-in/shift-out sequence to encode half-width Katakana characters. The display name for encoding 50222 is "Japanese (JIS-Allow 1 byte Kana - SO/SI)" to distinguish it from encoding 50220, which has the display name "Japanese (JIS)". + On .NET Framework, encodings 50220 and 50222 are both associated with the name "iso-2022-jp", but they are not identical. Encoding 50220 converts half-width Katakana characters to full-width Katakana characters, whereas encoding 50222 uses a shift-in/shift-out sequence to encode half-width Katakana characters. The display name for encoding 50222 is "Japanese (JIS-Allow 1 byte Kana - SO/SI)" to distinguish it from encoding 50220, which has the display name "Japanese (JIS)". - If you request the encoding name "iso-2022-jp", the .NET Framework returns encoding 50220. However, the encoding that is appropriate for your app depends on the preferred treatment of the half-width Katakana characters. + If you request the encoding name "iso-2022-jp", .NET Framework returns encoding 50220. However, the encoding that is appropriate for your app depends on the preferred treatment of the half-width Katakana characters. - To get a specific encoding, you should use the method. + To get a specific encoding, use the method. is sometimes used to present the user with a list of encodings in a File **Save as** dialog box. However, many non-Unicode encodings are either incomplete and translate many characters to "?", or have subtly different behavior on different platforms. Consider using UTF-8 or UTF-16 as the default. - - ## Examples The following example checks the values of the Boolean properties of each encoding. @@ -4056,9 +4017,7 @@ In the .NET Framework, the method rel Note that considers potential leftover surrogates from a previous decoder operation. Because of the decoder, passing a value of 1 to the method retrieves 2 for a single-byte encoding, such as ASCII. You should use the property if this information is necessary. > [!NOTE] -> `GetMaxByteCount(N)` is not necessarily the same value as `N* GetMaxByteCount(1)`. - - +> `GetMaxByteCount(N)` is not necessarily the same value as `N* GetMaxByteCount(1)`. ## Examples The following example determines the number of bytes required to encode a character array, encodes the characters, and displays the resulting bytes. @@ -4143,9 +4102,7 @@ In the .NET Framework, the method rel Note that considers the worst case for leftover bytes from a previous encoder operation. For most code pages, passing a value of 0 to this method retrieves values greater than or equal to 1. > [!NOTE] -> `GetMaxCharCount(N)` is not necessarily the same value as `N* GetMaxCharCount(1)`. - - +> `GetMaxCharCount(N)` is not necessarily the same value as `N* GetMaxCharCount(1)`. ## Examples The following example encodes a string into an array of bytes, and then decodes the bytes into an array of characters. @@ -4223,15 +4180,15 @@ In the .NET Framework, the method rel The Unicode byte order mark (BOM) is serialized as follows (in hexadecimal): -- UTF-8: EF BB BF +- UTF-8: EF BB BF -- UTF-16 big endian byte order: FE FF +- UTF-16 big endian byte order: FE FF -- UTF-16 little endian byte order: FF FE +- UTF-16 little endian byte order: FF FE -- UTF-32 big endian byte order: 00 00 FE FF +- UTF-32 big endian byte order: 00 00 FE FF -- UTF-32 little endian byte order: FF FE 00 00 +- UTF-32 little endian byte order: FF FE 00 00 You should use the BOM, because it provides nearly certain identification of an encoding for files that otherwise have lost reference to the object, for example, untagged or improperly tagged web data or random text files stored when a business did not have international concerns or other data. Often user problems might be avoided if data is consistently and properly tagged, preferably in UTF-8 or UTF-16. @@ -4239,12 +4196,10 @@ In the .NET Framework, the method rel There are some disadvantages to using a BOM. For example, knowing how to limit the database fields that use a BOM can be difficult. Concatenation of files can be a problem also, for example, when files are merged in such a way that an unnecessary character can end up in the middle of data. In spite of the few disadvantages, however, the use of a BOM is highly recommended. - For more information on byte order and the byte order mark, see The Unicode Standard at the [Unicode home page](https://go.microsoft.com/fwlink/?LinkId=37123). + For more information on byte order and the byte order mark, see The Unicode Standard at the [Unicode home page](https://home.unicode.org/). > [!CAUTION] -> To ensure that the encoded bytes are decoded properly, you should prefix encoded bytes with a preamble. However, most encodings do not provide a preamble. To ensure that the encoded bytes are decoded properly, you should use a Unicode encoding, that is, , , or , with a preamble. - - +> To ensure that the encoded bytes are decoded properly, you should prefix encoded bytes with a preamble. However, most encodings do not provide a preamble. To ensure that the encoded bytes are decoded properly, you should use a Unicode encoding, that is, , , or , with a preamble. ## Examples The following example determines the byte order of the encoding based on the preamble. @@ -4317,8 +4272,6 @@ In the .NET Framework, the method rel Note that the precise behavior of the method for a particular implementation depends on the fallback strategy defined for that object. For more information, see the "Choosing a Fallback Strategy" section of the [Character Encoding in .NET](/dotnet/standard/base-types/character-encoding) topic. - - ## Examples The following example reads a UTF-8 encoded string from a binary file represented by a object. For files that are smaller than 2,048 bytes, it reads the contents of the entire file into a byte array and calls the method to perform the decoding. For larger files, it reads 2,048 bytes at a time into a byte array, calls the method to determine how many characters are contained in the array, and then calls the method to perform the decoding. @@ -4327,7 +4280,7 @@ In the .NET Framework, the method rel The example uses the following text, which should be saved to a UTF-8 encoded file named Utf8Example.txt. -``` +```txt This is a UTF-8-encoded file that contains primarily Latin text, although it does list the first twelve letters of the Russian (Cyrillic) alphabet: @@ -4543,8 +4496,6 @@ The goal is to save this file, then open and decode it as a binary stream. See the Remarks section of the reference topic for a discussion of decoding techniques and considerations. - - ## Examples The following example reads a UTF-8 encoded string from a binary file that is represented by a object. For files that are smaller than 2,048 bytes, it reads the contents of the entire file into a byte array and calls the method to perform the decoding. For larger files, it reads 2,048 bytes at a time into a byte array, calls the method to determine how many characters are contained in the array, and then calls the method to perform the decoding. @@ -4553,7 +4504,7 @@ The goal is to save this file, then open and decode it as a binary stream. The example uses the following text, which should be saved to a UTF-8 encoded file named Utf8Example.txt. -``` +```txt This is a UTF-8-encoded file that contains primarily Latin text, although it does list the first twelve letters of the Russian (Cyrillic) alphabet: @@ -4636,8 +4587,6 @@ The goal is to save this file, then open and decode it as a binary stream. Note that returns the name to use to describe an encoding. The property defines a different encoding that might work better for an email application, for example. However, use of the property to define the encoding is not recommended. - - ## Examples The following example retrieves the different names for each encoding and displays the encodings with one or more names that are different from . It displays but does not compare against it. @@ -5077,9 +5026,7 @@ The goal is to save this file, then open and decode it as a binary stream. For a single-byte encoding, for example, , this property retrieves `true`. > [!CAUTION] -> You should be careful in what your application does with the value for . An assumption of how an Encoding will proceed may still be wrong. For example, Windows-1252 has a value of `true` for , but Encoding.GetMaxByteCount(1) returns 2. This is because the method considers potential leftover surrogates from a previous decoder operation. - - +> You should be careful in what your application does with the value for . An assumption of how an Encoding will proceed may still be wrong. For example, Windows-1252 has a value of `true` for , but Encoding.GetMaxByteCount(1) returns 2. This is because the method considers potential leftover surrogates from a previous decoder operation. ## Examples The following example checks the values of the Boolean properties of each encoding. @@ -5161,15 +5108,15 @@ The goal is to save this file, then open and decode it as a binary stream. The Unicode byte order mark (BOM) is serialized as follows (in hexadecimal): -- UTF-8: EF BB BF +- UTF-8: EF BB BF -- UTF-16 big endian byte order: FE FF +- UTF-16 big endian byte order: FE FF -- UTF-16 little endian byte order: FF FE +- UTF-16 little endian byte order: FF FE -- UTF-32 big endian byte order: 00 00 FE FF +- UTF-32 big endian byte order: 00 00 FE FF -- UTF-32 little endian byte order: FF FE 00 00 +- UTF-32 little endian byte order: FF FE 00 00 You should use the BOM, because it provides nearly certain identification of an encoding for files that otherwise have lost reference to the object, for example, untagged or improperly tagged web data or random text files stored when a business did not have international concerns or other data. Often user problems might be avoided if data is consistently and properly tagged, preferably in UTF-8 or UTF-16. @@ -5180,7 +5127,7 @@ The goal is to save this file, then open and decode it as a binary stream. For more information on byte order and the byte order mark, see The Unicode Standard at the [Unicode home page](https://home.unicode.org/). > [!CAUTION] -> To ensure that the encoded bytes are decoded properly, you should prefix encoded bytes with a preamble. However, most encodings do not provide a preamble. To ensure that the encoded bytes are decoded properly, you should use a Unicode encoding, that is, , , or , with a preamble. +> To ensure that the encoded bytes are decoded properly, you should prefix encoded bytes with a preamble. However, most encodings do not provide a preamble. To ensure that the encoded bytes are decoded properly, you should use a Unicode encoding, that is, , , or , with a preamble. ]]> @@ -5242,7 +5189,7 @@ Registering an encoding provider by using the method overloads is passed an argument of `0`. The provider can also choose to not return an encoding by having the method return `null`. -Starting with the .NET Framework 4.6, the .NET Framework includes one encoding provider, , that makes the encodings available that are present in the full .NET Framework but are not available in the Universal Windows Platform. By default, the Universal Windows Platform only supports the Unicode encodings, ASCII, and code page 28591. +Starting with .NET Framework 4.6, .NET Framework includes one encoding provider, , that makes the encodings available that are present in the full .NET Framework but are not available in the Universal Windows Platform. By default, the Universal Windows Platform only supports the Unicode encodings, ASCII, and code page 28591. If the same encoding provider is used in multiple calls to the method, only the first method call registers the provider. Subsequent calls are ignored. @@ -5304,15 +5251,12 @@ Starting with the .NET Framework 4.6, the .NET Framework includes one encoding p object that is returned by this property may not have the appropriate behavior for your app. It uses replacement fallback to replace each string that it cannot encode and each byte that it cannot decode with a question mark ("?") character. Instead, you can call the constructor to instantiate a little endian object whose fallback is either an or a , as the following example illustrates. [!code-csharp[System.Text.Encoding.Unicode#2](~/samples/snippets/csharp/VS_Snippets_CLR_System/system.text.encoding.unicode/cs/unicode1.cs#2)] [!code-vb[System.Text.Encoding.Unicode#2](~/samples/snippets/visualbasic/VS_Snippets_CLR_System/system.text.encoding.unicode/vb/unicode1.vb#2)] - - - ## Examples The following example determines the number of bytes required to encode a character array, encodes the characters, and displays the resulting bytes. @@ -5373,12 +5317,10 @@ Starting with the .NET Framework 4.6, the .NET Framework includes one encoding p [!code-csharp[System.Text.Encoding.UTF32#1](~/samples/snippets/csharp/VS_Snippets_CLR_System/system.text.encoding.utf32/cs/encoding.utf32.1.cs#1)] [!code-vb[System.Text.Encoding.UTF32#1](~/samples/snippets/visualbasic/VS_Snippets_CLR_System/system.text.encoding.utf32/vb/encoding.utf32.1.vb#1)] - For a discussion of little endian byte order, see the class topic. + For a discussion of little endian byte order, see . For information about the encodings supported by .NET and a discussion of which Unicode encoding to use, see [Character Encoding in .NET](/dotnet/standard/base-types/character-encoding). - - ## Examples The following example determines the number of bytes required to encode a character array, encodes the characters, and displays the resulting bytes. @@ -5436,9 +5378,7 @@ Starting with the .NET Framework 4.6, the .NET Framework includes one encoding p object that is returned by this property might not have the appropriate behavior for your app. -- It returns a object that provides a Unicode byte order mark (BOM). To instantiate a UTF8 encoding that doesn't provide a BOM, call any overload of the constructor. +- It returns a object that provides a Unicode byte order mark (BOM). To instantiate a UTF8 encoding that doesn't provide a BOM, call any overload of the constructor. -- It returns a object that uses replacement fallback to replace each string that it can't encode and each byte that it can't decode with a question mark ("?") character. Instead, you can call the constructor to instantiate a object whose fallback is either an or a , as the following example illustrates. +- It returns a object that uses replacement fallback to replace each string that it can't encode and each byte that it can't decode with a question mark ("?") character. Instead, you can call the constructor to instantiate a object whose fallback is either an or a , as the following example illustrates. :::code language="csharp" source="~/samples/snippets/csharp/VS_Snippets_CLR_System/system.text.encoding.utf8/cs/encoding.utf8.1.cs" interactive="try-dotnet" id="Snippet1"::: :::code language="vb" source="~/samples/snippets/visualbasic/VS_Snippets_CLR_System/system.text.encoding.utf8/vb/encoding.utf8.1.vb" id="Snippet1"::: - - ## Examples The following example defines an array that consists of the following characters: -- LATIN SMALL LETTER Z (U+007A) +- LATIN SMALL LETTER Z (U+007A) -- LATIN SMALL LETTER A (U+0061) +- LATIN SMALL LETTER A (U+0061) -- COMBINING BREVE (U+0306) +- COMBINING BREVE (U+0306) -- LATIN SMALL LETTER AE WITH ACUTE (U+01FD) +- LATIN SMALL LETTER AE WITH ACUTE (U+01FD) -- GREEK SMALL LETTER BETA (U+03B2) +- GREEK SMALL LETTER BETA (U+03B2) -- A surrogate pair (U+D800 U+DD54) that forms GREEK ACROPHONIC ATTIC ONE THOUSAND STATERS (U+10154). +- A surrogate pair (U+D800 U+DD54) that forms GREEK ACROPHONIC ATTIC ONE THOUSAND STATERS (U+10154). It displays the UTF-16 code units of each character and determines the number of bytes required by a UTF-8 encoder to encode the character array. It then encodes the characters and displays the resulting UTF-8-encoded bytes. @@ -5602,8 +5540,6 @@ Starting with the .NET Framework 4.6, the .NET Framework includes one encoding p The is the same as the returned by . Some of the web names are duplicates; see the remarks for for more information. - - ## Examples The following example includes the in an HTML header. @@ -5667,8 +5603,6 @@ Starting with the .NET Framework 4.6, the .NET Framework includes one encoding p ## Remarks This property is provided for compatibility with the Windows MultiLanguage (MLang) APIs, for example, in determining font families. For globalization, using one of the Unicode encodings is recommended instead. It is also recommended to use instead of to identify the code page. - - ## Examples The following example determines the Windows code page that most closely corresponds to each encoding.