![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Vasiliy!
Não esperei por uma resposta sua. (não sei se a MQ teve tempo para implementar mudanças na construção 1100)
Decodificador:
Chamadas:
Vasiliy!
Não esperei por uma resposta sua. (não sei se a MQ teve tempo para implementar mudanças na construção 1100)
Decodificador:
Chamadas:
Mikalas, é possível fazer a decodificação e codificação do código como uma biblioteca com um cheque para desempacotar a conclusão?
Claro. Isso é o que farei num futuro próximo. Haverá embalagem/desembalagem. Adicionar e remover arquivos do arquivo. O principal é que o CryptDecode não falha.
Vasiliy!
A embalagem ZIP é necessária?
Acho que não vale a pena.
1. Se você quiser construir um banco de dados com base no ZIP, ele não será relevante.
Em breve a MQ acrescentará funções padrão para trabalhar com o banco de dados (Renat fez uma pesquisa).
2. Você não pode resolver o problema com arquivos de tamanho maior do que o uint.
Deve haver compressão ZIP64 para os tamanhos ulong.
3. Você não sabe exatamente como os dados MT5 são comprimidos
É possível que arquivos grandes (mesmo de tamanho uint)
arquivos grandes ( mesmo tamanho uint ) serão comprimidos para HOURS!
4. Para "encher" os arquivos em um arquivo, você terá que manter um grande volume de informações em
muitas informações na memória - haverá HARDWARE!
Eu desaconselho vivamente....
Provavelmente estou pensando à moda antiga, mas para mim o arquivamento é interessante para acelerar a transferência de dados na Internet. Localmente com grandes discos rígidos, o tamanho do arquivo perde sua relevância, e o banco de dados será para uma gama limitada de pessoas, e a sua implementação é cara, pois exigirá conhecimentos adicionais do programador e do usuário.
É verdade que o fecho é consideravelmente inferior ao raro na compressão, especialmente do texto - o que é um pouco triste.
Vasiliy!
A embalagem ZIP é necessária?
Acho que não vale a pena.
Eu penso o contrário.
1. Se você quiser construir um banco de dados com base no ZIP, ele não será relevante.
Em breve a MQ adicionará funções padrão para trabalhar com banco de dados (Renat fez uma pesquisa)
Não, o zip não é interessante como alternativa ao DB. Não é por isso que vale a pena se preocupar com o zíper.
2. Você não pode resolver o problema com arquivos de tamanho maior do que o uint.
Deve haver compressão ZIP64 para os tamanhos ulong.
Não tenho nenhum objetivo de criar um análogo do WinZip ou do WinRar. Somente os arquivos mais básicos. Ninguém pensará sequer em comprimir arquivos maiores do que 4 GB.
3. Você não sabe exatamente como os dados MT5 são compactados.
É possível que os arquivos grandes (mesmo de tamanho uint) sejam
mesmo tamanho uint) será comprimido para HOUR!
4. Para "encher" os arquivos em um arquivo, você terá que manter um grande volume de informações em
muitas informações na memória - haverá HARDWARE!
Eu desaconselho vivamente....
1. MQ não faz funções lentas, e se faz, as otimiza de forma oportuna, com base nas solicitações do servicedesk. Estou de alguma forma confiante de que a CryptEncode voará.
2. Não haverá lentidão. Você não sabe o que uma MQL5 moderna é capaz de fazer em termos de desempenho. Os computadores de hoje têm muita memória. Para baixar e embalar um arquivo de algumas centenas de megabytes é canja, e você não precisa de mais. Para estas são outras tarefas.
Vasiliy!
A embalagem ZIP é necessária?
Acho que não vale a pena.
Eu penso o contrário.
Não, o zip não é interessante como alternativa ao DB. Não é por isso que vale a pena se preocupar com o zíper.
Não tenho nenhum objetivo de criar um análogo do WinZip ou do WinRar. Somente os arquivos mais básicos. Ninguém pensaria sequer em comprimir arquivos maiores do que 4 GB.
1. MQ não faz recursos lentos, e se fizer, otimizará seu trabalho de forma oportuna, com base nas solicitações da central de serviço. Estou de alguma forma confiante de que a CryptEncode voará.
2. Não haverá lentidão. Você não sabe o que uma MQL5 moderna é capaz de fazer em termos de desempenho. Os computadores de hoje têm muita memória. Para baixar e embalar um arquivo de algumas centenas de megabytes é canja, e você não precisa de mais. Para estas são outras tarefas.
Provavelmente estou pensando à moda antiga, mas para mim o arquivamento é interessante para acelerar a transferência de dados na Internet. Localmente com grandes discos rígidos, o tamanho do arquivo perde sua relevância, e o banco de dados será para uma gama limitada de pessoas, e a sua implementação é cara, pois exigirá conhecimentos adicionais do programador e do usuário.
O verdadeiro fecho é significativamente inferior em compressão, especialmente de texto, raro - o que é um pouco triste.
É bem verdade. A comunicação com um servidor de terceiros via WebRequest será muito mais rápida utilizando a embalagem das informações enviadas. Esta é outra idéia porque recarregar a embalagem é uma boa solução.
Entretanto, o zíper é significativamente inferior ao raro em compressão, especialmente de texto - o que é um pouco infeliz.
Apreciar o que nos foi dado. Acredite em mim, a capacidade de trabalhar com o formato de compressão mais popular cobre 90% de todas as tarefas. 80% da redundância é eliminada com sucesso com zíper. O que vem em seguida é perseguir papagaios que ninguém precisa.
Boa viagem!