Métodos de almacenamiento de la información: texto y binario

Ya hemos visto en muchas secciones anteriores que la misma información puede representarse en forma textual y binaria. Por ejemplo, los números de los formatos int, long y double, la fecha y la hora (datetime) y los colores (color) se almacenan en la memoria como una secuencia de bytes de una longitud determinada. Este método es compacto y es mejor para la interpretación informática, pero es más cómodo para la persona analizar la información en forma de texto, aunque lleva más tiempo. Por ello, prestamos mucha atención a convertir números en cadenas y viceversa, y a funciones para trabajar con cadenas.

A nivel de archivo también se conserva la división entre la representación binaria y textual de los datos. Un archivo binario está diseñado para almacenar datos en la misma representación interna que se utiliza en la memoria. El archivo de texto contiene una representación de cadena.

Los archivos de texto se utilizan habitualmente para formatos estándar como CSV (Comma Separated Values), JSON (JavaScript Object Notation), XML (Extensible Markup Language) y HTML (HyperText Markup Language).

Los archivos binarios, por supuesto, también tienen formatos estándar para muchas aplicaciones, en particular para imágenes (PNG, GIF, JPG, BMP), sonidos (WAV, MP3) o archivos comprimidos (ZIP). Sin embargo, el formato binario supone inicialmente una mayor protección y un trabajo de bajo nivel con los datos, por lo que se utiliza más a menudo para resolver problemas internos, cuando sólo son importantes la eficiencia del almacenamiento y la disponibilidad de los datos para un programa específico. En otras palabras: los objetos de cualquier estructura y clase aplicada pueden guardar y restaurar fácilmente su estado en un archivo binario, realizando de hecho una impresión de memoria y sin preocuparse por la compatibilidad con ningún estándar.

En teoría, podríamos convertir manualmente los datos en cadenas al escribir en un archivo binario y luego volver a convertirlos de cadenas a números (o estructuras, o arrays) al leer el archivo. Esto sería similar a lo que el modo de archivo de texto proporciona automáticamente, pero requeriría un esfuerzo adicional. El modo de archivo de texto nos ahorra dicha rutina. Además, el subsistema de archivos MQL5 realiza implícitamente varias operaciones opcionales pero importantes que son necesarias cuando se trabaja con texto.

En primer lugar, el concepto de texto se basa en algunas reglas generales de uso de caracteres delimitadores. En concreto, se supone que todos los textos están formados por cadenas. Así es más cómodo leerlos y analizarlos de forma algorítmica. Por lo tanto, hay caracteres especiales que separan una cadena de otra.

Aquí nos encontramos con las primeras dificultades asociadas al hecho de que los distintos sistemas operativos aceptan diferentes combinaciones de estos caracteres. En Windows, el separador de líneas es la secuencia de dos caracteres '\r\n' (ya sea como códigos hexadecimales, 0xD 0xA, o como el nombre CRLF, que significa Carriage Return and Line Feed). En Unix y Linux, el carácter único '\n' es el estándar, pero algunas versiones y programas bajo MacOS pueden utilizar el carácter único '\r'.

Aunque MetaTrader 5 funciona bajo Windows, no tenemos ninguna garantía de que cualquier archivo de texto resultante no se guardará con separadores inusuales. Si tuviéramos que leerlo en modo binario y comprobar nosotros mismos los delimitadores para formar cadenas, estas discrepancias requerirían un tratamiento específico. Aquí viene al rescate el modo de texto de operación de archivos en MQL5: normaliza automáticamente los saltos de línea al leer y escribir.

Es posible que MQL5 no corrija los saltos de línea en todos los casos. En particular, un único carácter '\r' no se interpretará como '\r\n' al leer un archivo de texto, mientras que un único '\n' se interpreta correctamente como '\r\n'.

En segundo lugar, las cadenas pueden almacenarse en memoria en múltiples representaciones. Por defecto, la cadena (tipo string) en MQL5 consta de caracteres de dos bytes. Esto ofrece compatibilidad para la codificación universal Unicode, lo que es bueno porque incluye scripts de todos los países. Sin embargo, en muchos casos no se requiere tal universalidad (por ejemplo, al almacenar números o mensajes en inglés), en cuyo caso es más eficiente utilizar cadenas de caracteres de un solo byte en la codificación ANSI. Las funciones de la API de MQL5 permiten elegir la forma preferida de escribir cadenas en modo texto en los archivos. Pero si controlamos la escritura en nuestro programa MQL, podemos garantizar la validez y fiabilidad del cambio de Unicode a caracteres de un solo byte. En este caso, cuando se integra con algún servicio web o software externo, la página de código ANSI en sus archivos puede ser cualquiera. A este respecto, se plantea la siguiente cuestión.

En tercer lugar, debido a la presencia de muchas lenguas diferentes, hay que estar preparado para textos en diversas codificaciones ANSI. Sin la interpretación correcta de la codificación, el texto se puede escribir o leer con distorsiones, o incluso volverse ilegible. Lo vimos en la sección Trabajar con símbolos y páginas de códigos. Por ello, las funciones de archivo ya incluyen medios para el correcto tratamiento de los caracteres: basta con especificar en los parámetros la codificación deseada o esperada. La elección de la codificación se describe con más detalle en una sección por separado.

Por último, el modo de texto es compatible con el conocido formato CSV. Dado que el trading suele requerir datos tabulares, CSV es muy adecuado para ello. En un archivo de texto en modo CSV, las funciones de la API de MQL5 procesan no sólo delimitadores para envolver las líneas de texto, sino también un delimitador adicional para el borde de las columnas (campos de cada fila de la tabla). Esto suele ser un tabulador '\t', una coma ',' o un punto y coma ';'. Por ejemplo, este es el aspecto de un archivo CSV con noticias de Forex (se muestra un fragmento separado por comas):

Y aquí está, para mayor claridad, en forma de tabla: