Problemas al tratar de guardar y después recuperar una cadena de texto cifrada

[dec]

Hola,

Román, acabo de probar de nuevo como si no hubiésemos hablado nada, es decir, quitando del medio la codificación/decodificación en "base 64". En este caso no he tratado de mostrar la cadena en un Memo, pero, he querido guardarla en un archivo. Pero estamos en las mismas: la cadena que la DLL pasa al programa, por un motivo que desconozco, parece perderse en parte por el camino...

Sin embargo creo (estoy medio loco ya) comprender el asunto que tratáis de explicarme. Es decir, si yo cifro una cadena en Delphi y trato de guardarla en un archivo, estaré en la misma situación, de ahí que vosotros me sugiráis guardar la cadena en un archivo binario. De hecho acabo de probar a guardar la cadena recién cifrada en un "TStrings", y, de ahí a un archivo, y, en efecto, el problema es el mismo...

Ciertamente, comienzo a pensar que tal vez esto requiera de un planteamiento diferente. ¡Pero no tengo ni idea ahora mismo de cuál puede ser!

Si uno quiere hacer un programa cifrador/descifrador de cadenas... ¿cómo se supone que debe entregar la cadena cifrada al usuario para que este pueda guardarla donde más le plazca? ¿No podrá? ¿Entonces para qué demonios sirve el cifrador/descifrador? ¿Qué es lo que no estoy entendiendo bien?

[roman]

Un TStrings tampoco te sirve, es lo mismo que un TMemo a final de cuentas. Son clases pensadas para mostrar texto y cualquier información binaria se pierde. Usa streams.

// Saludos

[dec]

Hola a todos,

Empezado por roman

Un TStrings tampoco te sirve, es lo mismo que un TMemo a final de cuentas. Son clases pensadas para mostrar texto y cualquier información binaria se pierde. Usa streams.

// Saludos

Quizá aquí deba decirse que el programa "madre" o "host" en cuestión (no mi DLL, claro está) no conoce de tipos "stream". Sólo trabaja con enteros y cadenas. También algún tipo de "array", pero, no sabe lo que es un "stream" y por tanto no puedo "pasar" un "stream" como acaso sería lo suyo.

¿Nos vamos acercando?

[roman]

¡Ah! Caray. Pues, ¿que no estamos hablando de delphi? Si está en Object Pascal debe haber streams, o ¿qué no estoy entendiendo?

Por otro lado, no sé en los delphis actuales, pero en los antiguos no puedes pasar un string de dll a aplicación ni viceversa. Pero eso no debería ser problema. Conviertes a PChar antes de entregarla al programa host.

// Saludos

[dec]

Hola,

En efecto, el programa está hecho en Delphi (desde los tiempos de Turbo Pascal, si no me equivo) y es un programa estupendo: NeoBook. Este programa, en pocas palabras, es un IDE para "no programadores". Permite crear aplicaciones para Windows de una forma "visual" y muy sencilla, seleccionado las "acciones" que uno quiere llevar a cabo: leer un archivo, escribir un archivo, hacer una petición HTTP, cifrar cadenas...

El programa, es decir, el propio NeoBook, sí que entiende de "streams", por supuesto, pero, no los programas generados con NeoBook. Este NeoBook es el IDE y también el intérprete de las acciones que el usuario programe. Y dicho usuario cuenta con la posibilidad de usar variables simples (cadenas, numéricas) o definir algunos tipos de variables más avanzadas como "arrays", pero, no el tipo "stream" o alguno similar.

Además, en efecto, la DLL trabaja con PChar. Es el propio NeoBook el que, en su SDK (Software Development Kit), ofrece ciertas funciones para establecer "variables de NeoBook", obtener su valor, etc. Me quedo con el hecho claro de que las aplicaciones desarrolladas con NeoBook no soportan el tipo "stream", y tal vez por aquí deberíamos empezar a obtener una explicación a todo lo que está pasando, en lugar de tratar de codificar la cadena cifrada en "base 64".

Ahora bien, tal vez, por la propia naturaleza de NeoBook (esto se podría explicar así a los usuarios de mi DLL) el plugin necesariamente tenga que hacer esa codificación en "base 64", puesto que no es posible retornar la cadena cifrada tal cual en una cadena de texto. Pero superado este razonamiento que parece lógico y entendible, nos encontraríamos con la cifra mágica de 60.000 caracteres... es decir, en Delphi puedo cifrar y codificar en "base 64" cadenas de muchos más caracteres.

Y aquí estamos hablando de cadenas de texto... ¿por qué demonios, entonces, no podría la DLL hacer lo mismo que el programa de pruebas de Delphi (de hecho usan el mismo código) y enviar la cadena a NeoBook, tenga esta la longitud que tenga? Más aún, ¿por qué se corta inexplicablemente a los 60.000 caracteres exactos? Vale decir que he probado a enviar cadenas de este tamaño (pero sin codificar ni nada) y NeoBook parece recibirlas correctamente.

[[escafandra]]

Puedes pasar la cadena cifrada a una cadena hexadecimal, en ese caso tendrás siempre texto puro y tu cliente podrá hacer lo que quiera con esa cadena, siempre y cuando la convierta a binario antes de descifrarla.

Saludos.

[dec]

Hola a todos,

Empezado por escafandra

Puedes pasar la cadena cifrada a una cadena hexadecimal, en ese caso tendrás siempre texto puro y tu cliente podrá hacer lo que quiera con esa cadena, siempre y cuando la convierta a binario antes de descifrarla.

Saludos.

Gracias escafandra. No sé si querrás decir que puede usarse otra cosa que no sea "base 64". En efecto, yo también lo he pensado, aunque, no había pensado en la solución que tú propones. De hecho podría ser una solución (si funciona), puesto que, digo yo, el usuario podrá pasarme esa cadena... y ser yo el encargado de convertirla a otra cosa. Pero no creas que tengo claro ahora mismo cómo hacerlo...

Por cierto, acabo de comprobar que, en efecto, una DLL puede pasar a NeoBook cadenas de mucho mayor tamaño que 60.000 caracteres. He cargado un archivo de texto mucho mayor en un "TStrings", lo he asignado a una variable de NeoBook (tal como se hace con la cadena codificada en "base 64") y la aplicación de NeoBook recibe dicha variable y puede a su vez guardarla en un archivo sin pérdidas de ningún tipo.

¿Qué está pasando aquí?

[[escafandra]]

Pasa a tu dll un buffer y su tamaño, es decir, un puntero al primer elemento de tu String y su tamaño, de esa forma probablemente no tendrás errores.


Saludos.