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