@@ -1554,7 +1554,7 @@ msgstr ""
1554
1554
"Las cadenas de caracteres se almacenan internamente como secuencias de puntos de "
1555
1555
"código en el rango ``0x0`` -- ``0x10FFFF``. (Consulte :pep:`393` para "
1556
1556
"obtener más detalles sobre la implementación.) Una vez que se utiliza un "
1557
- "objeto de cadena fuera de la CPU y la memoria, la *endianness* y cómo se "
1557
+ "objeto de cadena de caracteres fuera de la CPU y la memoria, la *endianness* y cómo se "
1558
1558
"almacenan estos conjuntos como bytes se convierte en un problema. Al igual "
1559
1559
"que con otros códecs, la serialización de una cadena en una secuencia de "
1560
1560
"bytes se conoce como *encoding*, y la recreación de la cadena a partir de la "
@@ -1646,7 +1646,7 @@ msgstr ""
1646
1646
"aparecer en un texto Unicode. Entonces, cuando el primer carácter en una "
1647
1647
"secuencia de bytes ``UTF-16`` o ``UTF-32`` parece ser un ``U+FFFE``, los "
1648
1648
"bytes deben intercambiarse en la decodificación. Desafortunadamente, el "
1649
- "carácter ``U+FEFF`` tenía un segundo propósito como ``ESPACIO SIN CIERRE DE "
1649
+ "carácter ``U+FEFF`` tenía un segundo propósito como ``ESPACIO SIN QUIEBRE DE "
1650
1650
"ANCHO CERO``: un carácter que no tiene ancho y no permite dividir una "
1651
1651
"palabra. Puede por ejemplo ser usado para dar pistas a un algoritmo de "
1652
1652
"ligadura. Con Unicode 4.0, el uso de ``U+FEFF`` como ``ESPACIO SIN QUIEBRE "
@@ -1731,8 +1731,7 @@ msgid ""
1731
1731
msgstr ""
1732
1732
"Como UTF-8 es una codificación de 8 bits, no se requiere una lista de "
1733
1733
"materiales y cualquier carácter ``U+FEFF`` en la cadena decodificada "
1734
- "(incluso si es el primer carácter) se trata como un ``ZERO WIDTH NO-BREAK "
1735
- "SPACE``."
1734
+ "(incluso si es el primer carácter) se trata como un `ESPACIO SIN QUIEBRE DE ANCHO CERO`` (*``ZERO WIDTH NO-BREAK SPACE``*)."
1736
1735
1737
1736
#: ../Doc/library/codecs.rst:945
1738
1737
msgid ""
0 commit comments