![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
Hola,
Sí; desde luego, no sé yo si tendré tiempo y lugar como para ponerme a investigar qué puede estar pasando en definitiva. Más bien tal vez sea mejor esperar a que algo falle para tratar de arreglarlo. A mí me extraña mucho que la última versión de Indy añada algún "bug" que no existía en versiones anteriores, pero, lo cierto es que sería posible. Pero me extraña doblemente, porque, para mí tengo que Indy se usa profusamente en muchos proyectos, de manera que parece raro que un error así no está arreglado o no se comente por ahí... ahora que lo pienso, tal vez pueda buscar información sobre esto: a ver si se comenta por ahí o no sobre algún error en la última versión de Indy en relación a al componente para trabajar con "base 64"... ya veremos. |
|
#2
|
||||
|
||||
|
Una pregunta: ¿por qué tienes que codificar en base 64? Eso sólo es para cuando necesitas transmitir la información en formato sólo texto, por ejemplo, cuando envías un correo electrónico, pero de otra forma es innecesario. Claro que no podrás mostrarla en un TMemo pero de todas maneras, ¿qué haría el usuario con esa información encriptada en el Memo? Si simplemente necesitas que el usuario conserve esa información puedes guardarla en un archivo usando un stream.
// Saludos |
|
#3
|
||||
|
||||
|
Habría que mirar ese código despacito y como se realizan ciertos cast. No es muy buena idea mezclar string con buffers cifrados pues éstos, además de caracteres no imprimibles pueden contener "ceros" en el buffer cifrado, al convertirlo a string la cadena se parte en en "0". Recordar el estilo "C" de cadenas ASCIIZ. Es probable que te esté ocurriendo esto. No que no tiene ninguna lógica es que no te funcione con BASE64, que está pensado para evitar este efecto.
Saludos. |
|
#4
|
||||
|
||||
|
Los strings pueden manejar perfectamente bytes no imprimibles incluido el cero. Lo único que no puedes es, este, imprimirlos. Por eso, insisto, a menos que quiera mostralo en un Memo, mandarlo por correo, guardarlo en un XML o algo por el estilo, no tiene necesidad de pasar a base 64.
// Saludos |
|
#5
|
||||
|
||||
|
Claro, roman, por eso me he referido al cast de conversión PBYTE -> String en el que se va a partir la cadena en cuanto encuentre un #0. Pero ya digo, hay que revisar el código al usar la API de windows y su conversión a String. Naturalmente puedo estar equivocado (no revisé el código), pero el hecho de que se parta la cadena me hace pensar en esa posible causa.
Saludos. |
|
#6
|
||||
|
||||
|
Acabo de probar el código y funciona bien. El primer ShowMessage no muestra toda la cadena cifrada porque realiza una conversión a PCHAR en el seno de ShowMessage. He realizado un debug hasta llegar al punto del fallo, en concreto cuando usa la API DrawText y corta en el primer #0 encontrado. El problema no es del cifrado sino de ShowMessage de delphi. En caso de usar cualquier otra API que use cadenas, el efecto será similar.
Saludos. |
|
#7
|
||||
|
||||
|
Cita:
// Saludos |
|
#8
|
||||
|
||||
|
Quizá me confundo pero yo a lo que me refiero es al código original que pone dec antes de entrar a lo de convertir a base 64.
Él dice que en este código
Cita:
Por ejemplo, puede meter encryptedText en un TStringStream, copiar el stream a un TFileStream y guardarlo a disco. Siguiendo los pasos inversos necesariamente obtendrá el texto original. // Saludos |
|
#9
|
||||
|
||||
|
Hola a todos,
Gracias por vuestro interés. Román, no se trata de mostrar la cadena cifrada en un "Memo", pero, de guardarla en un archivo INI, por ejemplo (por esto saltó la liebre, como suele decirse). O, en todo caso, se trata de "retornar" una cadena cifrada, que, después debería poder descifrarse para obtener la cadena original. De todas formas me has dejado una duda que quiero probar... Lo cierto es que todavía estoy con la mosca detrás de la oreja, fundamentalmente, por estos dos motivos: 1º Todavía no me explico cómo es posible que el mismo código que funciona en Delphi 2007 bajo Windows 7 no lo hace de igual modo en Delphi 2007 bajo Windows 8. Pero, en fin, vamos a dar por hecho algún tipo de error introducido en las últimas versiones de Indy, cosa que me extraña muchísimo, pero, puesto que el problema "parece" solucionarse usando un componente distinto de Indy, de acuerdo, sigamos adelante... pero... 2º Resulta que de este modo, con el nuevo componente (no Indy) todo va sobre ruedas en Delphi, esto es, puedo cifrar y descifrar cadenas verdaderamente largas sin problema alguno. Pero... por alguna razón, cuando lo pruebo en mi programa, no es que no funcione, pero, es que puede cifrar cadenas de (ojo al dato) hasta 60.000 caracteres. Como lo leéis. A mí me suena que esa es la cifra máxima permitida para una "línea"... Bien. Quisiera ahora hablar un poco de mi programa, sólo para declarar su naturaleza un tanto "especial". Mi programa es en realidad una DLL, que a su vez será usada por otro programa. ¿Complica esto las cosas? Bueno, sí, pero no. Llevo hechas ya varias decenas de DLL para dicho programa "host", y, ciertamente, a veces he notado comportamientos extraños que no notaba en Delphi. Resumiendo, esto podría deberse a las características del programa, de trabajar desde una DLL, etc. Pero el caso es que me llama muchísimo la atención no poder cifrar cadenas de más de una cifra tan redonda como 60.000 caracteres... me parece una cifra demasiado redonda como para que no signifique algo. ¿Cuál es mi problema ahora, por lo tanto? Pues que, asumiendo que usar "base 64" sea la solución, lo cierto es que esta solución funciona sin problemas en un programa de pruebas hecho en Delphi, pero, no en la DLL desarrollo y a su vez utiliza otro programa. Voy a intentar que el autor de dicho programa me eche una mano, en el sentido de si a él le sonase de algo una cifra mágica como es 60.000 caracteres... ni uno más. Por supuesto si se os ocurre cualquier cosa al respecto os estaría muy agradecido. P.D. Román, de hecho la DLL que desarrollo cuenta con "acciones" para cifrar y descifrar cadenas y archivos. Ahora bien, en lo tocante a archivos no he tenido problemas en cifrar y descifrar archivos de cualquier tamaño y tipo. Pero claro,... las acciones para cifrar cadenas se supone que deberían servir también. Ay diosito mío. ![]() |
|
#10
|
||||
|
||||
|
Cita:
No trates de guardarlo en un archivo de texto (INI) pues obtendrás el mismo error, usa un archivo binario. Saludos. |
|
#11
|
||||
|
||||
|
Si quieres guardar el resultado en un archivo INI, desde luego, no tienes otra opción que hacer una conversión a base 64 o similar. Pero, puedes guardarlo en un archivo binario y olvidarte del base 64
![]() // Saludos |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Recuperar BookMark despues de cerrar dataset... | verito_83mdq | Varios | 10 | 27-01-2011 00:03:18 |
| Recuperar Informacion despues de un Commit | Kipow | Firebird e Interbase | 2 | 01-04-2009 19:04:02 |
| Error al Tratar de Almacenar Cadena con Acepto | inferno | Firebird e Interbase | 3 | 04-10-2006 17:17:40 |
| Recuperar autoinc. después de Insert to | aig | MS SQL Server | 2 | 22-09-2004 10:41:28 |
| Recuperar autonumericos despues de Borrar, Cancelar ,Ect. | IcebergDelphi | Varios | 1 | 14-05-2003 07:55:02 |
|