Por que o arquivo IFC não abre ou abre pela metade?

Um IFC que não abre não é entrega — é anexo quebrado.

O coordenador recebe o arquivo da disciplina, importa no viewer ou no servidor de modelos, e o software rejeita. A mensagem varia — "file corrupted", "unexpected end of file", "invalid STEP syntax", "encoding error", "unable to parse" — mas o efeito é sempre o mesmo: o modelo não carrega. Nenhuma geometria, nenhuma propriedade, nenhuma entidade. O arquivo existe no disco, tem extensão .ifc, pesa dezenas ou centenas de megabytes, mas não funciona.

Em casos menos evidentes, o IFC abre parcialmente: o viewer renderiza parte da geometria, mas interrompe no meio. Faltam andares inteiros, disciplinas que deveriam estar no arquivo não aparecem, a árvore espacial para num IfcBuildingStorey e o resto some. O usuário descreve como "modelo cortado", "IFC pela metade", "só aparece o térreo". O arquivo não está íntegro — foi truncado durante a exportação, a transferência ou o armazenamento.

Este problema é distinto da não conformidade ao schema (dor que trata validação contra o schema IFC, entidades inválidas, atributos fora de cardinalidade). Aqui o arquivo sequer chega ao ponto de ser validado semanticamente — ele falha na leitura sintática. A serialização STEP (ISO 10303-21) que codifica o IFC está corrompida, ou o arquivo não é STEP válido de início.

As causas mais frequentes são mundanas: exportação interrompida (o software travou, o disco encheu, o processo foi cancelado antes de finalizar), transferência que truncou o arquivo (download parcial, upload incompleto ao CDE, cópia interrompida em rede instável), encoding incompatível (caracteres especiais no caminho do arquivo, BOM inválido, charset não ISO-8859-1 nem UTF-8 no cabeçalho STEP), ou corrupção silenciosa no armazenamento (bit flip em disco, compressão/descompressão que alterou bytes).

O problema é grave porque um IFC que não abre bloqueia toda a cadeia downstream: coordenação, quantitativo, auditoria, clash detection, verificação IDS — nada acontece até que exista um arquivo legível. E porque a causa raramente é investigada: a equipe pede "manda de novo" e o projetista re-exporta sem entender o que falhou. O ciclo se repete até que alguém resolva a causa raiz.

1. 1

   Viewer rejeita o arquivo com erro de parsing · BIMvision, BIMcollab Zoom, Solibri, xBIM Xplorer, FreeCAD, BlenderBIM — qualquer viewer STEP/IFC retorna erro na leitura. Mensagens típicas: "unexpected end of file", "invalid STEP physical file", "parse error at line N", "file is not a valid IFC".

2. 2

   Arquivo abre mas a geometria está incompleta · o viewer carrega parte do modelo e para. A árvore espacial (IfcProject > IfcSite > IfcBuilding > IfcBuildingStorey) aparece truncada. Andares, disciplinas ou conjuntos inteiros de elementos estão ausentes. O arquivo foi cortado antes de finalizar a serialização.

3. 3

   Tamanho do arquivo suspeitamente pequeno · o IFC deveria ter 200 MB com base no porte do modelo, mas o arquivo recebido tem 14 MB. Sinal direto de truncamento — a exportação ou a transferência interrompeu antes de concluir.

4. 4

   Caracteres estranhos no início do arquivo · ao abrir o .ifc num editor de texto, o cabeçalho STEP (ISO-10303-21; HEADER; ...) não aparece limpo. Há bytes estranhos antes do ISO-10303-21, BOM UTF-8 onde não deveria haver, ou o encoding do corpo mistura charsets.

5. 5

   O mesmo arquivo abre em um viewer e não abre em outro · sinal de que a corrupção é parcial ou de que o parser de um viewer é mais tolerante que o de outro. Não significa que o arquivo está correto — significa que um viewer ignorou o erro e o outro não.

6. 6

   Re-exportação resolve temporariamente · o projetista exporta de novo e o novo arquivo abre. Mas na semana seguinte o problema volta. A causa raiz (disco cheio, rede instável, processo cancelado, encoding do caminho) não foi tratada.

1. 1

   Exportação interrompida · o software de autoria travou, o disco encheu ou o usuário cancelou o processo antes de o exportador finalizar a escrita do arquivo STEP. O resultado é um arquivo truncado — a seção DATA não fecha com END-ISO-10303-21;, e o parser rejeita.

2. 2

   Transferência que truncou o arquivo · download parcial do CDE, upload incompleto (timeout, queda de conexão), cópia por rede instável (VPN, Wi-Fi intermitente), descompressão de ZIP corrompido. O arquivo que chega ao destino tem bytes a menos que o original.

3. 3

   Encoding incompatível no cabeçalho ou no caminho · a serialização STEP (ISO 10303-21) espera ISO-8859-1 ou UTF-8 declarado. Caracteres especiais no caminho do arquivo (acentos, cedilha, espaços, caracteres CJK) podem corromper o cabeçalho em alguns exportadores. BOM (Byte Order Mark) inserido por editores de texto invalida o início do arquivo.

4. 4

   Referência interna quebrada (EntityInstance inexistente) · o arquivo STEP referencia uma EntityInstance por ID numérico (#12345) que não existe no corpo do arquivo. Pode acontecer por edição manual do IFC, por merge mal feito de arquivos parciais, ou por bug do exportador que omitiu entidades dependentes.

5. 5

   Serialização STEP sintaticamente inválida · o exportador gerou linhas STEP mal formadas: ponto-e-vírgula ausente no final de instância, parênteses desbalanceados, aspas não fechadas em strings, tipos enumerados fora do schema. O parser rejeita na leitura sintática antes de qualquer validação semântica.

6. 6

   Corrupção silenciosa no armazenamento · bit flip em disco sem ECC, arquivo comprimido e descomprimido por ferramenta que alterou bytes, armazenamento em nuvem que corrompeu durante sincronização. O arquivo muda sem que ninguém tenha tocado nele.

7. 7

   Edição manual do IFC que introduziu erro · alguém abriu o .ifc num editor de texto para "corrigir" um valor, salvou com encoding errado, quebrou uma linha longa, ou deletou uma entidade sem remover as referências a ela. Edição manual de STEP sem parser é operação de alto risco.

1. 1

   Bloqueio total da cadeia downstream · coordenação, clash detection, extração de quantitativos, auditoria IDS, verificação de conformidade — nada começa enquanto o arquivo não abrir. Um IFC corrompido trava o cronograma inteiro de coordenação.

2. 2

   Retrabalho de re-exportação sem diagnóstico · a equipe pede "manda de novo", o projetista re-exporta, o novo arquivo pode ou não funcionar. Sem diagnóstico da causa, o ciclo se repete — custo acumulado de tempo e rede.

3. 3

   Entrega contratual invalidada · se o BEP exige entrega em IFC e o arquivo não abre, a entrega não existe formalmente. Medições podem ser travadas, penalidades contratuais podem ser acionadas.

4. 4

   Perda de confiança no formato · a equipe conclui que "IFC dá problema" e passa a trocar modelos em formato nativo proprietário. O problema era a integridade do arquivo, não o formato — mas a percepção já contaminou.

5. 5

   Dados irrecuperáveis se o modelo nativo não existir mais · se o autor perdeu o arquivo nativo ou mudou de versão do software e não consegue re-exportar, o IFC corrompido pode ser a única cópia do modelo. Sem ferramenta de recuperação, a informação está perdida.

6. 6

   Corrupção parcial não detectada · o IFC abre mas faltam elementos. Se ninguém confere a completude (contagem de entidades, andares presentes, disciplinas esperadas), a coordenação avança sobre modelo incompleto e os erros aparecem em fase posterior.

Todos os testes abaixo podem ser executados pelo BIM Manager ou coordenador com ferramentas gratuitas ou scripts simples. Nenhum exige software proprietário.

# Via Python — checar os primeiros bytes
with open('modelo.ifc', 'rb') as f:
    head = f.read(64)
    if head[:3] == b'\xef\xbb\xbf':
        print('AVISO: BOM UTF-8 detectado — pode causar falha de parsing')
    if b'ISO-10303-21' not in head:
        print('ERRO: cabeçalho STEP ausente nos primeiros 64 bytes')
    else:
        print('Cabeçalho STEP presente')

import ifcopenshell
try:
    ifc = ifcopenshell.open('modelo.ifc')
    print(f'Arquivo aberto: {len(ifc.by_type("IfcProduct"))} produtos')
except Exception as e:
    print(f'ERRO ao abrir: {e}')

import ifcopenshell
ifc = ifcopenshell.open('modelo.ifc')
storeys = ifc.by_type('IfcBuildingStorey')
print(f'Pavimentos encontrados: {len(storeys)}')
for s in storeys:
    print(f'  {s.Name} (elevation: {s.Elevation})')
# Contagem geral por tipo
for t in ['IfcWall', 'IfcSlab', 'IfcBeam', 'IfcColumn', 'IfcDoor', 'IfcWindow']:
    print(f'{t}: {len(ifc.by_type(t))}')

# No terminal (macOS/Linux)
shasum -a 256 modelo.ifc
# Comparar com o hash do arquivo recebido no destino

O problema é considerado resolvido quando todos os itens abaixo forem verdadeiros:

Curto prazo (destravar a entrega bloqueada):

1. Diagnosticar a causa da falha. Executar os Testes 1 a 4 do Bloco 06 para determinar se o arquivo foi truncado, tem encoding inválido, tem referência quebrada ou tem sintaxe STEP mal formada. O diagnóstico determina se a solução é re-exportar ou se há possibilidade de recuperação.

2. Re-exportar com monitoramento. Pedir ao projetista que re-exporte o IFC com atenção a: disco com espaço livre suficiente, processo de exportação completado até o final (sem cancelamento), caminho do arquivo sem caracteres especiais (sem acento, sem cedilha, sem espaço). Após a exportação, executar Teste 1 (terminador STEP) e Teste 4 (IfcOpenShell) antes de enviar.

3. Verificar a integridade da transferência. Gerar hash SHA-256 no momento da exportação (Teste 6). Após upload ao CDE, comparar o hash do arquivo recebido. Se divergem, a transferência corrompeu — repetir com conexão estável.

4. Tentar recuperação se re-exportação não for possível. Se o modelo nativo não está mais disponível ou o software de autoria mudou de versão, tentar abrir com IfcOpenShell em modo tolerante ou com ferramentas de reparo STEP. Recuperação parcial é melhor que perda total — mas a informação recuperada deve ser validada.

Médio prazo (prevenir recorrência):

5. Padronizar o processo de exportação. Documentar no BEP o procedimento de exportação IFC: espaço mínimo em disco, caminho sem caracteres especiais, verificação pós-export obrigatória (abrir o IFC em viewer antes de publicar), geração de hash.

6. Configurar verificação de integridade no CDE. Se o CDE permite, habilitar verificação automática de hash ou validação de parsing na ingestão de arquivos IFC. Arquivo que não passa na validação sintática não entra no estado Shared.

1. 1

   Verificação pós-export obrigatória · o autor abre o IFC exportado em viewer neutro e confirma que carrega completamente antes de publicar no CDE. Nenhum IFC sobe sem essa conferência — regra no BEP, não sugestão.

2. 2

   Hash SHA-256 gerado na exportação · o projetista gera o hash do IFC imediatamente após a exportação e registra junto ao arquivo no CDE. O receptor confere. Qualquer divergência indica corrupção na transferência.

3. 3

   Caminho de exportação sem caracteres especiais · o BEP define regra de nomenclatura de diretórios e arquivos: sem acentos, sem cedilha, sem espaços, sem caracteres CJK. Exportar para caminho limpo elimina a causa mais comum de encoding corrompido.

4. 4

   Espaço em disco verificado antes da exportação · modelos grandes geram IFCs de centenas de megabytes a gigabytes. O procedimento inclui checar espaço disponível antes de iniciar a exportação — disco cheio é causa trivial de truncamento.

5. 5

   Transferência por canal confiável · upload ao CDE por conexão estável (cabo, rede corporativa), não por Wi-Fi intermitente ou VPN instável. Se a transferência falhar, repetir — não assumir que o arquivo parcial está íntegro.

6. 6

   CDE com validação de ingestão · o CDE valida parsing sintático do IFC na ingestão. Arquivo que não passa na leitura STEP é rejeitado automaticamente, com mensagem ao autor. Impede que IFC corrompido entre no fluxo de coordenação.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC). Define o schema de dados que o arquivo STEP serializa. O arquivo .ifc é a serialização STEP (ISO 10303-21) do modelo de dados IFC. Um IFC que não abre falha na camada de serialização, antes de qualquer validação contra o schema.
• ISO 10303-21:2016STEP Physical File Format. Define a sintaxe da serialização que todo arquivo .ifc usa: cabeçalho (HEADER), corpo (DATA), terminador (END-ISO-10303-21;), encoding, referências internas (#ID). Corrupção sintática nessa camada é a causa direta de IFC que não abre.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.6.3 exige verificação da garantia da qualidade antes da troca — inclui garantir que o arquivo entregue é íntegro e legível.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. Seção 12 (Solução e fluxo de trabalho de um CDE) estabelece que a informação deve transitar por estados controlados — arquivo corrompido não pode entrar no estado Shared.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification. Verificação automatizada pressupõe arquivo legível — IDS não pode operar sobre IFC corrompido. A integridade do arquivo é pré-condição para qualquer validação de conformidade.