FreeToGenerate.com

Un archivo dice lo que es en sus primeros bytes. Algunos formatos los fijan en una norma; otros no los escribieron nunca. No se sube nada.

Identificar un archivo

Suelta un archivo aquí, o elige uno.

Solo se leen los primeros bytes, y se leen en tu navegador. El archivo no se sube y no sale de tu máquina.

norma
15
informativo
1
doc. del fabricante
14
solo convención
3
33 / 33
PNGnorma.pngimage/png
89 50 4E 47 0D 0A 1A 0A·PNG····En el byte 0 (el principio)

Escrito en: ISO/IEC 15948 §5.2

La norma actual enuncia estos ocho bytes y no dice por qué. La explicación —un primer byte no ASCII para cazar una transferencia que borre el bit alto, un CR-LF para cazar la conversión de saltos de línea, un control-Z para que MS-DOS no vuelque el archivo y un salto de línea final para el problema inverso— sobrevive solo en la RFC informativa que la norma sustituyó.

JPEGnorma.jpg .jpegimage/jpeg
FF D8 FF···En el byte 0 (el principio)

Escrito en: ITU-T T.81 §B.1 (SOI marker)

Solo los primeros bytes son fijos. Lo que sigue varía según el codificador, y por eso esta firma es más corta que la mayoría.

GIF 87adoc. del fabricante.gifimage/gif
47 49 46 38 37 61GIF87aEn el byte 0 (el principio)

Escrito en: GIF 87a, Header block

Dos versiones del formato comparten prefijo, así que la versión forma parte de la firma en vez de leerse después.

GIF 89adoc. del fabricante.gifimage/gif
47 49 46 38 39 61GIF89aEn el byte 0 (el principio)

Escrito en: GIF 89a §17 (Header)

Dos versiones del formato comparten prefijo, así que la versión forma parte de la firma en vez de leerse después.

BMPdoc. del fabricante.bmp .dibimage/bmp
42 4DBMEn el byte 0 (el principio)

Escrito en: Microsoft BITMAPFILEHEADER (bfType)

WebPnorma.webpimage/webp
52 49 46 46RIFFEn el byte 0 (el principio)

Escrito en: RFC 9649 §2 (RIFF container)

RIFF es un contenedor, no un formato. WebP, WAV y AVI son idénticos byte a byte aquí; los cuatro bytes que los distinguen vienen después.

TIFF (little-endian)doc. del fabricante.tif .tiffimage/tiff
49 49 2A 00II*·En el byte 0 (el principio)

Escrito en: TIFF 6.0 §2 (Image File Header)

TIFF (big-endian)doc. del fabricante.tif .tiffimage/tiff
4D 4D 00 2AMM·*En el byte 0 (el principio)

Escrito en: TIFF 6.0 §2 (Image File Header)

ICOsolo convención.icoimage/vnd.microsoft.icon
00 00 01 00····En el byte 0 (el principio)

Escrito en: nada normativo

Photoshopdoc. del fabricante.psdimage/vnd.adobe.photoshop
38 42 50 538BPSEn el byte 0 (el principio)

Escrito en: Adobe Photoshop File Formats, File Header

PDFnorma.pdfapplication/pdf
25 50 44 46 2D%PDF-En el byte 0 (el principio)

Escrito en: ISO 32000-2 §7.5.2 (File header)

La firma es texto legible y no binario, y por eso estos archivos suelen sobrevivir a que los abran en un editor de texto.

RTFdoc. del fabricante.rtfapplication/rtf
7B 5C 72 74 66{\rtfEn el byte 0 (el principio)

Escrito en: Microsoft RTF Specification

La firma es texto legible y no binario, y por eso estos archivos suelen sobrevivir a que los abran en un editor de texto.

ZIPdoc. del fabricante.zipapplication/zip
50 4B 03 04PK··En el byte 0 (el principio)

Escrito en: PKWARE APPNOTE §4.3.7 (local file header)

Un .docx, un .xlsx, un .jar, un .apk y un .epub son todos archivos ZIP y todos llevan estos bytes. Distinguirlos exige abrir el archivo y mirar lo que hay dentro.

gzipnorma.gzapplication/gzip
1F 8B··En el byte 0 (el principio)

Escrito en: RFC 1952 §2.3.1 (ID1, ID2)

bzip2solo convención.bz2application/x-bzip2
42 5A 68BZhEn el byte 0 (el principio)

Escrito en: nada normativo

XZdoc. del fabricante.xzapplication/x-xz
FD 37 7A 58 5A 00·7zXZ·En el byte 0 (el principio)

Escrito en: The .xz File Format §2.1.1.1 (Header Magic Bytes)

7-Zipsolo convención.7zapplication/x-7z-compressed
37 7A BC AF 27 1C7z··'·En el byte 0 (el principio)

Escrito en: nada normativo

RAR 5doc. del fabricante.rarapplication/vnd.rar
52 61 72 21 1A 07 01 00Rar!····En el byte 0 (el principio)

Escrito en: RAR archive format documentation

tar (ustar)norma.tarapplication/x-tar
75 73 74 61 72ustarEn el byte 257

Escrito en: POSIX.1-2017 (ustar Interchange Format)

Esta no empieza al principio del archivo, así que cualquier cosa que lea solo los primeros bytes se la pierde por completo.

ISO 9660norma.isoapplication/x-iso9660-image
43 44 30 30 31CD001En el byte 32769

Escrito en: ECMA-119 §8.4.1 (Standard Identifier)

Esta no empieza al principio del archivo, así que cualquier cosa que lea solo los primeros bytes se la pierde por completo.

WAVdoc. del fabricante.wavaudio/vnd.wave
52 49 46 46RIFFEn el byte 0 (el principio)

Escrito en: RFC 2361 / Microsoft RIFF

RIFF es un contenedor, no un formato. WebP, WAV y AVI son idénticos byte a byte aquí; los cuatro bytes que los distinguen vienen después.

AVIdoc. del fabricante.avivideo/vnd.avi
52 49 46 46RIFFEn el byte 0 (el principio)

Escrito en: Microsoft RIFF (AVI form)

RIFF es un contenedor, no un formato. WebP, WAV y AVI son idénticos byte a byte aquí; los cuatro bytes que los distinguen vienen después.

MP4 / ISO base medianorma.mp4 .m4a .movvideo/mp4
66 74 79 70ftypEn el byte 4

Escrito en: ISO/IEC 14496-12 §4.3 (File Type Box)

Esta no empieza al principio del archivo, así que cualquier cosa que lea solo los primeros bytes se la pierde por completo.

Oggnorma.ogg .oga .ogvapplication/ogg
4F 67 67 53OggSEn el byte 0 (el principio)

Escrito en: RFC 3533 §6 (capture_pattern)

FLACnorma.flacaudio/flac
66 4C 61 43fLaCEn el byte 0 (el principio)

Escrito en: RFC 9639 §8.1 (stream marker)

MP3 with ID3v2informativo.mp3audio/mpeg
49 44 33ID3En el byte 0 (el principio)

Escrito en: ID3v2 informal standard §3.1

Matroska / WebMnorma.mkv .webmvideo/x-matroska
1A 45 DF A3·E··En el byte 0 (el principio)

Escrito en: RFC 8794 §4 (EBML magic)

Dos versiones del formato comparten prefijo, así que la versión forma parte de la firma en vez de leerse después.

ELFnormaapplication/x-executable
7F 45 4C 46·ELFEn el byte 0 (el principio)

Escrito en: System V ABI, ELF header (EI_MAG0..3)

DOS / Windows executabledoc. del fabricante.exe .dllapplication/vnd.microsoft.portable-executable
4D 5AMZEn el byte 0 (el principio)

Escrito en: Microsoft PE Format (IMAGE_DOS_HEADER)

Java classnorma.classapplication/java-vm
CA FE BA BE····En el byte 0 (el principio)

Escrito en: Java Virtual Machine Specification §4.1 (magic)

SQLite databasedoc. del fabricante.sqlite .dbapplication/vnd.sqlite3
53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00SQLite format 3·En el byte 0 (el principio)

Escrito en: SQLite Database File Format §1.3 (header string)

WOFFnorma.wofffont/woff
77 4F 46 46wOFFEn el byte 0 (el principio)

Escrito en: WOFF File Format 1.0 §3 (signature)

WOFF2norma.woff2font/woff2
77 4F 46 32wOF2En el byte 0 (el principio)

Escrito en: WOFF File Format 2.0 §3 (signature)

Dónde están especificadas

normaFijado en el texto normativo de una norma publicada. Si lo cambias, el archivo deja de ser conforme.

informativoEstá escrito, pero en un documento que no impone requisitos: una RFC informativa, o una especificación que ya ha sido sustituida.

doc. del fabricanteDocumentado por quien es dueño del formato y no por un organismo de normalización. Fiable en la práctica, y revisable sin el acuerdo de nadie.

solo convenciónTodas las herramientas lo implementan y ningún documento lo exige. Estos bytes sostienen el formato solo porque todo el mundo está de acuerdo.

Cada fila se comprueba contra un archivo generado por un codificador real, así que estos bytes no vienen copiados de otra tabla.

También disponible en: English · Português · Français · العربية

Firmas de archivo y números mágicos

Los números mágicos de 33 formatos, cada uno con el documento que de verdad lo define, y un identificador que lee solo la cabecera en tu navegador.

¿Qué es una firma de archivo?

Una firma de archivo, o número mágico, es una secuencia corta y fija de bytes al principio de un archivo que dice de qué tipo es. Todos los PNG empiezan por los mismos ocho bytes; todos los archivos gzip por los mismos dos. Los programas los leen porque el nombre no es una prueba: renombrar una hoja de cálculo como .png no cambia nada de lo que hay dentro, y un archivo que llega de internet tiene el nombre que quiso ponerle quien lo envió.

La lista de abajo trae 33 formatos con sus bytes, en qué punto del archivo están y el tipo de medio cuando está registrado. Lo que además trae, y que las tablas copiadas unas de otras se dejan, es el documento que define cada firma. Esa columna resulta ser la interesante.

Porque la respuesta no es uniforme. Algunas firmas están fijadas en el texto normativo de una norma publicada. Otras solo en la documentación del propio fabricante. Otras en un documento que ya no tiene ningún peso. Y unas cuantas —ICO, bzip2, 7-Zip— las implementan igual todas las herramientas del mundo y no se escribieron nunca en ninguna parte como requisito.

Cómo usarlo

  1. Suelta un archivo, o elígelo. Solo se lee la cabecera, y la lee tu navegador. No se sube nada. Si alguna firma coincide, obtienes el formato, los bytes que coincidieron y dónde están definidos.
  2. O pega los bytes que ya tengas. Si estás mirando un volcado hexadecimal, pega los primeros bytes. Se aceptan espacios, prefijos 0x y minúsculas; solo hace falta un número par de dígitos.
  3. Busca en la lista por cualquier cosa de la fila. Sirven el nombre del formato, una extensión, un tipo de medio, un prefijo hexadecimal o el nombre de una especificación. Escribir png pone PNG primero en vez de enterrarlo bajo todo lo que contenga esas letras.

La firma de PNG, y la explicación que la norma dejó caer

PNG es el formato que merece mirarse de cerca, porque sus ocho bytes son los mejor diseñados de la lista y su historia no es la que esperarías. Son 137, 80, 78, 71, 13, 10, 26, 10; en texto, un byte con el bit alto puesto, luego PNG, luego un retorno de carro, un salto de línea, un control-Z y otro salto de línea.

Cada uno hace su trabajo. El primer byte no es deliberadamente un carácter ASCII, para que un archivo de texto no se confunda con un PNG y, sobre todo, para cazar una transferencia que borre el bit alto de cada byte. El retorno de carro y el salto de línea cazan el problema contrario: una transferencia que convierta amablemente los finales de línea entre plataformas destroza esa pareja, y el archivo falla en el byte cinco en vez de en algún punto profundo de la imagen. El control-Z impide que MS-DOS vuelque el resto de un binario en la terminal cuando alguien lo escribe. El salto de línea final caza el inverso de la conversión CR-LF.

Y aquí está la parte que nos sorprendió. Esa explicación no está en la norma actual. ISO/IEC 15948, que es lo que normaliza PNG hoy, enuncia los ocho bytes y sigue adelante, dejando una sola frase en su apartado de justificación para decir que la firma detecta errores comunes de transmisión. El razonamiento byte a byte sobrevive únicamente en la RFC 2083 de 1997, un documento marcado como Informativo al que la norma ha sustituido. Los bytes son normativos. Las razones por las que son esos bytes, no.

Límites honestos

Una firma dice lo que un archivo afirma ser, y ese es justo el motivo para comprobarla, pero también su límite. Los bytes del principio son baratos de falsificar. Si estás decidiendo si algo es seguro de abrir, una firma que coincide te dice que el archivo está lo bastante bien formado como para tener una cabecera plausible y nada más.

No todas las firmas empiezan al principio. El marcador ustar que identifica un archivo tar está en el byte 257, y el CD001 de ISO 9660 en el byte 32769, más de 32 kilobytes dentro. Cualquier cosa que lea solo los primeros cuatro bytes se pierde por completo los dos formatos de archivo comprimido y de imagen de disco más comunes, y por eso esta herramienta lee más lejos.

Varios formatos son indistinguibles en la cabecera, y la herramienta lo dice en vez de adivinar. WebP, WAV y AVI empiezan por los mismos cuatro bytes, porque los tres son contenedores RIFF y los bytes que los separan vienen después. Un .docx, un .xlsx, un .jar, un .apk y un .epub son todos archivos ZIP y llevan la firma de ZIP; distinguirlos exige descomprimir y mirar dentro, que es otro trabajo. En ambos casos se muestran todas las coincidencias en lugar de elegir una.

Muchos formatos no tienen firma ninguna. CSV, texto plano, casi todo el código fuente y SVG son solo caracteres, y no hay nada fijo al principio con lo que comparar: SVG en particular es XML, que puede empezar o no por una declaración. Un archivo que no coincide con nada de aquí te ha dicho muy poco.

Por último, 33 formatos son una selección y no un censo, y la lista está acotada a propósito. La respuesta completa de facto es la base de datos mágica que acompaña al comando file de Unix, con miles de reglas, lógica condicional y aritmética de bytes. Lo que hay en esta página es el subconjunto cuyos bytes se pueden comprobar contra un archivo real que las pruebas de esta página construyen, así que cada fila está verificada y no transcrita.

¿Por qué es gratis?

Porque no cuesta nada mantenerlo. La lista forma parte de la página y la identificación ocurre en tu navegador: cuando sueltas un archivo, solo se leen sus primeros bytes, y se leen en local. No se sube nada, ningún servidor ve tu archivo y no hay cuenta.

La tabla no está copiada de otra tabla. Cada fila que se puede construir se comprueba contra un archivo producido por un codificador real, y se contrasta con la identificación del propio comando file, así que un dígito transpuesto rompe la compilación en vez de llegar a la página. Donde un formato no se ha podido construir aquí, la página lo dice en vez de dejarlo sin verificar en silencio.