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

[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.

[dec]

Hola,

Empezado por 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.

No estoy seguro de que algo así pueda funcionar escafandra. Recordemos que el usuario sólo puede pasar a mi DLL una cadena de texto, no un "buffer" ni nada parecido. ¿O lo he entendido mal?

Por cierto que ya vamos acotando el asunto... he guardado en un archivo de texto unos 80.000 caracteres codificados en "base 64". Desde mi DLL leo dicho archivo (usando "TStrings") y asigno su contenido a una variable de NeoBook.

Pues bien, dicha variable se asigna correctamente... y la aplicación puede guardar su contenido a otro archivo de texto sin que se pierda nada en absoluto. Y ahora es cuando digo que creo haber acotado algo que no sé ni lo que es...

[[escafandra]]

En realidad un String no es otra cosa que un buffer y un tamaño...

Debes tener claro si quieres base64 u otra cosa. Cualquier otra cosa binaria puedes pasarla a su texto en hexadecimal... tu decides

Saludos

[dec]

Hola,

Empezado por escafandra

En realidad un String no es otra cosa que un buffer y un tamaño...

Debes tener claro si quieres base64 u otra cosa. Cualquier otra cosa binaria puedes pasarla a su texto en hexadecimal... tu decides

Saludos

Gracias escafandra. Te juro que no sé cómo hacer lo que me sugieres. Otrosí recordemos que yo recibo variables del tipo PChar y no de tipo String. No sé si esto implica algo.

Por lo demás, si os cuento lo que acabo de hacer no lo creéis. Como he dicho arriba, otra de mis DLL permite al usuario codificar y decodificar en "base 64". Ahora bien, esta DLL usa los componentes Indy para llevarlo a cabo.

Pues bien, he probado a codificar un archivo de texto en "base 64" con una de estas acciones, es decir, enviar al programa "madre" la cadena codificada (no cifrada) en "base 64", y, ¿y qué diréis que ha pasado? Exacto: no puedo enviar más de 60.000 caracteres exactos.

O sea, suponiendo que algún usuario de dicha DLL quisiera codificar más de 60.000 caracteres se encontraría con el problema de no poder hacerlo... por si tenía poco con un problema, ahora acaso tengo dos. ¡Toma ya!

¿Pero qué demonios significa esta limitación de 60.000 caracteres? ¿Por qué, exactamente, 60.000 caracteres? ¿Cómo es que dicha limitación existe si se usa Indy como si se usa la unidad que he enlazado más arriba?

Uff...