Если Nano Banana Pro пишет «Unsupported file URI type» или «Invalid or unsupported file uri», не начинайте с переписывания prompt. Чаще всего проблема не в том, что модель внезапно перестала понимать изображения, а в том, что файл так и не дошел до Gemini по правильному файловому маршруту.
Сначала нужно отделить две вещи: что именно вы передали и какая поверхность Gemini это отклонила. Native Gemini file_data, OpenAI-совместимый image_url, Vertex-путь gs://, публичный HTTPS-объект и локальный файловый путь не используют один и тот же URI-контракт. То, что строка выглядит как URI, не делает ее допустимым файловым ресурсом для текущей ветки.
Маршрут за 30 секунд
Главное правило здесь одно: сначала разделите поверхность и тип входа, а уже потом исправляйте. Официальные документы Gemini были перепроверены 9 апреля 2026 года, и текущие рабочие пути по-прежнему разделены: native Gemini использует Files API или files.register, совместимый слой использует image_url, а Vertex живет по собственной объектной логике.
Начните с этой таблицы:
| Что вы передали | Самая вероятная проблема | Самый безопасный первый шаг | Как проверить на том же пути | Когда повышать уровень разбора |
|---|---|---|---|---|
| Публичный HTTPS URL | Вы приняли веб-адрес за native Gemini file resource | На Gemini сначала загрузите файл, либо зарегистрируйте базовый GCS object, если это и есть настоящий источник | Тот же запрос Gemini теперь принимает файл | Возвращенный file resource все еще падает |
data:image/...;base64,... | Либо выбрана не та поверхность, либо base64 был испорчен в пути | Оставьте OpenAI-совместимый image_url и соберите чистый payload заново | Тот же совместимый запрос теперь принимает изображение | Чистый payload все равно падает |
gs://bucket/object | Вы смешали native Gemini и Vertex | На Gemini используйте files.register, на Vertex оставьте gs:// | Та же поверхность теперь принимает объект | Документационно правильный cloud route все еще не работает |
Локальный путь вроде /tmp/a.png или file:///... | Приложение отправило путь устройства как будто это повторно используемый file URI | Сначала загрузите файл и используйте возвращенный resource | Тот же поток теперь работает через валидный file resource | После upload проблема осталась или wrapper переписал запрос |
Важно помнить еще один момент: поддерживаемый формат изображения не гарантирует правильный file route. В текущей документации Gemini указаны PNG, JPEG, WEBP, HEIC и HEIF, но ошибка на этой странице обычно возникает раньше, чем модель вообще получает корректный файловый ресурс.
Если вы используете native Gemini file_data
Native Gemini ожидает не любую строку, похожую на URI, а file resource, который сама экосистема Gemini считает допустимым. Если вставить в file_uri публичную ссылку, локальный путь или старый обходной вариант, который когда-то случайно работал, вы как раз и получаете это семейство ошибок.
Текущие Files API docs описывают маршрут предельно прямо: сначала upload, потом возвращенный file.uri, затем повторное использование этого resource в generate-запросе. Если ваш исходный файл живет в Google Cloud Storage, нынешний Files API reference уже документирует files.register, то есть официальный путь зарегистрировать GCS object как File resource, а не притворяться, будто публичный URL уже им является.
Из-за этого старые ответы на форумах сегодня легко вводят в заблуждение. Вы все еще встретите совет в духе «AI Studio / Gemini не работает с GCS, gs:// только для Vertex». В качестве предупреждения «не путайте поверхности» это еще полезно, но как полное описание текущего контракта уже устарело. Более точная формулировка на 2026 год такая: native Gemini не воспринимает произвольный public URL как file resource, но теперь имеет официальный путь files.register для GCS object.
Есть и еще одна граница, которую легко принять за «вчера работало, а сегодня сломалось». В актуальных Files API docs говорится, что загруженные файлы хранятся 48 часов. Если запрос раньше проходил, а теперь падает похожим образом, не обвиняйте сразу prompt или модель. Сначала проверьте, не используете ли вы просроченный file resource.
Если в итоге выяснится, что проблема уже вышла за рамки этой узкой file-route ошибки и превратилась в более широкий класс сбоев Nano Banana Pro, следующий материал логичнее открыть как гид по кодам ошибок Nano Banana Pro.
Если вы используете OpenAI-совместимый image_url
Эта ветка обманывает чаще всего, потому что одна и та же ошибка может появляться даже тогда, когда сама поверхность выбрана правильно. В текущих Gemini OpenAI compatibility docs по-прежнему есть multimodal-примеры с image_url, включая base64-строки вида data:image/...;base64,.... То есть data: не является «запрещенным везде» форматом. Он просто относится только к compatibility route.
Значит, полезный вопрос здесь не «поддерживает ли Gemini data: URL вообще». На текущий момент поддерживает, если вы действительно находитесь в совместимой ветке. Правильнее спросить: «дошел ли payload до сервера именно в той форме, которую требует этот route?» HTML-escaped base64, wrapper, который переписал content items, совместимый клиент, меняющий структуру поля, все это может выдать тот же unsupported-file-URI symptom, даже когда выбранная поверхность сама по себе верна.
Поэтому порядок исправления здесь такой: сначала подтвердите, что вы действительно используете OpenAI-совместимый вход, затем проверьте, что payload все еще имеет документированную форму image_url, и только потом пересоберите base64 из исходного файла и отправьте запрос заново. Не пытайтесь «починить» compatibility request, подмешивая в него native Gemini file_data. Обычно это просто создает вторую ошибку поверх первой.
Эта ветка заслуживает отдельного раздела именно потому, что текущие треды Google AI Developers Forum уже показывают такой ложный след: пользователь публикует Unsupported file uri: data:image/png;base64,..., и снаружи это выглядит как доказательство «data не работает». Но в тот же день официальные docs продолжают показывать поддержку data: в image_url. На практике это означает не «документация врет», а «ошибка может означать либо неверный route, либо испорченный payload при правильном route».
Если ваш вход — GCS object, public URL или Vertex path
Публичный URL, зарегистрированный Gemini file и Vertex gs:// — это не одно и то же. Короткие ответы обычно чинят только половину проблемы и на этом заканчивают.
Если вы находитесь на native Gemini и передаете публичный HTTPS object URL, вы, скорее всего, перепутали «объект доступен по сети» с «Gemini уже владеет этим file resource». Это разные утверждения. URL может открываться в браузере и при этом быть недопустимым для native Gemini file_data. Более надежный путь остается тем же: загрузить файл через Files API или, если настоящий source of truth живет в GCS, зарегистрировать базовый объект через files.register, а не тестировать его веб-обертку как будто это уже file resource.
На Vertex AI логика другая. Там gs://bucket/object действительно может быть ожидаемой формой. Ошибка начинается в тот момент, когда этот опыт механически переносят обратно в native Gemini и начинают считать, будто все «гугловские» image-сценарии обязаны делить один и тот же объектный URI-контракт. Они его не делят.
Поэтому в этой ветке полезнее всего ответить не на вопрос «работает ли GCS вообще», а на вопрос «какая поверхность сейчас владеет запросом». Если это native Gemini, двигайтесь к upload или files.register. Если это Vertex, оставляйте Vertex-объектный путь. Если вы просто вставили public URL потому, что он выглядел как URI, остановитесь и превратите его в file resource, который текущая поверхность действительно умеет читать.
Именно поэтому фраза «GCS в Gemini вообще не работает» сегодня слишком груба. Старые треды отражали реальную боль, но официальный контракт с тех пор изменился. Более точная формулировка сейчас такая: произвольный public URL все еще не является native Gemini file URI, но для GCS object уже есть официальный регистрационный путь.
Если приложение передало локальный файловый путь
Локальный путь кажется убедительным, потому что он действительно указывает на существующий файл. Но /tmp/example.png, file:///storage/... и похожие device-side paths — это ссылки внутри вашего устройства или процесса, а не повторно используемые file resources, которые Gemini сможет потом забрать сама.
Самое безопасное правило для всех платформ одинаково: сначала upload. Как только файл станет Gemini-managed resource, вы сможете ссылаться на него так, как текущие docs и ожидают. До этого локальный путь доказывает лишь то, что файл виден вашему приложению, но не доказывает, что текущая поверхность Gemini может использовать его как внешний resource.
Именно здесь легко утонуть в частных кейсах мобильных SDK и wrapper-ов. Да, бывают нюансы вокруг content:// и других клиентских схем. Но они не должны захватывать основную линию статьи. Пока первичный route не исправлен, переход к частным клиентским исключениям обычно только тратит время.
Правильный порядок обратный: сначала загрузите файл, потом подтвердите, что возвращенный resource работает на том же path, и лишь затем разбирайте клиентские URI-детали или поведение wrapper-а, если проблема пережила first-party correction. Если ошибка после этого уже относится к более широкому классу, разумный следующий шаг — хаб по отладке Nano Banana Pro.
Как проверить исправление и что подозревать дальше
Если ошибка исчезла один раз, это еще не значит, что проблема закрыта. Более надежная последовательность выглядит так:
- Меняйте только один минимальный file-route шаг и повторяйте запрос на том же самом пути.
- Проверяйте, что тот же запрос теперь не только принимает файл, но и действительно выполняет ту задачу, ради которой вы его запускали.
- Если вы загружали или регистрировали файл раньше, проверьте, не истек ли этот resource.
- Если route уже явно правильный, а ошибка осталась, переходите к base64 integrity, wrapper-модификациям запроса и stale client code.
Самая важная граница здесь — что не стоит обвинять слишком рано. Эта ошибка чаще всего не означает, что Nano Banana Pro внезапно перестал обрабатывать изображения. Обычно это означает, что изображение так и не попало к модели по поддерживаемому route. Только после того как route выровнен, есть смысл переходить к payload corruption, resource expiry и platform-specific behavior.
Если вы уже прошли file-route этап и понимаете, что проблема сместилась в другой класс image-сбоев, следующий логичный материал — гид по частым ошибкам Gemini image API.
FAQ
Можно ли напрямую передать public HTTPS URL в native Gemini file_data?
Как правило, нет. Публичный объектный URL не равен Gemini File resource. Для native Gemini надежнее сначала upload, либо files.register, если настоящий источник — GCS object.
Поддерживается ли data:image/...;base64,... вообще?
Да, но только на OpenAI-совместимой ветке image_url. По состоянию на 2026-04-09 актуальные docs Gemini все еще показывают такую форму. Если ошибка возникает и там, сначала проверяйте целостность payload, а не объявляйте весь route неподдерживаемым.
Можно ли передать локальный путь вроде /tmp/a.png или file:///...?
Не так, будто это уже повторно используемый Gemini file URI. Для межплатформенного сценария безопаснее сначала загрузить файл, а потом работать с возвращенным resource.
Заменяет ли files.register обычный upload?
Нет. Это официальный путь для GCS object, но локальные файлы по-прежнему сначала нужно загружать.
Что делать, если route уже исправлен, а ошибка не исчезла?
Тогда проблема, скорее всего, уже не чисто маршрутизационная. Проверяйте corrupted base64, истекшие file resources и wrapper / SDK, которые переписали запрос по дороге.
Запомните это правило
Самое быстрое чистое исправление — не «переписать prompt» и не «конвертировать все подряд в PDF». Самое быстрое исправление — понять текущую поверхность, перевести файл на route, который эта поверхность действительно поддерживает, повторить проверку на том же path и только потом переходить к payload, просроченным resources или платформенному поведению, если ошибка остается.