web-dev-qa-db-fra.com

Le contrôle d'entrée de fichier HTML avec les attributs de capture et d'acceptation fonctionne mal?

Mon problème:

Puis, cliquez sur l'utilisateur input type=file Pour obtenir la boîte de dialogue upload file + camera. J'utilise pour ces attributs HTML accept et capture. Mais sur certains appareils modernes, cela ne se produit pas. Ci-dessous se trouvent les exemples de code et la table qui de ses travaux ou non. Les exemples de code sont testés dans Mobile Safari Et Chrome.

TL; DR:

J'ai 5 exemples de code avec seulement input type file:

1.. ( jsfiddle )

<input type="file" accept="image/*" capture>

2. ( jsfiddle )

<input type="file" accept="image/*" capture="camera">

3. ( jsfiddle )

<input type="file" capture="camera">

4. ( jsfiddle )

<input type="file" capture>

5. ( jsfiddle )

<input type="file" accept="image/*">

Dispositifs de test:

  • Samsung S3 (Android 4.1.2)
  • Samsung S3 (Android 4.3)
  • Samsung Galaxy Tab 2 7.0 (Android 4.2.2)
  • Samsung Note (Android 4.1.2)
  • iPhone 5 (iOS 7.0.4)
  • Nexus 4 (Android 4.4)

Tableau de résultats:

  • W (ork) - signifie activé upload image dialog with camera
  • P (travaux artistiques) - signifie activé upload dialog(not image only) with camera
  • N (ot work) - signifie only camera Activé
  • Ch - signifie Chrome
  • MS - signifie Mobile Safari

#

--------------------------------------------------------------------------------
|devices/example   | Ch 1| Ch 2| Ch 3| Ch 4| Ch 5| MS 1| MS 2| MS 3| MS 4| MS 5| 
--------------------------------------------------------------------------------
|Samsung S3/4.1    |  N  |  N  |  P  |  P  |  W  |  W  |  N  |  P  |  P  |  W  |
--------------------------------------------------------------------------------
|Samsung S3/4.3    |  N  |  N  |  P  |  P  |  P  |  N  |  N  |  P  |  P  |  P  |
--------------------------------------------------------------------------------
|Samsung Galaxy Tab|  N  |  N  |  P  |  P  |  W  |  W  |  N  |  P  |  P  |  W  |
--------------------------------------------------------------------------------
|Samsung Note      |  N  |  N  |  P  |  P  |  W  |  W  |  N  |  P  |  P  |  W  |
--------------------------------------------------------------------------------
|iPhone 5          |  W  |  W  |  P  |  P  |  W  |  W  |  Y  |  P  |  P  |  W  |
--------------------------------------------------------------------------------
|Nexus 4           |  N  |  N  |  P  |  P  |  W  |  -  |  -  |  -  |  -  |  -  |
--------------------------------------------------------------------------------

Comme vous pouvez le constater, je ne peux obtenir que la boîte de dialogue upload file + camera Pour tous les navigateurs utilisant

<input type="file" accept="image/*"> Seulement. Mais il n'y a pas d'attribut capture dans ce cas, ce qui me préoccupe et pose un problème avec Android 4.3.

Mes questions sont:

  1. Les comportements dans la table sont-ils vrais? Android 4.3 comportement est un bogue?
  2. Est-ce que je peux faire confiance aux navigateurs pour qu'il ajoute toujours un appareil photo pour charger la boîte de dialogue sans attribut de capture? (S'il vous plaît ajouter des liens de preuve pour la réponse)

Merci.

P.S. La question est spéciale, mais sur mon site, je dois fournir aux utilisateurs un accès à ses images et à sa caméra. De plus, je pense que mon tableau peut être utile à tout le monde et je vais aussi chercher une réponse et poster ma réponse ici si personne ne répond.

65
Pinal

C'est la réponse réelle. Il suffit de poster ici pour les prochains utilisateurs:

En fait, il semble que les implémentations actuelles ne reposent pas du tout sur l'attribut de capture, mais uniquement sur les attributs de type et d'acceptation: le navigateur affiche une boîte de dialogue dans laquelle l'utilisateur peut choisir l'emplacement où le fichier doit être récupéré, et le capture attribut n'est pas pris en compte. Par exemple, iOS Safari s'appuie sur l'attribut accept (pas capture) pour les images et vidéos (pas audio). Même si vous n'utilisez pas l'attribut accept, le navigateur vous laissera choisir entre "Prendre une photo ou une vidéo" et "Choisir existant" (merci à @firt de l'avoir signalé).

De this

EDITED 17 fév 2016: Ce comportement est toujours actif sur les périphériques.

34
Pinal

Le code "correct" et celui que vous devriez utiliser est le 5ème:

<input type="file" accept="image/*">

C'est pourquoi il fonctionne correctement sur la plupart de vos appareils. Le code ci-dessus est correct, complet et assez pour indiquer à la fois iOS et Android = que:

  1. vous voulez capturer une image (utilisez accept="video/*" pour la vidéo et accept="audio/*" pour l'audio, ignorez tout pour permettre quoi que ce soit).
  2. l'utilisateur devrait pouvoir en sélectionner un existant OR ) pour le capturer le spot
  1. Est-ce que je peux faire confiance aux navigateurs pour qu'il ajoute toujours un appareil photo pour charger la boîte de dialogue sans attribut de capture?

Oui.

L’attribut capture n’est PAS utilisé pour inclure l’option caméra dans la boîte de dialogue (<input type="file"> est suffisant pour cela) mais pour indiquer que la capture directe depuis la webcam est préférée. De spécification de la recommandation du W3C :

L'attribut capture est un attribut booléen qui, s'il est spécifié, indique que la capture de média directement à partir du périphérique ... est préférée.

capture est pris en charge par Android 3.0+ qui vous mènera directement à l'application pour appareil photo si capture est présent dans le code.

IOS6-10 n'est pas pris en charge et vous donnera toujours au moins 2 options: "Prendre une photo" + "Photothèque".

L'attribut capture a évolué dans les spécifications (c'est pourquoi vous verrez plusieurs versions dans StackOverflow):

  1. Juillet 2010: accept="image/*;capture=camera"
  2. Avril 2011: capture="camera" (Chaîne)
  3. Décembre 2012: capture (Booléen, Recommandation du candidat au W3C ,)

PS: J'ai effectué une tonne de recherches sur la capture multimédia HTML, voir Syntaxe correcte pour la capture multimédia HTML et La nouvelle invite de capture multimédia dans iOS9 . Voici mon banc d'essai avec plus de 20 combinaisons de codes.

21
Octavian Naicu