ForumSections

CryptDecode avec modificateur CRYPT_ARCH_ZIP - Comment l'utiliser ? - page 7

Nouveau commentaire

Vasiliy !

Avez-vous obtenu une réponse ?

Pas encore. Je pense qu'ils liront ce fil et répondront ici même. En attente.
Veuillez établir une liste claire de vos questions.

La fonction fonctionne avec un tampon de données séparé, pas avec des fichiers d'archives.
L'algorithme deflate est utilisé, et la fonction a été introduite pour être utilisée dans WebRequest, au cas où la réponse serait récupérée par le serveur.

Le paramètre clé n'est pas utilisé.
mql5:
Veuillez établir une liste claire de vos questions.

La fonction fonctionne avec le tampon de données individuel, pas avec les fichiers d'archives.
L'algorithme deflate est utilisé, et la fonction a été introduite pour être utilisée dans WebRequest, au cas où la réponse est friée par le serveur.

Le paramètre clé n'est pas utilisé.

Bonjour !

Une question, que signifient les 4 octets à la fin duCryptEncode() avec le paramètre CRYPT_ARCH_ZIP ?

Si vous utilisez l'algorithmedeflate, vous pouvez également décompresser les archives ZIP en sachant comment vous obtenez ces 4 octets.

( Exemple de décompilateur ZIP à la page 6)

Mikalas:

Bonjour !

Une question, que signifient les 4 octets à la fin duCryptEncode() avec le paramètre CRYPT_ARCH_ZIP ?

Il s'agit du contrôle d'intégrité, ADLER32 ou CRC32 (il dépend des paramètres d'archivage (Adler32 est toujours utilisé dans MQL) et peut être absent) des données sources.
et les 2 premiers octets ?
sanyooooook:
mais les 2 premiers octets ?

C'est très probable :

0x78 - signe des données emballées

0x5E - méthode de compression

Ces octets ne changent pas (j'ai vérifié)

mql5:
Il s'agit d'un contrôle d'intégrité, ADLER32 ou CRC32 (peut ne pas exister) à partir des données sources.

Merci.

Le ZIP sans 4 octets et CRC32 de l'archive ZIP n'est pas déballé :(

Vasiliy, notre entreprise ne fonctionnera pas

À moins, bien sûr, que les gars de MQ ne nous rejoignent à mi-chemin et n'ajoutent un drapeau à l'adresse suivante

functionCryptDecode(CRYPT_ARCH_ZIP, data, key, result,NO_READ_CRC) ;

ou prenez le CRC32 du fichier ZIP:

CryptDecode(CRYPT_ARCH_ZIP, data, key, result,USE_CRC_FROM_ZIP) ;

struct ZIP_HEADER
{
  uint   sign;
  ushort a_version;
  ushort bit_flag;
  ushort comp_method;
  ushort last_mod_time;
  ushort last_mod_date;
  //uint   crc_32;
  uchar  ll_crc;
  uchar  lh_crc;
  uchar  hl_crc;
  uchar  hh_crc;
  uint   pack_size;
  uint   unpack_size;
  ushort fn_len;
  ushort extr_field_len;
};
Mikalas:

Merci.

Le ZIP sans 4 octets et CRC32 de l'archive ZIP n'est pas déballé :(

Vasily, notre idée ne fonctionnera pas.

À moins, bien sûr, que les gars de MQ ne nous rejoignent à mi-chemin et ajoutent un drapeau en

functionCryptDecode(CRYPT_ARCH_ZIP, data, key, result,NO_READ_CRC) ;

Peut-on essayer de glisser un quatre octets vide ?

mql5:
Il s'agit du contrôle d'intégrité, ADLER32 ou CRC32 (dépend des paramètres d'archivage (MQL utilise toujours Adler32) et peut ne pas exister) des données sources.
C-4:

Essayez peut-être de glisser un quatre octets vide ?

J'ai essayé sans les 4 derniers octets et avec les 4 derniers octets "0" - ça ne marche pas :(
12345678910
Nouveau commentaire