Советник EA может получать API-данные в демо, но не получать эквивалентных ответов в тестере. Это не обязательно отказ сервера. До проверки архива установите доступность функции в испытательной среде. Подстановка сегодняшнего значения в прежнее решение создает другой тест. Ниже явно воспроизводятся версии, исправления отделяются от недоступности; внешнего соединения с API нет.
Почему рабочего WebRequest недостаточно для бэктеста?
Документация MQL5 указывает, что WebRequest не выполняется в Strategy Tester. Добавление адреса в разрешенные URL терминала не снимает ограничение. Отделяйте недоступную функцию среды от сетевой ошибки, отказа авторизации и ответа обычного запущенного EA.
Если правило использует внешнее экономическое наблюдение, не заменяйте неуспешный запрос нулем. Ноль может быть допустимым значением, а ошибка означает отсутствие входа. Замены WebRequest файлом тоже недостаточно, если файл содержит исправления, еще неизвестные во время прежнего решения.
До соединения сигнальной логики с HTTP определите наблюдение, версию, значение и время доступности. Материал о простом EA (на английском) разделяет данные, решение и исполнение; здесь разбирается слой данных. Другой адаптер не должен молча менять смысл входа или реакцию на его отсутствие.
Как разделить получение online и воспроизведение offline?
Адаптер online обрабатывает ответ поставщика. Тестовый адаптер выбирает сохраненную запись, доступную к моменту решения. Оба передают логике сопоставимые состояния: допустимое значение, явную недоступность или ошибку. Это предложенная организация кода, не готовый торговый робот и не обещание совместимости с любым API.
Сохраняйте исходные ответы отдельно от подготовленных записей. Укажите источник, версию схемы, время получения и основание доступности. Период, описываемый наблюдением, не равен моменту, когда его узнали. Если известна только дата версии, не придумывайте точный час публикации. Дневной архив сам по себе не устанавливает внутридневную доступность.
FRED описывает real-time periods, разделяя сведения, известные сейчас и в прошлом. Это пример версионных данных, не универсальный API Forex. Дата vintage автоматически не задает точную UTC-секунду публикации. До подготовки внутридневного входа установите хронологию конкретного источника.
В MQL5 FileOpen использует выделенную файловую область, в том числе при тестировании. Относительный путь не обязан вести в обычную папку терминала. Проверьте успешность открытия и чтения. Отсутствующий вход должен давать распознаваемую недоступность, а не пустую таблицу, принятую за полную историю.
Какую версию может использовать прежнее решение?
Учебная история трех ответов
Зададим вымышленное наблюдение GDP-model 1 октября 2026 года. Это не публикации ВВП и не записи настоящего API. Все времена — UTC. availableAt обозначает момент доступа в нашей модели, не момент исполнения ордера.
Прокрутите таблицу вправо, чтобы увидеть все столбцы →
| availableAt | revision | value |
|---|---|---|
| 2026-10-01T12:00:00Z | initial | "1.0" |
| 2026-10-01T13:00:00Z | revised | "1.4" |
| 2026-10-01T14:00:00Z | unavailable | null |
В 12:30 последнее допустимое значение — 1.0; в 13:30 — 1.4. В 14:30 последняя доступная запись содержит null, поэтому вход недоступен. Модель не возвращает старое 1.4 и не заменяет отсутствие нулем.
Версия, доступная тогда, а не сегодня
Прокрутите схему вправо, чтобы увидеть ее целиком →
Условное правило «значение больше 1.2» в 12:30 ложно. Подстановка более позднего 1.4 изменит это решение даже при прежних ценовых данных. Здесь проверяется доступность информации, не прибыльность стратегии. Инструмент выбирает запись и не рассчитывает торговый сигнал или доходность.
Если стратегия должна сохранять последнее известное значение после сообщения о недоступности, задайте это отдельной политикой. До оценки результатов укажите допустимый возраст и причину использования старой записи. Вариант с явным null ниже такого возврата не реализует. Нельзя добавить его после удачного результата и назвать повтор неизмененным.
Что можно проверить в локальном воспроизведении?
Вставьте объект JSON с числовой version 1 и массивом events. В событии ровно четыре поля: availableAt, observation, value и revision. Формат времени — YYYY-MM-DDTHH:mm:ssZ без долей секунды и других смещений. observation и revision — строки, value — числовой текст с десятичной точкой или null, без преобразования в Number. Пределы: 1–200 событий и 64 КиБ JSON; observation и value до 128 единиц UTF-16, revision до 64. Ниже используются точно те же ограничения уже проверенного компонента.
Воспроизведение доступных версий данных
Задайте учебные события и время решения. Модель выбирает для каждого наблюдения последнюю запись, которая уже доступна к этому моменту. Более поздняя версия не меняет входные данные прежнего решения. Значение null означает явную недоступность: модель не подставляет ноль и не возвращается к старому значению.
Проверка работает локально в браузере: без обращения к счету, API или внешнему архиву и без постоянного сохранения введенного текста. Не вводите пароли и личные сведения. Время в файле — ваше утверждение; инструмент не подтверждает, когда источник действительно опубликовал данные.
Формат и ограничения
Корневой объект содержит числовую version: 1 и массив events из 1–200 событий. У каждого события ровно четыре поля: availableAt, observation, value, revision. Время указывается в UTC строго как YYYY-MM-DDTHH:mm:ssZ, без долей секунды и иных смещений.
observation — непустая строка длиной до 128 единиц UTF-16; revision — непустая строка до 64. Метки версий не задают порядок выбора. value — null либо строка длиной до 128 с цифрами ASCII, необязательным знаком и десятичной точкой: например, "0.00", "+01.20", "-0". Запятая, экспонента и числовое JSON-значение вместо строки здесь не подходят. Текст значения не преобразуется в JavaScript Number и не вычисляется.
Предел JSON — 65 536 байт UTF-8, глубина восемь уровней и 2000 значений. Поле ввода дополнительно ограничено 65 536 символами; многобайтовый текст может достичь байтового предела раньше. Повторяющиеся и небезопасные ключи отклоняются. Два события с одинаковыми observation и availableAt неоднозначны и отклоняются независимо от порядка строк.
TXT содержит полный результат и введенные метки событий; числовое поле at в нем — техническое время UTC в миллисекундах от начала эпохи Unix. Перед сохранением или передачей проверьте личные сведения. Внутренние ключи, replay и коды значений в машинном результате сохраняются для сопоставления.
Для проверки и скачивания нужен JavaScript. Полный начальный JSON и разобранные примеры доступны ниже без запуска формы.
Полный начальный JSON — доступен без JavaScript
{
"version": 1,
"events": [
{
"availableAt": "2026-10-01T12:00:00Z",
"observation": "GDP-model",
"value": "1.0",
"revision": "initial"
},
{
"availableAt": "2026-10-01T13:00:00Z",
"observation": "GDP-model",
"value": "1.4",
"revision": "revised"
},
{
"availableAt": "2026-10-01T14:00:00Z",
"observation": "GDP-model",
"value": null,
"revision": "unavailable"
}
]
}Три версии одного учебного наблюдения
Это вымышленный GDP-model 1 октября 2026 года, а не публикация ВВП и не ответ настоящего API. В 12:00 UTC доступно "1.0", в 13:00 — "1.4", в 14:00 — null. В 12:30 выбирается первая запись, в 13:30 — исправленная, в 14:30 — недоступность. Ровно в 13:00 вторая запись уже доступна: граница включается.
Для отдельного условного правила «значение больше 1.2» число 1.0 дает ложь, а более позднее 1.4 — истину. Подстановка исправления в 12:30 изменила бы решение при тех же ценах. Сам инструмент сигнал не вычисляет и доходность стратегии не оценивает.
Доступный ноль и отсутствие данных — разные состояния
Дополнительный вымышленный пример содержит два наблюдения и намеренно перемешанные строки. В 12:30 UTC для A-model выбирается "0.00", появившееся ровно в момент решения: это доступное значение. Для B-model выбирается null от 12:20; ни старое 7.0, ни будущее 8.0 не подставляются. У B-model остается одна будущая запись, у A-model — ни одной. Буквенные метки a, b, z не являются счетчиком времени.
JSON дополнительного примера — скопируйте в форму и оставьте 12:30 UTC
{
"version": 1,
"events": [
{
"availableAt": "2026-10-01T13:00:00Z",
"observation": "B-model",
"value": "8.0",
"revision": "a"
},
{
"availableAt": "2026-10-01T12:20:00Z",
"observation": "B-model",
"value": null,
"revision": "b"
},
{
"availableAt": "2026-10-01T12:30:00Z",
"observation": "A-model",
"value": "0.00",
"revision": "a"
},
{
"availableAt": "2026-10-01T12:00:00Z",
"observation": "B-model",
"value": "7.0",
"revision": "z"
}
]
}Что эта проверка не устанавливает
Сначала проверьте происхождение архива и доказательства доступности каждой версии. Период наблюдения не равен времени публикации; из одной календарной даты нельзя придумывать точную UTC-секунду. FRED различает сведения, известные сейчас и в прошлом, но его даты версий сами по себе не доказывают точную внутридневную доступность.
В MQL5 функция WebRequest недоступна в Strategy Tester. FileOpen работает в выделенной файловой области; у агента тестирования она отличается от обычной папки терминала. Это основания отделять получение данных от их воспроизведения, а не доказательство правильности конкретного файла. Здесь не запускаются MQL5, терминал, HTTP-запросы или торговые операции.
Выбор версии не воспроизводит Bid/Ask, комиссии, объем, задержку и исполнение. Если требуется использовать последнюю известную величину после сообщения о недоступности, задайте отдельную политику возраста и причин отсутствия заранее. В этой модели такой политики нет.
Вопросы о результате
Почему последняя запись файла может отличаться от выбранной?
Она может появиться после времени решения. Столбец показывает ее для сравнения; это не разрешение использовать будущие сведения.
Означает ли корректный JSON подлинный архив?
Нет. Проверяется соответствие формату и ограничениям, а не происхождение и достоверность объявленных времен. Неверная дата даст логически правильный выбор из неверных предпосылок.
Нужно ли менять null на ноль?
Нет. Доступное числовое текстовое значение ноль и явно недоступная версия различаются. В этой модели null блокирует оценку нового сигнала.
Заменяет ли TXT отчет тестера?
Нет. Это локальный результат отбора версий по введенным событиям, а не журнал исполнения сделок или проверка прибыльности.
Контекст исходной статьи: воспроизведение API-данных в тесте — на английском.
Отдельно задайте decisionAt в том же формате UTC. Для каждого наблюдения выбирается последняя версия с availableAt не позже решения. До первой записи значения нет. Два события одного наблюдения с одинаковым временем неоднозначны и отклоняются, а не разрешаются порядком вставки. Метка revision не является числовым счетчиком хронологии.
Упражнение работает локально с вставленными событиями, не загружая публикации и не используя ключи API. Оно не проверяет время поставщика. Корректный JSON не доказывает подлинного архива. Если время угадано или поздним исправлениям назначено время первоначальной публикации, правильный алгоритм воспроизведет неправильные предпосылки. Для реального исследования сохраняйте происхождение данных.
Документация тестера отделяет файлы и среду агента от терминала. Для параллельных запусков используйте фиксированную копию набора, не перезаписывая ее живым ответом во время исследования. В манифесте запуска сохраняйте реальную версию набора, не одно имя endpoint.
Материал о бэктесте в Python (на английском) развивает соединение по времени, а материал об экономическом календаре (на английском) — исправления публикаций. Воспроизведение данных автоматически не воспроизводит исполнение: Bid/Ask, расходы, количество и ответы сервера остаются отдельными частями. Сначала сравните несколько решений без сделок, затем объясняйте различие результата стратегии.
Что сделать до оценки результатов этого EA?
- Запишите контракт данных и отделите online от offline. Сохраните исходные ответы, смысл наблюдений и основания доступности. Недостающие исторические версии отметьте ограничением вместо подстановки сегодняшнего ответа в прошлую дату.
- Проследите одно учебное наблюдение до первой версии, между публикацией и исправлением и после явной недоступности. Сопоставьте выбор с таблицей. До большого исследования проверьте точную включенную границу и конфликт одинаковых времен.
- В тестере подтвердите чтение нужного файла и распознавание отсутствующих данных. Храните версию набора с отчетом. После объяснения расхождений отдельно проверяйте сигналы, исполнение и расходы. Корректный replay входа не устанавливает будущую прибыльность.
Близкие текстовые значения, ноль и недоступность
Новый полностью условный набор. Два наблюдения ниже не являются котировками или публикациями. У Rate-model первая строка доступна в 09:00:00 UTC, следующая — ровно через секунду, затем в 09:01:00 появляется null. У Zero-model единственная версия содержит строку "-0" и доступна в 09:00:01. Буквенные метки версий не задают время. Значения передаются текстом; инструмент не вычисляет торгового порога.
{
"version": 1,
"events": [
{"availableAt":"2026-10-02T09:00:01Z","observation":"Rate-model","value":"1.200000000000000002","revision":"a"},
{"availableAt":"2026-10-02T09:00:00Z","observation":"Rate-model","value":"1.200000000000000001","revision":"z"},
{"availableAt":"2026-10-02T09:01:00Z","observation":"Rate-model","value":null,"revision":"b"},
{"availableAt":"2026-10-02T09:00:01Z","observation":"Zero-model","value":"-0","revision":"v0"}
]
}Скопируйте JSON в существующую форму и поочередно задайте 09:00:00,09:00:01 и 09:01:00 того же условного дня с полным UTC-форматом. На первой границе выбирается первая строка Rate-model, а Zero-model еще не имеет записи. Через секунду выбирается вторая Rate-model и доступный текст "-0" у Zero-model. После 09:01 Rate-model недоступен, а Zero-model сохраняет свою единственную допустимую запись. Это не возврат за null: у Zero-model последующей null-записи нет.
Две длинные строки Rate-model различаются на 10⁻¹⁸. Если принудительно преобразовать их в обычный JavaScript Number, обе могут отобразиться как 1.2. Здесь значения не преобразуются: в результате и TXT сохраняется точный текст выбранной версии. Это пример границы представления, не ошибка проверенного компонента и не рекомендация сравнивать экономические величины как строки.
Добавление еще одной строки того же Rate-model с тем же availableAt 09:00:01 и другим значением делает набор неоднозначным и должно отклоняться. Простое изменение порядка исходных четырех строк выбор не меняет. При исправлении ввода прежний TXT становится неактуальным: повторите проверку, а перед передачей файла проверьте введенные метки. Никакие реальные API-данные или ключи для примера не нужны.