O KMZ não abre: leia o aviso, depois corrija o arquivo
Resposta curta: um KMZ é um arquivo KML dentro de um zip, então o pacote só pode ser uma de quatro coisas, o visualizador diz qual, e três das quatro se resolvem com um comando. O caso que pega mais gente é o pacote renomeado — o arquivo está bom, e o nome não está.
Testado em 2 de outubro de 2026 no visualizador de KMZ, nos três idiomas da interface, com todos os arquivos de teste montados a partir dos comandos no fim deste post. Toda string citada abaixo é a da própria ferramenta. Cada caso aqui mostra ou um aviso vermelho e nenhuma camada, ou uma camada com a linha de contagens e nenhum aviso — nunca os dois, então a tela já diz em qual metade deste post você está.
Um KMZ é um zip, então leia a listagem primeiro
unzip -l site.kmz é o primeiro movimento, e o guia de KML e KMZ diz o mesmo, na seção "Abrir e visualizar um KMZ online sem o Google Earth". Este post é o que fazer com cada uma das quatro respostas dela: uma entrada KML sob um nome .kmz, uma entrada KML sob outro nome qualquer, nenhuma entrada KML, ou uma listagem que falha porque a coisa não é um pacote.
O controle para tudo o que vem abaixo é um pacote montado à mão: um doc.kml com um ponto, uma linha e um polígono, zipado com zip -X site.kmz doc.kml. Ele abre sem aviso nenhum, o painel de camadas mostra 1 polígono · 1 linha · 1 ponto, e a camada vem rotulada com o nome do documento do próprio KML, não com o nome do arquivo. Essa é a cara de um sucesso — uma linha de contagens, nada em vermelho.
O .zip renomeado: o nome decide, não os bytes
Copie esse mesmo pacote para um segundo nome com cp site.kmz site.zip e você tem dois arquivos byte a byte idênticos. O .kmz abre. O .zip é recusado, e o aviso diz Este ZIP contém um arquivo KML. Renomeie para .kmz, ou extraia o .kml, e carregue novamente.
É só isso: o carregador decide o que um arquivo é pela extensão antes que qualquer coisa leia um byte, e .zip quer dizer shapefile zipado. Então o seu pacote vai para o parser de shapefile, que o recusa — não existe .shp ali dentro. Mas o que você lê não é a reclamação desse parser: tendo sido recusado, o visualizador reabre o pacote, vê que ele de fato contém um KML, e reformula a recusa como o reparo de que você precisa. O arquivo continua recusado; a frase é sobre o seu arquivo, e não sobre shapefiles.
É o nome que faz todo esse trabalho, o que fica mais claro visto do outro lado. O carregador tem uma segunda porta de entrada — buscar um arquivo a partir de um link — e ela não passa nome de arquivo nenhum adiante: inventa um, remote.kmz quando o link termina em .kmz ou quando a resposta se declara um zip, e então chama o mesmo despacho. Os mesmos bytes seriam aceitos sob o nome inventado e recusados sob o seu, então o ramo do .zip é inalcançável por esse caminho. Um despacho, duas portas de entrada, um nome que ninguém escolheu. Essa inconsistência é nossa e está na nossa lista, em vez de corrigida; e também não é uma saída, porque o visualizador não tem campo para colar um link. Corrigir o nome é o reparo.
Um zip sem nenhum KML dentro
Monte um com zip -X nokml.kmz readme.txt e solte no visualizador. O aviso diz Nenhum arquivo KML encontrado dentro do ZIP.
Este se chama .kmz, então o caminho do KMZ rodou mesmo: o pacote abriu, o visualizador percorreu as entradas, e não havia nada para interpretar. O aviso anterior pode ser mais específico porque lá ele encontrou alguma coisa.
Um KML aninhado abre, e isso surpreende as pessoas
Coloque o KML em qualquer lugar que não seja a raiz — mkdir layers && cp doc.kml layers/site.kml && zip -X nested.kmz layers/site.kml — e o pacote não tem nenhum doc.kml e nenhuma entrada no nível da raiz. Ele abre. Nenhum aviso, a mesma linha de contagens 1 polígono · 1 linha · 1 ponto, o mesmo nome de documento na camada.
A regra que o visualizador aplica é a primeira entrada cujo nome termina em .kml, em qualquer lugar do pacote, abaixo da raiz ou não, passada para minúsculas antes desse teste, então DOC.KML também abre. Um doc.kml na raiz do pacote é uma convenção — a do Google Earth, e um bom hábito para um arquivo que você entrega a outra pessoa — não algo que este visualizador exija. Se o seu KMZ foi recusado, a profundidade em que o KML está não é o motivo.
Não é um zip, ou não é uma extensão que o visualizador conheça
head -c 512 /dev/urandom > broken.kmz cria um arquivo com nome de KMZ e nenhum pacote dentro. O aviso diz Erro ao processar o arquivo. Verifique se o arquivo é um KML ou KMZ válido. Um download truncado cai aqui, e também cai uma página de erro que o servidor devolveu com o nome que você pediu: file broken.kmz responde data em vez de nomear um pacote zip, e unzip -l nele falha de saída.
Copie esses mesmos bytes para broken.dat, ou para um nome sem extensão nenhuma, e a resposta muda para Tipo de arquivo não suportado. Use KML ou KMZ. Nada leu os bytes desta vez: a extensão é checada duas vezes, uma para escolher o parser e outra dentro do caminho do KML, e uma que nenhuma das duas checagens reconhece é recusada antes de qualquer tentativa de interpretação.
Corrigindo, de três maneiras
- Renomeie de volta:
mv site.zip site.kmz, e então solte no visualizador de novo. Para um pacote renomeado esse é o reparo inteiro. - Remonte o pacote:
zip -X site.kmz doc.kml, a partir do diretório que contém o KML. Use isso quando o zip veio de algum lugar que você não controla. - Pule o contêiner:
unzip -o site.kmz '*.kml'e carregue o.kmlextraído no lugar dele. O visualizador aceita um KML puro, e ounzipignora o nome do pacote, então isso funciona no arquivo renomeado também.
Nenhum desses converte nada, porque nenhuma dessas falhas é sobre o conteúdo. Para as que são — atributos perdidos na leitura, estilos perdidos na conversão — a seção "Erros, decodificados" do guia tem as transcrições.
Arquivos de teste que você pode usar
Nada é hospedado; cada arquivo de teste é um ou dois comandos. Monte o KML primeiro, como um doc.kml em UTF-8: <?xml version="1.0" encoding="UTF-8"?>, depois <kml xmlns="http://www.opengis.net/kml/2.2"><Document><name>KMZ test</name>, depois os três placemarks, depois </Document></kml>. As coordenadas são graus decimais de propósito.
<Placemark><name>P1</name><Point><coordinates>-46.633,-23.550,0</coordinates></Point></Placemark><Placemark><name>L1</name><LineString><coordinates>-46.64,-23.55,0 -46.63,-23.54,0</coordinates></LineString></Placemark><Placemark><name>A1</name><Polygon><outerBoundaryIs><LinearRing><coordinates>-46.65,-23.56,0 -46.64,-23.56,0 -46.64,-23.55,0 -46.65,-23.56,0</coordinates></LinearRing></outerBoundaryIs></Polygon></Placemark>
Depois os seis pacotes, em ordem: o controle, zip -X site.kmz doc.kml · os mesmos bytes sob um segundo nome, cp site.kmz site.zip · um pacote sem nenhum KML dentro, printf 'no KML here\n' > readme.txt && zip -X nokml.kmz readme.txt · um KML abaixo da raiz, mkdir layers && cp doc.kml layers/site.kml && zip -X nested.kmz layers/site.kml · algo que não é um pacote, head -c 512 /dev/urandom > broken.kmz · e esse mesmo não-pacote sob uma extensão desconhecida, cp broken.kmz broken.dat. Confira um antes de tudo: unzip -l nested.kmz lista uma única entrada, layers/site.kml.
Para times
"O KMZ não abre" costuma ser um problema de passagem de bastão, e não um problema de arquivo: o pacote foi renomeado para passar por um filtro de e-mail, ou remontado por uma ferramenta que mudou o KML de lugar, e quem precisa abrir não é quem fez. O Geodocs mantém os dados de campo em um único mapa compartilhado, em vez de um KMZ por celular, então não há pacote para renomear e nada para zipar de novo.