|
|
|
@ -858,7 +858,7 @@ Encodings and Unicode |
|
|
|
--------------------- |
|
|
|
|
|
|
|
Strings are stored internally as sequences of code points in |
|
|
|
range ``0x0``-``0x10FFFF``. (See :pep:`393` for |
|
|
|
range ``0x0``--``0x10FFFF``. (See :pep:`393` for |
|
|
|
more details about the implementation.) |
|
|
|
Once a string object is used outside of CPU and memory, endianness |
|
|
|
and how these arrays are stored as bytes become an issue. As with other |
|
|
|
@ -868,7 +868,7 @@ There are a variety of different text serialisation codecs, which are |
|
|
|
collectivity referred to as :term:`text encodings <text encoding>`. |
|
|
|
|
|
|
|
The simplest text encoding (called ``'latin-1'`` or ``'iso-8859-1'``) maps |
|
|
|
the code points 0-255 to the bytes ``0x0``-``0xff``, which means that a string |
|
|
|
the code points 0--255 to the bytes ``0x0``--``0xff``, which means that a string |
|
|
|
object that contains code points above ``U+00FF`` can't be encoded with this |
|
|
|
codec. Doing so will raise a :exc:`UnicodeEncodeError` that looks |
|
|
|
like the following (although the details of the error message may differ): |
|
|
|
@ -877,7 +877,7 @@ position 3: ordinal not in range(256)``. |
|
|
|
|
|
|
|
There's another group of encodings (the so called charmap encodings) that choose |
|
|
|
a different subset of all Unicode code points and how these code points are |
|
|
|
mapped to the bytes ``0x0``-``0xff``. To see how this is done simply open |
|
|
|
mapped to the bytes ``0x0``--``0xff``. To see how this is done simply open |
|
|
|
e.g. :file:`encodings/cp1252.py` (which is an encoding that is used primarily on |
|
|
|
Windows). There's a string constant with 256 characters that shows you which |
|
|
|
character is mapped to which byte value. |
|
|
|
|