0
Por que os dados do UPLOAD de um campo especificado na forma de vetor vem organizado desta forma?
Quando queremos fazer o upload de um arquivo, normalmente criamos um INPUT, colocamos o atributo type="file" e um name="teste". No lado do PHP, recebemos o vetor associativo $_FILES, cuja posição "teste" possui um pacote de informações sobre o arquivo enviado e tal pacote é disposto na forma de um vetor associativo.
Porém, se mudarmos o atributo name para enviar um vetor, acontece algo estranho. Supondo o INPUT abaixo:
<input type="file" name="exemplo[teste]" />
Se fosse um campo de texto, o valor seria recebido em:
$_POST['exemplo']['teste']
ou
$_GET['exemplo']['teste']
Porém, como é um campo do tipo file, o pacote de dados fica aparentemente "embaralhado". Conseguimos pegar as informações assim:
$_FILES['exemplo']['name']['teste']
$_FILES['exemplo']['type']['teste']
$_FILES['exemplo']['size']['teste']
$_FILES['exemplo']['tmp_name']['teste']
$_FILES['exemplo']['error']['teste']
Ou seja, o segundo nível do vetor $_FILES sempre terá as chaves "name", "type", "size", "tmp_name" e "error". Isso me parece pouco intuitivo. Na minha opinião seria mais intuitivo até se o primeiro nível sempre viesse com estas chaves, mas o segundo... Realmente não entendo por que fizeram isso. O ideal, no entanto, seria que o tal "pacote de informações" viesse sempre no último nível, daí pegariamos os dados assim:
$_FILES['exemplo']['teste']['name']
$_FILES['exemplo']['teste']['type']
...
Bom, a coisa piora quando fazemos um name com mais níveis ainda, como este:
<input type="file" name="exemplo[teste][outro]" />
Recebemos o nome do arquivo em:
$_FILES['exemplo']['name']['teste']['outro']
Alguém conheceria um motivo lógico para isso? Ou será que é um daqueles "inconvenientes históricos" e que, se mudasse agora, poderia prejudicar codigos antigos?
Porém, se mudarmos o atributo name para enviar um vetor, acontece algo estranho. Supondo o INPUT abaixo:
<input type="file" name="exemplo[teste]" />
Se fosse um campo de texto, o valor seria recebido em:
$_POST['exemplo']['teste']
ou
$_GET['exemplo']['teste']
Porém, como é um campo do tipo file, o pacote de dados fica aparentemente "embaralhado". Conseguimos pegar as informações assim:
$_FILES['exemplo']['name']['teste']
$_FILES['exemplo']['type']['teste']
$_FILES['exemplo']['size']['teste']
$_FILES['exemplo']['tmp_name']['teste']
$_FILES['exemplo']['error']['teste']
Ou seja, o segundo nível do vetor $_FILES sempre terá as chaves "name", "type", "size", "tmp_name" e "error". Isso me parece pouco intuitivo. Na minha opinião seria mais intuitivo até se o primeiro nível sempre viesse com estas chaves, mas o segundo... Realmente não entendo por que fizeram isso. O ideal, no entanto, seria que o tal "pacote de informações" viesse sempre no último nível, daí pegariamos os dados assim:
$_FILES['exemplo']['teste']['name']
$_FILES['exemplo']['teste']['type']
...
Bom, a coisa piora quando fazemos um name com mais níveis ainda, como este:
<input type="file" name="exemplo[teste][outro]" />
Recebemos o nome do arquivo em:
$_FILES['exemplo']['name']['teste']['outro']
Alguém conheceria um motivo lógico para isso? Ou será que é um daqueles "inconvenientes históricos" e que, se mudasse agora, poderia prejudicar codigos antigos?
comentários (0)
suspender
Lista de Respostas:
0
25/12/2009 7:17pm
(~15 anos atrás)
(~15 anos atrás)
Sua observação é interessante e muito pertinente.
Eu não nunca tive a necessidade de reparar em tal peculiaridade em nenhum sistema que tenha desenvolvido, por isso não sei dizer nada quanto à suposição histórica sobre "será que é um daqueles "inconvenientes históricos" e que, se mudasse agora, poderia prejudicar códigos antigos"; apesar de que, creio não ser este o motivo.
O que podemos dizer é que isso, apesar de simples de trabalhar, é uma padronização nada facultativa. Acredito ter argumentos intrínsecos à própria implementação dos arrays na linguagem e, provavelmente, associados à forma como dados de formulários do tipo FILE são mais facilmente alocados nos arrays.
Eu não nunca tive a necessidade de reparar em tal peculiaridade em nenhum sistema que tenha desenvolvido, por isso não sei dizer nada quanto à suposição histórica sobre "será que é um daqueles "inconvenientes históricos" e que, se mudasse agora, poderia prejudicar códigos antigos"; apesar de que, creio não ser este o motivo.
O que podemos dizer é que isso, apesar de simples de trabalhar, é uma padronização nada facultativa. Acredito ter argumentos intrínsecos à própria implementação dos arrays na linguagem e, provavelmente, associados à forma como dados de formulários do tipo FILE são mais facilmente alocados nos arrays.