Guía para la codificación de caracteres

1. Información general

En este tutorial, discutiremos los conceptos básicos de la codificación de caracteres y cómo lo manejamos en Java.

2. Importancia de la codificación de caracteres

A menudo tenemos que lidiar con textos pertenecientes a varios idiomas con escrituras diversas como el latín o el árabe. Todos los caracteres de todos los idiomas deben asignarse de alguna manera a un conjunto de unos y ceros. Realmente, es una maravilla que las computadoras puedan procesar correctamente todos nuestros idiomas.

Para hacer esto correctamente, debemos pensar en la codificación de caracteres. No hacerlo a menudo puede provocar la pérdida de datos e incluso vulnerabilidades de seguridad.

Para entender esto mejor, definamos un método para decodificar un texto en Java:

String decodeText(String input, String encoding) throws IOException { return new BufferedReader( new InputStreamReader( new ByteArrayInputStream(input.getBytes()), Charset.forName(encoding))) .readLine(); }

Tenga en cuenta que el texto de entrada que alimentamos aquí utiliza la codificación de plataforma predeterminada.

Si ejecutamos este método con una entrada como "El patrón de fachada es un patrón de diseño de software". y codificando como "US-ASCII" , generará:

The fa��ade pattern is a software design pattern.

Bueno, no es exactamente lo que esperábamos.

¿Qué pudo haber salido mal? Intentaremos comprender y corregir esto en el resto de este tutorial.

3. Fundamentos

Sin embargo, antes de profundizar, revisemos rápidamente tres términos: codificación , conjuntos de caracteres y punto de código .

3.1. Codificación

Las computadoras solo pueden comprender representaciones binarias como 1 y 0 . Procesar cualquier otra cosa requiere algún tipo de mapeo del texto del mundo real a su representación binaria. Este mapeo es lo que conocemos como codificación de caracteres o simplemente como codificación .

Por ejemplo, la primera letra de nuestro mensaje, "T", en US-ASCII se codifica como "01010100".

3.2. Conjuntos de caracteres

La asignación de caracteres a sus representaciones binarias puede variar mucho en términos de los caracteres que incluyen. El número de caracteres incluidos en un mapeo puede variar desde unos pocos hasta todos los caracteres en el uso práctico. El conjunto de caracteres que se incluyen en una definición de mapeo se denomina formalmente conjunto de caracteres .

Por ejemplo, ASCII tiene un juego de caracteres de 128 caracteres.

3.3. Punto de código

Un punto de código es una abstracción que separa un carácter de su codificación real. Un punto de código es una referencia entera a un carácter en particular.

Podemos representar el entero en sí mismo en decimal simple o en bases alternas como hexadecimal u octal. Usamos bases alternativas para facilitar la referencia de grandes números.

Por ejemplo, la primera letra de nuestro mensaje, T, en Unicode tiene un punto de código “U + 0054” (o 84 en decimal).

4. Comprensión de los esquemas de codificación

Una codificación de caracteres puede adoptar varias formas dependiendo del número de caracteres que codifica.

El número de caracteres codificados tiene una relación directa con la longitud de cada representación, que normalmente se mide como el número de bytes. Tener más caracteres para codificar significa esencialmente necesitar representaciones binarias más largas.

Repasemos algunos de los esquemas de codificación más populares en la práctica hoy.

4.1. Codificación de un solo byte

Uno de los primeros esquemas de codificación, llamado ASCII (Código estándar americano para el intercambio de información) utiliza un esquema de codificación de un solo byte. Esto esencialmente significa que cada carácter en ASCII se representa con números binarios de siete bits. ¡Esto todavía deja un poco libre en cada byte!

El conjunto de 128 caracteres de ASCII cubre los alfabetos ingleses en minúsculas y mayúsculas, dígitos y algunos caracteres especiales y de control.

Definamos un método simple en Java para mostrar la representación binaria de un carácter bajo un esquema de codificación particular:

String convertToBinary(String input, String encoding) throws UnsupportedEncodingException { byte[] encoded_input = Charset.forName(encoding) .encode(input) .array(); return IntStream.range(0, encoded_input.length) .map(i -> encoded_input[i]) .mapToObj(e -> Integer.toBinaryString(e ^ 255)) .map(e -> String.format("%1$" + Byte.SIZE + "s", e).replace(" ", "0")) .collect(Collectors.joining(" ")); }

Ahora, el carácter 'T' tiene un punto de código de 84 en US-ASCII (ASCII se conoce como US-ASCII en Java).

Y si usamos nuestro método de utilidad, podemos ver su representación binaria:

assertEquals(convertToBinary("T", "US-ASCII"), "01010100");

Esto, como esperábamos, es una representación binaria de siete bits para el carácter 'T'.

El ASCII original dejaba sin utilizar el bit más significativo de cada byte. Al mismo tiempo, ASCII había dejado una gran cantidad de caracteres sin representar, especialmente para idiomas distintos del inglés.

Esto llevó a un esfuerzo por utilizar ese bit no utilizado e incluir 128 caracteres adicionales.

Hubo varias variaciones del esquema de codificación ASCII propuestas y adoptadas a lo largo del tiempo. Estos vagamente se conocen como "extensiones ASCII".

Muchas de las extensiones ASCII tuvieron diferentes niveles de éxito, pero obviamente, esto no fue lo suficientemente bueno para una adopción más amplia, ya que muchos caracteres aún no estaban representados.

Una de las extensiones ASCII más populares fue ISO-8859-1 , también conocida como "ISO Latin 1".

4.2. Codificación de varios bytes

A medida que crecía la necesidad de acomodar más y más caracteres, los esquemas de codificación de un solo byte como ASCII no eran sostenibles.

Esto dio lugar a esquemas de codificación multibyte que tienen una capacidad mucho mejor, aunque a costa de mayores requisitos de espacio.

BIG5 y SHIFT-JIS son ejemplos de esquemas de codificación de caracteres multibyte que comenzaron a usar uno y dos bytes para representar conjuntos de caracteres más amplios . La mayoría de estos fueron creados para la necesidad de representar escrituras chinas y similares que tienen un número significativamente mayor de caracteres.

Ahora llamemos al método convertToBinary con una entrada como '語', un carácter chino y codificado como "Big5":

assertEquals(convertToBinary("語", "Big5"), "10111011 01111001");

El resultado anterior muestra que la codificación Big5 usa dos bytes para representar el carácter '語'.

La Autoridad de Números Internacionales mantiene una lista completa de codificaciones de caracteres, junto con sus alias.

5. Unicode

No es difícil comprender que, si bien la codificación es importante, la decodificación es igualmente vital para dar sentido a las representaciones. Esto solo es posible en la práctica si se usa ampliamente un esquema de codificación compatible o consistente.

Los diferentes esquemas de codificación desarrollados de forma aislada y practicados en geografías locales comenzaron a convertirse en un desafío.

Este desafío dio lugar a un estándar de codificación singular llamado Unicode que tiene capacidad para todos los caracteres posibles del mundo . ¡Esto incluye los personajes que están en uso e incluso los que ya no existen!

Well, that must require several bytes to store each character? Honestly yes, but Unicode has an ingenious solution.

Unicode as a standard defines code points for every possible character in the world. The code point for character ‘T' in Unicode is 84 in decimal. We generally refer to this as “U+0054” in Unicode which is nothing but U+ followed by the hexadecimal number.

We use hexadecimal as the base for code points in Unicode as there are 1,114,112 points, which is a pretty large number to communicate conveniently in decimal!

How these code points are encoded into bits is left to specific encoding schemes within Unicode. We will cover some of these encoding schemes in the sub-sections below.

5.1. UTF-32

UTF-32 is an encoding scheme for Unicode that employs four bytes to represent every code point defined by Unicode. Obviously, it is space inefficient to use four bytes for every character.

Let's see how a simple character like ‘T' is represented in UTF-32. We will use the method convertToBinary introduced earlier:

assertEquals(convertToBinary("T", "UTF-32"), "00000000 00000000 00000000 01010100");

The output above shows the usage of four bytes to represent the character ‘T' where the first three bytes are just wasted space.

5.2. UTF-8

UTF-8 is another encoding scheme for Unicode which employs a variable length of bytes to encode. While it uses a single byte to encode characters generally, it can use a higher number of bytes if needed, thus saving space.

Let's again call the method convertToBinary with input as ‘T' and encoding as “UTF-8”:

assertEquals(convertToBinary("T", "UTF-8"), "01010100");

The output is exactly similar to ASCII using just a single byte. In fact, UTF-8 is completely backward compatible with ASCII.

Let's again call the method convertToBinary with input as ‘語' and encoding as “UTF-8”:

assertEquals(convertToBinary("語", "UTF-8"), "11101000 10101010 10011110");

As we can see here UTF-8 uses three bytes to represent the character ‘語'. This is known as variable-width encoding.

UTF-8, due to its space efficiency, is the most common encoding used on the web.

6. Encoding Support in Java

Java supports a wide array of encodings and their conversions to each other. The class Charset defines a set of standard encodings which every implementation of Java platform is mandated to support.

This includes US-ASCII, ISO-8859-1, UTF-8, and UTF-16 to name a few. A particular implementation of Java may optionally support additional encodings.

There are some subtleties in the way Java picks up a charset to work with. Let's go through them in more details.

6.1. Default Charset

The Java platform depends heavily on a property called the default charset. The Java Virtual Machine (JVM) determines the default charset during start-up.

This is dependent on the locale and the charset of the underlying operating system on which JVM is running. For example on MacOS, the default charset is UTF-8.

Let's see how we can determine the default charset:

Charset.defaultCharset().displayName();

If we run this code snippet on a Windows machine the output we get:

windows-1252

Now, “windows-1252” is the default charset of the Windows platform in English, which in this case has determined the default charset of JVM which is running on Windows.

6.2. Who Uses the Default Charset?

Many of the Java APIs make use of the default charset as determined by the JVM. To name a few:

  • InputStreamReader and FileReader
  • OutputStreamWriter and FileWriter
  • Formatter and Scanner
  • URLEncoder and URLDecoder

So, this means that if we'd run our example without specifying the charset:

new BufferedReader(new InputStreamReader(new ByteArrayInputStream(input.getBytes()))).readLine();

then it would use the default charset to decode it.

And there are several APIs that make this same choice by default.

The default charset hence assumes an importance which we can not safely ignore.

6.3. Problems With the Default Charset

As we have seen that the default charset in Java is determined dynamically when the JVM starts. This makes the platform less reliable or error-prone when used across different operating systems.

For example, if we run

new BufferedReader(new InputStreamReader(new ByteArrayInputStream(input.getBytes()))).readLine();

on macOS, it will use UTF-8.

If we try the same snippet on Windows, it will use Windows-1252 to decode the same text.

Or, imagine writing a file on a macOS, and then reading that same file on Windows.

It's not difficult to understand that because of different encoding schemes, this may lead to data loss or corruption.

6.4. Can We Override the Default Charset?

The determination of the default charset in Java leads to two system properties:

  • file.encoding: The value of this system property is the name of the default charset
  • sun.jnu.encoding: The value of this system property is the name of the charset used when encoding/decoding file paths

Now, it's intuitive to override these system properties through command line arguments:

-Dfile.encoding="UTF-8" -Dsun.jnu.encoding="UTF-8"

However, it is important to note that these properties are read-only in Java. Their usage as above is not present in the documentation. Overriding these system properties may not have desired or predictable behavior.

Hence, we should avoid overriding the default charset in Java.

6.5. Why Is Java Not Solving This?

There is a Java Enhancement Proposal (JEP) which prescribes using “UTF-8” as the default charset in Java instead of basing it on locale and operating system charset.

This JEP is in a draft state as of now and when it (hopefully!) goes through it will solve most of the issues we discussed earlier.

Note that the newer APIs like those in java.nio.file.Files do not use the default charset. The methods in these APIs read or write character streams with charset as UTF-8 rather than the default charset.

6.6. Solving This Problem in Our Programs

We should normally choose to specify a charset when dealing with text instead of relying on the default settings. We can explicitly declare the encoding we want to use in classes which deal with character-to-byte conversions.

Luckily, our example is already specifying the charset. We just need to select the right one and let Java do the rest.

We should realize by now that accented characters like ‘ç' are not present in the encoding schema ASCII and hence we need an encoding which includes them. Perhaps, UTF-8?

Let's try that, we will now run the method decodeText with the same input but encoding as “UTF-8”:

The façade pattern is a software-design pattern.

Bingo! We can see the output we were hoping to see now.

Here we have set the encoding we think best suits our need in the constructor of InputStreamReader. This is usually the safest method of dealing with characters and byte conversions in Java.

Similarly, OutputStreamWriter and many other APIs supports setting an encoding scheme through their constructor.

6.7. MalformedInputException

When we decode a byte sequence, there exist cases in which it's not legal for the given Charset, or else it's not a legal sixteen-bit Unicode. In other words, the given byte sequence has no mapping in the specified Charset.

There are three predefined strategies (or CodingErrorAction) when the input sequence has malformed input:

  • IGNORE will ignore malformed characters and resume coding operation
  • REPLACE will replace the malformed characters in the output buffer and resume the coding operation
  • REPORT will throw a MalformedInputException

The default malformedInputAction for the CharsetDecoder is REPORT, and the default malformedInputAction of the default decoder in InputStreamReader is REPLACE.

Let's define a decoding function that receives a specified Charset, a CodingErrorAction type, and a string to be decoded:

String decodeText(String input, Charset charset, CodingErrorAction codingErrorAction) throws IOException { CharsetDecoder charsetDecoder = charset.newDecoder(); charsetDecoder.onMalformedInput(codingErrorAction); return new BufferedReader( new InputStreamReader( new ByteArrayInputStream(input.getBytes()), charsetDecoder)).readLine(); }

So, if we decode “The façade pattern is a software design pattern.” with US_ASCII, the output for each strategy would be different. First, we use CodingErrorAction.IGNORE which skips illegal characters:

Assertions.assertEquals( "The faade pattern is a software design pattern.", CharacterEncodingExamples.decodeText( "The façade pattern is a software design pattern.", StandardCharsets.US_ASCII, CodingErrorAction.IGNORE));

For the second test, we use CodingErrorAction.REPLACE that puts � instead of the illegal characters:

Assertions.assertEquals( "The fa��ade pattern is a software design pattern.", CharacterEncodingExamples.decodeText( "The façade pattern is a software design pattern.", StandardCharsets.US_ASCII, CodingErrorAction.REPLACE));

For the third test, we use CodingErrorAction.REPORT which leads to throwing MalformedInputException:

Assertions.assertThrows( MalformedInputException.class, () -> CharacterEncodingExamples.decodeText( "The façade pattern is a software design pattern.", StandardCharsets.US_ASCII, CodingErrorAction.REPORT));

7. Other Places Where Encoding Is Important

We don't just need to consider character encoding while programming. Texts can go wrong terminally at many other places.

The most common cause of problems in these cases is the conversion of text from one encoding scheme to another, thereby possibly introducing data loss.

Let's quickly go through a few places where we may encounter issues when encoding or decoding text.

7.1. Text Editors

In most of the cases, a text editor is where texts originate. There are numerous text editors in popular choice including vi, Notepad, and MS Word. Most of these text editors allow for us to select the encoding scheme. Hence, we should always make sure they are appropriate for the text we are handling.

7.2. File System

After we create texts in an editor, we need to store them in some file system. The file system depends on the operating system on which it is running. Most operating systems have inherent support for multiple encoding schemes. However, there may still be cases where an encoding conversion leads to data loss.

7.3. Network

Texts when transferred over a network using a protocol like File Transfer Protocol (FTP) also involve conversion between character encodings. For anything encoded in Unicode, it's safest to transfer over as binary to minimize the risk of loss in conversion. However, transferring text over a network is one of the less frequent causes of data corruption.

7.4. Databases

Most of the popular databases like Oracle and MySQL support the choice of the character encoding scheme at the installation or creation of databases. We must choose this in accordance with the texts we expect to store in the database. This is one of the more frequent places where the corruption of text data happens due to encoding conversions.

7.5. Browsers

Finally, in most web applications, we create texts and pass them through different layers with the intention to view them in a user interface, like a browser. Here as well it is imperative for us to choose the right character encoding which can display the characters properly. Most popular browsers like Chrome, Edge allow choosing the character encoding through their settings.

8. Conclusion

In this article, we discussed how encoding can be an issue while programming.

We further discussed the fundamentals including encoding and charsets. Moreover, we went through different encoding schemes and their uses.

We also picked up an example of incorrect character encoding usage in Java and saw how to get that right. Finally, we discussed some other common error scenarios related to character encoding.

Como siempre, el código de los ejemplos está disponible en GitHub.