Memo remplace les caractères spéciaux !
Résolu
romit
Messages postés
160
Date d'inscription
jeudi 28 août 2003
Statut
Membre
Dernière intervention
30 juin 2011
-
29 déc. 2005 à 20:15
f0xi Messages postés 4205 Date d'inscription samedi 16 octobre 2004 Statut Modérateur Dernière intervention 12 mars 2022 - 31 déc. 2005 à 21:23
f0xi Messages postés 4205 Date d'inscription samedi 16 octobre 2004 Statut Modérateur Dernière intervention 12 mars 2022 - 31 déc. 2005 à 21:23
A voir également:
- Powershell remplacer caractère spéciaux
- Regex caractères spéciaux ✓ - Forum VB.NET
- Chaine sans caractère spéciaux - Forum Java
- Interdire certains caracteres ( le | et ;) ✓ - Forum Regex
- Vba caractère spéciaux ✓ - Forum Visual Basic 6
- Powershell tableau 2 dimensions ✓ - Forum Flash
10 réponses
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
35
31 déc. 2005 à 21:23
31 déc. 2005 à 21:23
mmmm ....
alors les carrés noirs ce sont tout simplement des caracteres non affichable... en gros, il n'ont pas de representation dans la police (fonte) en cours.
si tu prend la police Terminal tout les caracteres s'afficherons
pour le probleme des saut de lignes, cela vient des caractere #13 et #10 qui servent en fait a TMemo et au TStrings en general pour sauter a la ligne suivante.
cela le feras egalement dans un ListBox par exemple ...
c'est la le probleme d'afficher du code ASCII dans un bloc note ou memo.
de plus, notepad.exe est ecrit en C++ ou en VB ... donc il se peu que le comportement differe completement d'un TMemo de delphi et tu veras egalement un comportement tout autre sur Notepad++ ou Wordpad par exemple.
mais ton fichier par contre, lui reste inchangé ... c'est seulement un probleme d'affichage.
si tu utilise la commande DOS "Type" tu auras un affichage similaire a celui d'un TMemo.
de plus, il y a surrement l'option WordWrap (saut de ligne auto) d'activer dans ton bloc-note ou dans ton TMemo, d'ou un affichage different.
et n'oublis pas, il faut travailler sur la propriétée Memo.Text et non Memo.Lines
La theorie c'est quand on sait tout, mais que rien ne fonctionne.
La pratique c'est quand tout fonctionne, mais que personne ne sait pourquoi.
<hr>
alors les carrés noirs ce sont tout simplement des caracteres non affichable... en gros, il n'ont pas de representation dans la police (fonte) en cours.
si tu prend la police Terminal tout les caracteres s'afficherons
pour le probleme des saut de lignes, cela vient des caractere #13 et #10 qui servent en fait a TMemo et au TStrings en general pour sauter a la ligne suivante.
cela le feras egalement dans un ListBox par exemple ...
c'est la le probleme d'afficher du code ASCII dans un bloc note ou memo.
de plus, notepad.exe est ecrit en C++ ou en VB ... donc il se peu que le comportement differe completement d'un TMemo de delphi et tu veras egalement un comportement tout autre sur Notepad++ ou Wordpad par exemple.
mais ton fichier par contre, lui reste inchangé ... c'est seulement un probleme d'affichage.
si tu utilise la commande DOS "Type" tu auras un affichage similaire a celui d'un TMemo.
de plus, il y a surrement l'option WordWrap (saut de ligne auto) d'activer dans ton bloc-note ou dans ton TMemo, d'ou un affichage different.
et n'oublis pas, il faut travailler sur la propriétée Memo.Text et non Memo.Lines
La theorie c'est quand on sait tout, mais que rien ne fonctionne.
La pratique c'est quand tout fonctionne, mais que personne ne sait pourquoi.
<hr>
romit
Messages postés
160
Date d'inscription
jeudi 28 août 2003
Statut
Membre
Dernière intervention
30 juin 2011
29 déc. 2005 à 20:18
29 déc. 2005 à 20:18
Ha j'ai oublié de précisé que mon programme de cryptage enregistre le
texte crypté dans un fichier (avec un memo et SaveToFile) mais comme je
l'ai dit, le texte n'est pas modifié dans le notepad !
Romit.
texte crypté dans un fichier (avec un memo et SaveToFile) mais comme je
l'ai dit, le texte n'est pas modifié dans le notepad !
Romit.
sisi231
Messages postés
207
Date d'inscription
mercredi 5 mars 2003
Statut
Membre
Dernière intervention
29 mars 2013
5
30 déc. 2005 à 11:42
30 déc. 2005 à 11:42
quel est ton algo de cryptage ?
car si, comme je le crois il remplace un caractère par un autre d'un autre numéro, peut-être remplacera-t'il des caractères " spéciaux " par des caractères retour chariot (13) et tabulation (je sais plus le numéro), attention aussi car si après cryptage/décryptage il y a des caractères n°8 (backspace) des caractères seront effacés, rendant le cryptage inutilisable.
Une bonne solution est de réaliser un algorythme de cryptage bijectif (si tu as déjà fait un peu de maths tu dois savoir ce que je veux dire) qui soit :
une bijection des caractères IMPRIMABLES vers des caractères IMPRIMABLES
Pour ta deuxième question, tu devrais être plus précis...
Le notepad c a d ?
SISI231
car si, comme je le crois il remplace un caractère par un autre d'un autre numéro, peut-être remplacera-t'il des caractères " spéciaux " par des caractères retour chariot (13) et tabulation (je sais plus le numéro), attention aussi car si après cryptage/décryptage il y a des caractères n°8 (backspace) des caractères seront effacés, rendant le cryptage inutilisable.
Une bonne solution est de réaliser un algorythme de cryptage bijectif (si tu as déjà fait un peu de maths tu dois savoir ce que je veux dire) qui soit :
une bijection des caractères IMPRIMABLES vers des caractères IMPRIMABLES
Pour ta deuxième question, tu devrais être plus précis...
Le notepad c a d ?
SISI231
romit
Messages postés
160
Date d'inscription
jeudi 28 août 2003
Statut
Membre
Dernière intervention
30 juin 2011
30 déc. 2005 à 15:06
30 déc. 2005 à 15:06
Notepad= Bloc-notes de windows mais je ne pense pas que cela viennent
du cryptage, je veux juste que le memo ne remplace par les caractères
et qu'ils se mêle de ce qui le regarde lol.
Donc si 'louverture du fichier pouvait s'effectuer coimme dans le bloc-notes, ce serait parfait ;)
Romit.
du cryptage, je veux juste que le memo ne remplace par les caractères
et qu'ils se mêle de ce qui le regarde lol.
Donc si 'louverture du fichier pouvait s'effectuer coimme dans le bloc-notes, ce serait parfait ;)
Romit.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
35
30 déc. 2005 à 19:59
30 déc. 2005 à 19:59
alors, quand tu travail sur un TMemo et non un file of byte ou array of char, tu ne doit surtout pas travailler avec Memo.Lines
mais avec Memo.text
Memo comme dans tout les fichiers texte brut (ascii) utilise le retour chariot #13#10 (h0D0A) et ce retour chariot doit egalement etre compris dans le cryptage donc, si tu utilise Memo.Lines tu ne pourrat pas transformer le retour chariot et donc cela poseras des problemes.
en travaillant sur Memo.text ou encore [TStrings].text tu pourras modifier TOUT les caracteres present dans le fichiers.
voici un exemple :
// cryptage :
Memo1.text := Crypte(Memo1.Text);
// Décryptage
Memo1.text := Decrypte(Memo1.Text);
pour sauvegarder et ouvrir le fichier, on utiliseras toujours Memo.Lines.LoadFromFile() et Memo.Lines.SaveToFile()
et cela est valable pour n'importe quel algo de cryptage. On pourrais croire qu'il vaudrais mieux utiliser un Array of char ... mais Memo.text etant de type string et les "string" etant tout simplement des array of char, cela n'est pas necessaire.
par contre, on peu bien sur utiliser les pointeurs et donc un array of char (ou byte) pour accelerer les traitements.
cela est simple a comprendre.
voila une fichier ascii : ABDC[h0D0A]DEFG[h0D0A]HIJK
Memo.Text contiendras exactement la meme chose mais Memo.Lines se presenteras de cette façon :
Memo.Lines[0] : ABCD
Memo.Lines[1] : DEFG
Memo.Lines[2] : HIJK
on perd donc ici les retour chariot. ce qui pose un gros probleme car si dans l'algo de cryptage certain caracteres sont transformer en h0D0A (ce qui peu arriver a coups sur) au decryptage, tout les code 0D et 0A seront retransformer en A ou B ou C etc... et donc Memo.Text serat completement different de l'original aprés decryptage.
et comme tout, le mieux serait non pas d'utiliser un bloc note pour visualiser la transformation, avec donc les caracteres ASCII apparent, mais visualiser les valeur Hexa ou Decimal de ces codes.
cela eviteras egalement un probleme d'affichage, notement avec les return et les backspace.
pour corriger Sisi231, le caractere Backspace n'efface les caracteres que "virtuellement" (a l'affichage) jusqu'au retour a la ligne (EOLN) precedent.
en gros si j'ai :
ABCD[EOLN]DEFG[BACKSCPACE][EOLN]HIJK
a l'affichage je n'aurais que ABCD HIJK
mais mon fichier contiendras toujours ABCD DEFG HIJK
d'ou l'interet donc de travailler sur Memo.text plutot que sur Memo.Lines.
ou alors il faudrait reinserrer dans la chaine les retour chariot, mais la encore ça peu poser des problemes.
La theorie c'est quand on sait tout, mais que rien ne fonctionne.
La pratique c'est quand tout fonctionne, mais que personne ne sait pourquoi.
<hr>
mais avec Memo.text
Memo comme dans tout les fichiers texte brut (ascii) utilise le retour chariot #13#10 (h0D0A) et ce retour chariot doit egalement etre compris dans le cryptage donc, si tu utilise Memo.Lines tu ne pourrat pas transformer le retour chariot et donc cela poseras des problemes.
en travaillant sur Memo.text ou encore [TStrings].text tu pourras modifier TOUT les caracteres present dans le fichiers.
voici un exemple :
// cryptage :
Memo1.text := Crypte(Memo1.Text);
// Décryptage
Memo1.text := Decrypte(Memo1.Text);
pour sauvegarder et ouvrir le fichier, on utiliseras toujours Memo.Lines.LoadFromFile() et Memo.Lines.SaveToFile()
et cela est valable pour n'importe quel algo de cryptage. On pourrais croire qu'il vaudrais mieux utiliser un Array of char ... mais Memo.text etant de type string et les "string" etant tout simplement des array of char, cela n'est pas necessaire.
par contre, on peu bien sur utiliser les pointeurs et donc un array of char (ou byte) pour accelerer les traitements.
cela est simple a comprendre.
voila une fichier ascii : ABDC[h0D0A]DEFG[h0D0A]HIJK
Memo.Text contiendras exactement la meme chose mais Memo.Lines se presenteras de cette façon :
Memo.Lines[0] : ABCD
Memo.Lines[1] : DEFG
Memo.Lines[2] : HIJK
on perd donc ici les retour chariot. ce qui pose un gros probleme car si dans l'algo de cryptage certain caracteres sont transformer en h0D0A (ce qui peu arriver a coups sur) au decryptage, tout les code 0D et 0A seront retransformer en A ou B ou C etc... et donc Memo.Text serat completement different de l'original aprés decryptage.
et comme tout, le mieux serait non pas d'utiliser un bloc note pour visualiser la transformation, avec donc les caracteres ASCII apparent, mais visualiser les valeur Hexa ou Decimal de ces codes.
cela eviteras egalement un probleme d'affichage, notement avec les return et les backspace.
pour corriger Sisi231, le caractere Backspace n'efface les caracteres que "virtuellement" (a l'affichage) jusqu'au retour a la ligne (EOLN) precedent.
en gros si j'ai :
ABCD[EOLN]DEFG[BACKSCPACE][EOLN]HIJK
a l'affichage je n'aurais que ABCD HIJK
mais mon fichier contiendras toujours ABCD DEFG HIJK
d'ou l'interet donc de travailler sur Memo.text plutot que sur Memo.Lines.
ou alors il faudrait reinserrer dans la chaine les retour chariot, mais la encore ça peu poser des problemes.
La theorie c'est quand on sait tout, mais que rien ne fonctionne.
La pratique c'est quand tout fonctionne, mais que personne ne sait pourquoi.
<hr>
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
35
30 déc. 2005 à 20:08
30 déc. 2005 à 20:08
pour les Backspace, c'etait une astuce utilisée par certain programmeur a l'epoque du DOS pour eviter que les gens puisse faire un simple "Type file.exe" sur les programme.
en inserrant des backspaces a des endroits strategique, Type ne renvoyer quasiment rien du contenus du fichier.
mais a une epoque ou les gens on accés a des editeurs Hexadecimaux et désassembleur, cette "technique" est completement devenue obsolete.
pour certain desassembleur il existe des petit bouts de code pour les mettre en echec, mais certain assé performant (softice) ne sont pas sensible a ces petit "anti-deasm".
un editeur hexadecimal ne peu pas etre mis en echec.
on vas donc utiliser un compresseur d'executable (pklite, upx etc...) pour rendre le fichier "illisible" dans un editeur hexa ... mais la encore, il suffit d'avoir le compresseur pour decompresser l'executable et le rendre lisible.
ensuite il suffirat de "noper" les "anti-deasm" avec l'editeur hexa et on pourrat alors passer l'exe dans le desassembleur.
mais bon c'etait juste pour faire une parenthese culturelle.... cela n'a pas pour but de donner une technique de cracking qui n'est d'ailleur pas un secret et on la trouve egalement dans la Bible PC.
La theorie c'est quand on sait tout, mais que rien ne fonctionne.
La pratique c'est quand tout fonctionne, mais que personne ne sait pourquoi.
<hr>
en inserrant des backspaces a des endroits strategique, Type ne renvoyer quasiment rien du contenus du fichier.
mais a une epoque ou les gens on accés a des editeurs Hexadecimaux et désassembleur, cette "technique" est completement devenue obsolete.
pour certain desassembleur il existe des petit bouts de code pour les mettre en echec, mais certain assé performant (softice) ne sont pas sensible a ces petit "anti-deasm".
un editeur hexadecimal ne peu pas etre mis en echec.
on vas donc utiliser un compresseur d'executable (pklite, upx etc...) pour rendre le fichier "illisible" dans un editeur hexa ... mais la encore, il suffit d'avoir le compresseur pour decompresser l'executable et le rendre lisible.
ensuite il suffirat de "noper" les "anti-deasm" avec l'editeur hexa et on pourrat alors passer l'exe dans le desassembleur.
mais bon c'etait juste pour faire une parenthese culturelle.... cela n'a pas pour but de donner une technique de cracking qui n'est d'ailleur pas un secret et on la trouve egalement dans la Bible PC.
La theorie c'est quand on sait tout, mais que rien ne fonctionne.
La pratique c'est quand tout fonctionne, mais que personne ne sait pourquoi.
<hr>
romit
Messages postés
160
Date d'inscription
jeudi 28 août 2003
Statut
Membre
Dernière intervention
30 juin 2011
30 déc. 2005 à 22:00
30 déc. 2005 à 22:00
Merci pour ta réponse ultracomplète lol mais j'utilse deja Memo1.lines.LoadFromFile(...)
et c'est la quer ça me donne le remplacement de caractère !
Romit.
et c'est la quer ça me donne le remplacement de caractère !
Romit.
romit
Messages postés
160
Date d'inscription
jeudi 28 août 2003
Statut
Membre
Dernière intervention
30 juin 2011
30 déc. 2005 à 22:02
30 déc. 2005 à 22:02
Lol tout ced que je veux c'est que le mémo n'effectue pas de formatage ^^
Romit.
Romit.
romit
Messages postés
160
Date d'inscription
jeudi 28 août 2003
Statut
Membre
Dernière intervention
30 juin 2011
30 déc. 2005 à 22:07
30 déc. 2005 à 22:07
Oups dsl j'ai pas bien lu ta réponse, je test àa tout de suite et j'accepte p-e la réponse
Romit.
Romit.
romit
Messages postés
160
Date d'inscription
jeudi 28 août 2003
Statut
Membre
Dernière intervention
30 juin 2011
30 déc. 2005 à 22:12
30 déc. 2005 à 22:12
Ca ne marche pas mais je réexplique briévement:
Quand je crypte un texte, le texte contient des petits rectangles verticaux noirs (tu vois ce que je veux dire) et quand j'ouvre un fichier avec mon memo, certains de ces rectangles sont interpretès comme des sauts de lignes.
Quand j'ouvre mon fichier avec le bloc-notes, les caractères sont toujours bien présents et non interpretés ^^
Romit.
Quand je crypte un texte, le texte contient des petits rectangles verticaux noirs (tu vois ce que je veux dire) et quand j'ouvre un fichier avec mon memo, certains de ces rectangles sont interpretès comme des sauts de lignes.
Quand j'ouvre mon fichier avec le bloc-notes, les caractères sont toujours bien présents et non interpretés ^^
Romit.
