Recherche avancée

Sur d’autres sites (7090)

• How to properly escape shell arguments on Windows ?

  20 novembre 2016, par PeeHaa

  I am trying to properly escape user supplied data for a command line script. Normally I would use escapeshellarg, however this will simply not work because it’s breaks the eventual command line in glorious ways.

  The use case is trying to add meta data to videos using ffmpeg. A simplified and isolated problem case is the following command :

  ffmpeg -i in.mp4 -metadata author="My Name" out.mp4

  The author value is user supplied (My Name). I tried escaping only the user supplied part which resulted in :

  ffmpeg -i in.mp4 -metadata author=""My Name"" out.mp4

  Which results in the following ffmpeg error :

  Name : Invalid argument

  Next I tried escaping the entire flag (-metadata author="My Name") which results in :

  ffmpeg -i in.mp4 "-metadata author= My Name " out.mp4

  "Unrecognized option ’metadata author= My Name ’.

  Test cases :

  $flag = '-metadata author="%s"';
  
  
  
  var_dump(sprintf($flag, escapeshellarg('My Name')));
  
  var_dump(escapeshellarg(sprintf($flag, 'My Name')));

  Is there anything that will properly escape the user supplied data so that users cannot pass arbitrary flags to my command and that will make ffmpeg happy without having to do it manually with the risk of forgetting something and screwing it up ?

  Update

  I also tried escaping the entire flag value which works unless there is a double quote inside the user supplied part :

  $flag = 'author="%s"';
  
  
  
  var_dump('-metadata ' . escapeshellarg(sprintf($flag, 'My Name')));
  
  var_dump('-metadata ' . escapeshellarg(sprintf($flag, 'My "Name"')));

  Which results in :

  -metadata "author= My Name "
  
  -metadata "author= My  Name  " // it eats my quotes

• qsvdec_h2645 : switch to the new generic filtering mechanism

  13 novembre 2016, par Anton Khirnov

  qsvdec_h2645 : switch to the new generic filtering mechanism
  Drop the internal manual conversion from the MP4 format to Annex B.
  

  • [DBH] libavcodec/qsvdec_h2645.c

• Anomalie #3861 : Tri et caractères accentués dans boucle DATA

  7 février 2017

  Pour le pourquoi :

  • Les boucles articles, rubriques, etc, utilisent le moteur de base de données pour trier (ie ORDER BY titre) qui s’occupe brillamment de trier dans un ordre logique pour l’encodage utilisé
  • les boucles DATA utilisent PHP avec un tri sur un tableau de données.

  Actuellement {par x} dans une boucle DATA utilise un algorithme de tri assez classique qui fonctionne bien pour tout ce qui est numérique, mais effectivement ça peut poser des problèmes dès lors qu’on souhaite un tri naturel ou alphabétique sur des chaines non ascii.

  On pourrait peut être étendre pour la boucle DATA le critère par, de sorte que

  • {par alpha x} utiliserait une comparaison de texte en utilisant l’encodage (fonctions strcoll(), strcmp() ou strcasecmp() peut être)
  • {par naturel x} utiliserait une comparaison naturelle des nombres (fonction natsort()) (mais ne semble pas par contre trier correctement les accents)

  - http://php.net/manual/en/function.strcmp.php
  - http://php.net/manual/en/function.strcasecmp.php
  - http://php.net/manual/en/function.natsort.php

  Après un court test, les fonctions strcmp() ne prennent pas en compte les accents. Ça ne suffira pas. Une solution proposée convertie la chaine avec iconv() : http://stackoverflow.com/questions/14655092/comparing-utf-8-string mais suggère de préférer la classe Collatior (mais il faut l’extension Intl qui ne sera peut être pas installée partout)…
  Au sein de SPIP, si on suit cette technique, on peut peut être utiliser translitteration() pour enlever les accents, puis trier sur le résultat avec strcmp() ou strnatcmp() ou simplement avec < > d’ailleurs.