AutoIt Français

Bonsoir
En éditant un fichier avec un éditeur hexadécimal, ce dernier contient des ofset :00 00 00 en copiant à partir de n’importe quel éditeur hexadécimal j’obtient ce qui suit : « MZP ÿÿ bahbahba¸bah @ bah bah « c.à.d. là ou j’ai mis bah normalement c’est des caractères invisibles (0 invisible)
Alors en copiant le dit texte dans « SciTE Script Editor de Autoit» et après l’avoir copié de nouveau de autoit vers bloc notes en l’ouvrant avec editHxa les 00 00 devinent des 20 20 incroyable mais vrai !!! Là je suis bloqué pour mon application filewrite($2,"MZP ÿÿ ¸ @ "&$txt)
Pouvez-vous m’aider merci

Si on ne vous a jamais dit qu'écrire le titre de son message tout en majuscule est incorrect, voilà qui est fait. Donc merci d'éditer rapidement.

De plus votre explication est relativement confuse et n'incite pas à vous aider puisque ce que vous écrivez parait totalement abstrait !!!
Mettez vous à la place de quelqu'un qui ne voit pas ce que vous avez fait et expliquez plus clairement.

Edit : Pour information, voici deux explications de ce qu'est un offset :
http://fr.wikipedia.org/wiki/Offset_%28informatique%29
http://www.developpez.net/forums/d1497/ ... /#post9081
Je doute que cela corresponde à ce dont vous voulez nous parler.

Après réflexion, en ce qui concerne votre demande, n'effectuez vous pas une opération en mode texte plutôt qu'en mode binaire ?

Le copier/coller de caractères spéciaux ne fonctionne pas vraiment bien dans des applications tel que le bloc-notes ou assimilé. ^^

Bonsoir Tlem
1- Copiez ce texte Hex suivant : 4D 5A 50 00 02 00 00 00 04 00 0F 00 FF FF 00 00 sur le ploc notes puis enregistrer le.
2- Avec un éditeur hexadécimal par exemple : HexEdit (modification à faire avant Tools/options/Miscellaneous/activer : Typing replaces selection/ok) puis faite une copie du contenu sur un nouveau bloc notes, vérifiez avec HexEdit vous allez constatez que le texte reste inchangé.
3- Copie le texte du bloc notes (2) sur « SciTE Script Editor » de Autoit.
4- Puis copier le texte du bloc note (3) sur un nouveau bloc notes. Vous allez constater à l’aide de HexEdit que les 00 deviennent des 20.

00 Hex veut dire NUL (ne fait rien ou retour chariot) par cotre 20 Hex signifie espace (Space).Dans ce cas toutes les applications basées sur table ASCII seront inapplicable avec Autoit se qui revint à dire que les mauvais étudiants auraient 20 à leur bulletin à la place d’un 00.
Bon courage les amis.

Et en UTF8 ?

Vous mélangez des outils et des données qui ne ne vont pas ensemble, alors forcément, ça fait de la mayonnaise !!!

Bonjour
le chiffre zéro (0) n'est pas un caractères spécial et le copier/coller il fonctionne parfaitement bien dans des applications tel que le bloc-notes ou assimilé mais il ne se mélange pas avec les outils et les données de la mayonnaise !!! un beug en le corrige c'est tout.

Bonjour Iste
svp voulez vous développer vos propos merci

Vous confondez plusieurs choses.
Déjà, pour commencer, dans la séquence "4D 5A 50 00 02 00 00 00 04 00 0F 00 FF FF 00 00" vous avez des espaces intermédiaires, or sur de vraies données hexadécimale extraites d'un éditeur lui aussi hexadécimal, ces données n'y sont pas !!!
Ensuite, si je fait la première partie de ce que vous demandez :

ELGAMALI a écrit :Copiez ce texte Hex suivant : 4D 5A 50 00 02 00 00 00 04 00 0F 00 FF FF 00 00 sur le ploc notes puis enregistrer le.

mon bloc-notes me propose plusieurs types de fichiers :

• ANSI
• Unicode
• Unicode big endian
• UTF-8

Forcément, si vous choisissez le mauvais format avec en plus des données qui ne sont pas sensées être existante, cela ne risque pas de fonctionner.

Encore si vous m'aviez proposé :cela pourrait éventuellement fonctionner si vous utilisez le bon format, mais sans cela, aucune chance ...

Mais sa ne résous pas le beug Autoit

Bonjour,

Tu n'as pas compris ce qu'on essaye de te dire Elgamali : IL N'Y A PAS DE BUG. En tout cas pas dans cet exemple là.

En effet tu mélanges les torchons et les serviettes, car en copiant du texte dans le bloc notes, tu ne touches pas du tout au binaire (en tout cas dans le bloc notes windows). Et AutoIt fonctionne très bien en mode binaire : les 0 sont des 0 et les 1 sont des 1, et comme on dit, qui peut le plus peut le moins.

Revérifie ton modus operandi avant de présenter un bug, car (je l'ai vu énormément dans mon boulot) un test qui plante ne vient pas toujours d'un programme qui plante, mais du test qui est mal conçu.

A bientôt.

Bonjour ZDS

Je vous remercie de t'être penché sur ce bug autoit, pour le comprendre vous trouverez ci-joint fichier TEST.txt .
1- Ouvrir le fichier TEST.TXT ci-joint avec HexEdit, vous aller voir que les 00 sont bien là. Puis (edition/ sélectionner tout) copiez le contenu sur une page de SciTE Script Editor.
2- Copie le texte de la page SciTE Script Editor de Autoit vers un nouveau bloc notes.
3- Vous allez constater à l’aide de HexEdit que les 00 deviennent des 20.

Cordialement

Déjà, rien a voir avec AutoIt vu que la on n'y touche même pas...
Ensuite, votre chaine n'est pas faites pour être copiée dans le presse papier, aussi, des données sont perdu ou modifiées quand on essaye.

Mais si je demande a AutoIt de faire la copie :aucun souci.

Tlem a écrit :Vous mélangez des outils et des données qui ne ne vont pas ensemble, alors forcément, ça fait de la mayonnaise !!!

Coucou,


Comme le dit très bien Tlem, le mélange de format, sa fait des chocapics.


Il y a surement un autre moyen pour vous de "copier" cette chaîne de caractère (si j'ai bien compris le soucis) pour le pas utiliser de logiciel tiers qui vienne grappiller des informations et qui les perdent au passage.




Eߣ“B‚ˆmatroskaB‡B…S€g I©fä*×±ƒB@M€£libebml v0.7.7 + libmatroska v0.8.1WAAVSMatroskaFileD‰„GÖ< Daˆâj¶úö s¤·1
êƃ§¶->Që¢2¥T®k@æ®@×sÅ„Ü’®ƒ¹ˆUª œ mç#1O„?€ Uî †V_MPEG4/ISO/AVCª#ツbZ 3µœƒundc¢¨M@3ÿá gM@3št “`3 e0e@ hî<€à•°‚к‚@š T°‚ÐTº‚@®ÒׁsÅ„iÕy‘ƒ¹ˆUª œmç #1O„?€ Uî †‰A_MPEG/L3ª#ツŽ˜Ð3µœƒundት„G,D ŸìD


(J'aime surtout le MPEG a la fin, je sais pas de quoi provient cette chaine, mais c'est pas du txt xD)

PS : Matroska ??


Jérôme

Salut Iste
Que pensez-vous du résultat du code ci-dessous
Honnêtement j'aimerai avoir votre avis.

Ne vous inquiéter pas cher Jerome ce n’est qu’un exemple parmi d’autre, mais comme vous le dit très bien il y a sûrement un autre moyen pour "copier" cette chaîne de caractère avec Autoit, ainsi le bug autoit sautera

J'en pense que pour avoir écrit ce code vous avez du copier coller le contenu via un éditeur de text, et que comme déja dis, le presse papier n'est pas fait pour stocker ce genre de données et que donc il ne faut pas s'attendre a retrouver le résultat de dépars...
De toute facon chez moi, la compilation ne passe pas du tout ! Et normal, ce genre de chaine n'a rien a faire dans un code..

Mais l'autre ligne "filewrite($2,"ici c'est la copie du texte TEST.TXT"&$txt)" prouve bien qu'il n'y a pas de bug avec AutoIt !

Encore une foi, ces valeurs sont du binaire et non des chaines de caractères ! Vous ne pouvez donc pas les manipuler avec des outils fait pour du texte comme le blocnote ou le copier/coller

Vous vous trompez c'est un véridique Bug pour les développeurs. AutoIt est un langage de création de script, normalement il doit stocker dans son presse papier les données binaire et aussi les chaînes de caractères n’est se pas !!!!!!???? D’après vous on ne peut pas sauter ce Bug, donc il faut au mois le contourné ; la solution est devant vous mais il faut tout simplement l’amélioré merci pour votre aide.

Rebonjour,

Je pense que tu es plus de mauvaise foi sans même essayer de comprendre ce que disent Tlem, Iste, Jérôme, etc... : Le problème que tu as n'est pas lié à AutoIt, mais au mieux à Scintilla !

C'est comme d'ouvrir un fichier texte encodé en chinois (ou en binaire dans ton cas) dans un éditeur de texte qui ne lit pas le chinois de façon native (Scite). Normal dans ce cas que ça affiche des carrés (ou des espaces) à la place des caractères non traitables.

Après, mon raisonnement n'est certainement pas sans faille (j'essaye surtout de vulgariser les dires précédents), mais pas la peine de blâmer et de crier au bug alors que tu n'en as pas la certitude/preuve que ça vienne d'AutoIt et pas de ton environnement de développement. Si tu as un exemple plus concret, je suis preneur.

A bientôt !

Personnellement, quand je copie/colle ton texte "Eߣ“B‚ˆmatroskaB‡B…S€g I©fä*tagadatsointsoin" dans Scite, je me retrouve avec des symboles "illégaux" types [SOB], <sub>, [NAK], etc... Par contre, en partant de ton fichier TEST.TXT, en récupérant son contenu dans un script, et en le collant dans un autre fichier texte (EN BINAIRE), la comparaison de contenu (sous Notepad++ par exemple) tombe sur un match parfait... Ce qui prouve bien qu'AutoIt peut traiter tes caractères zarbis mais que Scite lui a du mal vu l'encodage utilisé.[spoiler="Lecture et copie, y a pas plus c*n comme code"][code=text]Local $fichier, $texte, $flux

; Récupération
$fichier = "Test.txt"
$flux    = FileOpen($fichier, 0)
$texte   = FileRead($flux)

; Enregistrement
$fichier = "Test2.txt"
$flux    = FileOpen($fichier,8+2)
FileWrite($flux, $texte)
FileClose($fichier)[/code][/spoiler]</sub>

le "00" en valeur hexa copier dans le bloc note donne rien car il correspond a rien en valeur ascii
ce qui se traduit par un blanc
mais quand tu essaye d envoyer un "blanc" (espace en faite) de l ascii vers l hexa ca se traduit par un 0x20 ce qui est tout a fait normale car c est le code ascii de l espace

si tu veut editer des fichier binaire tu ouvre le fichier en binaire et tu lis la valeur des octet
et si tu veut les coller dans un bloc note il faut les transcodé dans leur équivalent ascii

pas de bug la juste des torchons et des serviettes dans le meme panier