Golang peut-il être décompilé ?

golang ne peut pas être décompilé. Raison : Golang est un langage statique compilé. Golang générera des fichiers binaires après la compilation, et les fichiers binaires sont des fichiers contenant des données ou des instructions de programme écrites en ASCII et en caractères ASCII étendus. Ces fichiers contiennent des formats et des codes informatiques spéciaux, ils ne peuvent donc pas être décompilés.

L'environnement d'exploitation de ce tutoriel : système Windows 7, GO version 1.18, ordinateur Dell G3.

golang ne prend pas en charge la décompilation.

Raison :

Le langage Go est un langage statique compilé, donc avant d'exécuter un programme en langage Go, il doit être compilé dans un fichier exécutable binaire.

Golang générera des fichiers binaires après la compilation, et les fichiers binaires sont des fichiers contenant des données ou des instructions de programme écrites en ASCII et en caractères ASCII étendus. Ces fichiers contiennent des formats spéciaux et des codes informatiques, ils ne peuvent donc pas être décompilés.

Avantages des fichiers binaires

Pourquoi utiliser des fichiers binaires. Il y a probablement trois raisons :

La première est que les fichiers binaires économisent de l'espace, et il n'y a aucune différence entre les deux lors du stockage des données de caractères. Cependant, lors du stockage de nombres, en particulier de nombres réels, le binaire est plus économe en espace. Par exemple, pour stocker des données Real*4 : 3.1415927, un fichier texte nécessite 9 octets et stocke respectivement : 3. 1 4 1 5 9 2 7 ces 9. Valeur ASCII, alors que les fichiers binaires ne nécessitent que 4 octets (DB 0F 49 40)

　La deuxième raison est que les données impliquées dans les calculs dans la mémoire sont stockées au format binaire non formaté, donc utiliser le binaire pour les stocker dans un fichier est plus rapide. S'il est stocké sous forme de fichier texte, un processus de conversion est requis. Lorsque la quantité de données est importante, il y aura une différence de vitesse significative entre les deux.

　Troisièmement, pour certaines données relativement précises, l'utilisation du stockage binaire n'entraînera pas la perte de bits valides.

Comment les fichiers binaires sont stockés

Répertoriez un fichier binaire comme suit :

00000000h:0F 01 00 00 0F 03 00 00 12 53 21 45 58 62 35 34; .........S!EXb54
00000010h:41 42 43 44 45 46 47 48 49 47 4B 4C 4D 4E 4F 50; ABCDEFGHIGKLMNOP

Les éléments répertoriés ici sont ce que vous voyez dans UltraEdit (UE). En fait, seule la partie rouge correspond au contenu du fichier. Le précédent est le numéro de ligne ajouté par UE. Ce qui suit est une référence que l'UE tente d'interpréter comme un personnage.

　Ce fichier fait 32 octets au total. Affiché sous forme de deux colonnes de 16 octets chacune. En fait, ce n'est qu'un affichage de l'UE. Les vrais fichiers n'ont pas de lignes séparées. Connaissant simplement le contenu de ce fichier, si nous n'avons aucune explication, nous ne pouvons voir aucune information utile.

　Je vais préciser une explication ci-dessous : Nous pensons que les 4 premiers octets sont des données entières de 4 octets (0F 01 00 00 hexadécimal : 10Fh décimal : 271). Les 4 octets après ces 4 octets sont 4 autres octets de données entières (0F 03 00 00 hexadécimal : 30Fh décimal : 783). Les 4 octets suivants (12 53 21 45) représentent une donnée réelle de 4 octets : 2,5811919E+3. Les 4 octets suivants (58 62 35 34) représentent 4 autres octets de données d'exécution : 1.6892716E-7. Et seuls les 16 derniers octets (41 42 43 44 45 46 47 48 49 47 4B 4C 4D 4E 4F 50) sont, à notre avis, 16 octets de chaîne (ABCDEFGHIGKLMNOP)

En fait, les fichiers binaires stockent simplement des données, le type de données n'est pas spécifié par exemple, du 9ème octet au 16ème octet ci-dessus (12 53 21 45 58 62 35 34), nous pensions simplement qu'il s'agissait de 2 types réels de 4 octets, mais en fait, il peut également être considéré comme un type de caractère de 8 octets (S). !EXb54). La chaîne de 16 octets suivante (ABCDEFGHIGKLMNOP) peut également être considérée comme deux entiers de 8 octets, ou quatre entiers de 4 octets, ou encore deux types réels de 8 octets, et quatre types réels de 4 octets, etc.

Par conséquent, face à un fichier binaire, nous ne pouvons pas connaître avec précision sa signification. Nous avons besoin d'une description de sa méthode de stockage des données. Cette description nous indique quel type de données se trouve de quel octet à quel octet et quelle est la signification des données stockées. Sinon, nous ne pouvons que deviner ou être impuissants.

【Recommandations associées : Tutoriel vidéo Go, Enseignement de la programmation】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!