O sistema de arquivos Microsoft FAT possui uma tabela de diretórios para representar quais "arquivos" estão em quais "pastas" no disco. Por enquanto, essas entradas colocavam muitas informações em uma pequena quantidade de bits. Há um monte de especificações técnicas no Wiki para os curiosos, mas o desafio aqui será focar na decodificação "simples" de uma entrada.
Cada entrada consiste em uma palavra binária de 32 bytes, dividida em várias seções. Para maior consistência nesse desafio, usaremos a versão MS-DOS 5.0, os bytes são ordenados como big endian e chamamos byte 0x00
como o mais à esquerda e byte 0x1F
como o mais à direita.
Abaixo está um breve esquema das seções relevantes e qual deve ser o resultado de cada seção (em negrito ).
- Os primeiros 11 bytes são o nome do arquivo no formato ASCII (é daí que o famoso nome do arquivo 8.3 vem - 8 bytes para o nome do arquivo, 3 bytes para a extensão). Elas são codificação ASCII direta e devem ser exibidas como ASCII com um período (.) Entre .
- Nota: as partes 8 e 3 são preenchidas com espaços para fazer uma entrada completa. A saída deve ignorar os espaços (por exemplo, não os gera).
- A extensão do arquivo pode estar vazia (ou seja, todos os espaços); nesse caso, a saída não deve gerar o ponto .
- Como o ASCII usa apenas os 7 bits inferiores, todos os bytes terão uma vantagem
0
.
- O próximo byte (0x0b) é uma máscara de bits do seguinte:
- 0x01 somente leitura - saída RO
- 0x02 Oculto - saída H
- Sistema 0x04 - saída S
- Etiqueta de volume 0x08 - saída VL . O tamanho do arquivo (abaixo) deve ser exibido como 0 , independentemente de sua entrada real.
- 0x10 Subdiretório - saída SD . O tamanho do arquivo (abaixo) deve ser exibido como 0 , independentemente de sua entrada real.
- Arquivo 0x20 - saída A
- Dispositivo 0x40 - ignorado para este desafio.
- 0x80 Reservado - ignorado para este desafio.
- Como se trata de uma máscara de bits, vários sinalizadores são possíveis - todas as saídas aplicáveis devem ser concatenadas juntas em qualquer ordem. Por exemplo,
0xff
poderia serROHSVLSDA
(ou qualquer outra combinação).
- Os próximos dois bytes (0x0c e 0x0d) não são usados no MS-DOS 5.0.
- Os próximos dois bytes (0x0e e 0x0f) são o horário de criação da seguinte maneira:
- Os bits 15 a 11 são as horas no formato de 24 horas - saída 00 a 23
- Os bits 10 a 5 são os minutos - saída 00 a 59
- Os bits 4 a 0 são os segundos / 2 - saída de 00 a 58 (observe que os segundos estão apenas na resolução de dois segundos)
- Para esclarecimento:
hhhhhmmmmmmsssss
quando escrito big-endian.
- Os próximos dois bytes (0x10 e 0x11) são a data de criação da seguinte maneira:
- Os bits 15 a 9 são o ano - produção em 1980 para
0
até 2107 para127
- Os bits 8 a 5 são os meses - saída 1 a 12 (com ou sem zero inicial)
- Os bits 4 a 0 são o dia - saída 0 a 31 (com ou sem zero inicial)
- Para esclarecimento:
yyyyyyymmmmddddd
quando escrito big-endian.
- Os bits 15 a 9 são o ano - produção em 1980 para
- Os próximos dois bytes (0x12 e 0x13) são a última data de acesso. Enquanto usado no MS-DOS 5.0, estamos ignorando esta parte desse desafio.
- Os próximos dois bytes (0x14 e 0x15) não são usados pelo MS-DOS 5.0.
- Os próximos dois bytes (0x16 e 0x17) são a hora da última modificação, seguindo o mesmo formato da hora de criação, acima.
- Os próximos dois bytes (0x18 e 0x19) são a data da última modificação, seguindo o mesmo formato da data de criação acima.
- Os próximos dois bytes (0x1a e 0x1b) são o local do cluster do arquivo no disco. Estamos ignorando esta parte deste desafio.
- Os quatro bytes finais (0x1c, 0x1d, 0x1e e 0x1f) são o tamanho do arquivo - produzido como um número inteiro não assinado , a menos que os sinalizadores VL ou SD estejam definidos (acima), nesse caso, saída
0
.
Representação visual
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
\______________________________FILENAME________________________________________________/\_ATTR_/\___NOTUSED____/\_CREATIONTIME_/\_CREATIONDATE_/\__LASTACCESS__/\___NOTUSED____/\_MODIFIEDTIME_/\_MODIFIEDDATE_/\___NOTUSED____/\___________FILESIZE___________/
Entrada
- Uma única palavra de 32 bytes (ou seja, 256 bits), em qualquer formato que seja conveniente.
- Pode ser uma string
1
e0
, como váriosint
s não assinados , uma matriz de valores booleanos, etc. - Especifique na sua resposta qual formato você está usando para entrada.
- Você não pode receber várias entradas (ou seja, uma matriz pré-dividida nos tamanhos de bytes relevantes), a menos que seja a única maneira de o seu idioma receber entradas. Analisar a entrada faz parte do desafio.
- Pode ser uma string
- Você pode assumir que a entrada é válida (por exemplo, não é necessário executar a verificação da data para verificar se a data é válida).
- Os bytes não utilizados podem ser todos
0
, todos1
etc., desde que estejam presentes. Nos exemplos abaixo, usei tudo0
para os bytes não utilizados.
Saída
Impresso em tela ou retornado, o seguinte:
- O nome do arquivo como uma sequência ASCII
- O arquivo atribui como uma sequência ASCII
- O horário e a data de criação, com separadores apropriados (dois pontos, barras, algo para distinguir os componentes)
- A hora e data da modificação, novamente com separadores apropriados
- O tamanho do arquivo
A saída pode ser uma cadeia única separada por espaço ou nova linha, elementos separados em uma matriz, etc. Especifique na sua resposta como a saída é formatada.
Regras
- Formatos de E / S padrão são aceitáveis.
- Um programa completo ou uma função são aceitáveis.
- As brechas padrão são proibidas.
- Isso é código-golfe , então todas as regras usuais de golfe se aplicam e o código mais curto vence.
- Os internos que executam exatamente essa função são proibidos.
Exemplos
0111000001110010011011110110011101110010011000010110110101101101011010010110111001100111000001100000000000000000101000100100010001001000110101000000000000000000000000000000000010100010010001000100100011010100000000000000000000000000000000001101000000000000
programm.ing HS 20:18:08 2016/06/20 20:18:08 2016/06/20 53248
0010000000100000001000000010000001110000011100000110001101100111001000000010000000100000000101000000000000000000010111010110110000111101100111110000000000000000000000000000000010100010010001000100100011010100000000000000000011110000000100111111001011100001
ppcg SDS 11:43:24 2010/12/31 20:18:08 2016/06/20 0
fonte
SD S
um conjunto de sinalizadores válido?Respostas:
Verilog,
513670617 bytesExecuta usando IVerilog. Não são necessários sinalizadores especiais de compilação.
Este é um monstro de definições aninhadas, manipulação de bits e o incômodo de ter que inverter a ordem dos bits devido à persistência (caso contrário, a sequência não será impressa ou a ordem dos bits numéricos estará incorreta). A entrada é feita através da
i
porta, que é a maneira usual de levar a entrada para um módulo Verilog.$display
é usado para imprimir na saída padrão. 6 bytes poderiam ser salvos se zeros à esquerda não fossem necessários para o registro de data e hora.Demo
Testbench (Não pontuado):
Exemplo de execução:
fonte
Python,
485, 479, 442, 438, 431, 429, 418, 402, 395, 391, 370 bytes.Economizei 19 bytes graças a Cᴏɴᴏʀ O'Bʀɪᴇɴ, lembrando-me que posso atribuir funções a uma letra.
Economizou 6 bytes graças à sugestão de FryAmTheEggman de limpar o filtro de máscaras de bits.
Economizei 21 bytes graças à incrível resposta Ruby de W0lf, forçando-me a resolver isso um pouco mais. ;)
Este é um monstro absoluto. Tenho certeza de que posso reduzi-lo um pouco mais, mas está ficando bem perto de ser jogado fora.
fonte
int
a um char? ou talvez faça uma função que executastr int
.or 'SD'
pode ser removido, eu acho #Haskell,
781710 bytesObrigado ao BlackCap por algumas simplificações
Isso também permite que o lixo (como um caractere de nova linha) apareça após a entrada.
fonte
Java,
17211587157315601511 bytes:Recebe entrada no formato de sequência binária de 32 bytes. Saídas no formato de uma sequência separada por espaço. Esta pode ser uma resposta muito, muito longa, mas ainda não estou decepcionada. Estou feliz por poder implementar isso em Java. Ainda vou tentar jogar isso o máximo que puder.
Experimente Online! (Ideona)
fonte
Ruby, 344 bytes
A versão um pouco mais legível está disponível aqui .
Teste on-line: http://ideone.com/Fww1Rw
fonte
JavaScript (ES6), 369
Menos golfe
Teste
fonte
Script error.
. Mas, por alguma razão, no Firefox, parece funcionar perfeitamente. Pergunto-me porquê ...PHP ,
301288 bytesExperimente online!
Input é uma cadeia de palavras de 32 bytes via
STDIN
, saída paraSTDOUT
.-13 bytes como um programa independente.
fonte
Stax , 111 bytes
Execute e depure
fonte
Perl, 249 bytes
Toma 32 bytes como entrada, a saída é separada por novas linhas.
unpack
é perfeito para esse tipo de análise de estrutura binária.Alguns destaques:
unpack
.@{[]}
permite interpolar o código em uma string. Na verdade, ele cria uma referência de matriz que é desreferenciada."$str1"x!!$str2
é uma boa maneira de retornar$str1
apenas se$str2
for uma string não vazia.Abaixo está uma versão que funciona em entradas de diretório real, com campos little endian, e apenas ignorando o preenchimento correto no nome do arquivo e na extensão (por exemplo
" ppcg"
, não tem seu espaço em branco inicial removido) (254 bytes)fonte