Tag

encodage

Browsing

Des espaces après chaque caractère accentué

Pour le site du Kriya Yoga France, on me transmet régulièrement des fichiers PDF que je dois transformer en articles. Je fais donc la plupart du temps un copié-collé et ensuite je m'attèle à la mise en page dans l'éditeur WordPress.

MacOS : résoudre le problème d'encodage Unicode des accents photo

Le hic, c'est que depuis l'année dernière, je travaille sous MacOS pour tout ce qui est développement web. J'ouvre donc chaque PDF avec Preview - la visionneuse PDF installée par défaut - mais lorsque l'on colle le contenu du PDF dans un autre document, tous les caractères accentués sont suivis d'une espace (oui, on dit bien une espace en typographie) et des sauts de ligne apparaissent de nulle part. Clairement improductif.

Un conflit Unicode

Le problème réside entre un conflit lors de l'encodage Unicode entre caractères précomposés et caractères décomposés.

Un caractère précomposé ou caractère composite ou caractère décomposable est une entité Unicode qui peut aussi être définie comme une combinaison de plus de deux caractères.

Un caractère précomposé peut typiquement représenter une lettre surplombée d'un accent, comme é (lettre e avec accent aigu).

Techniquement, é (U+00E9) est un caractère qui peut être décomposé en son équivalent unicode à base de la lettre e (U+0065) et du caractère combinant accent aigu (U+0301).

La solution : UnicodeChecker

Heureusement, il existe un petit utilitaire, UnicodeChecker, qui permet de régler le problème très simplement. Voici la marche à suivre.

1. Lancez UnicodeChecker > File > New Utilities Window.

2. Copiez le texte de votre fichier PDF en mémoire (sélectionnez le texte puis Cmd+C ou Ctrl+C au clavier).

3. Dans UnicodeChecker, choississez l'option Normalize (6ème icône) et collez votre texte dans le champ Input puis appuyez sur Entrée. Cela donne :

MacOS : résoudre le problème d'encodage Unicode des accents sous Preview photo

Quatre champs sont proposés avec le résultat de la normalisation. Les deux champs qui nous importent sont NFC et NFKC, qui utilisent tout deux de l'Unicode précomposé, dans lequel l'accent fait partie intégrante du caractère accentué et non une entité à part.

4. Sélectionnez et copiez le texte contenu dans le champ NFC:

MacOS : résoudre le problème d'encodage Unicode des accents sous Preview photo 1

5. Collez maintenant le texte précédemment copié dans votre document ou l'éditeur de texte de votre CMS. A l'œil nu, rien ne change mais dans le rendu, votre texte est désormais correctement accentué, sans espaces inopportunes.

Quatre ans après le passage du codec XviD au codec x264, voici que la "scene" change de nouveau les règles du jeu : les fichiers SD et HD seront maintenant en .MKV (Matroska) et non plus en .MP4 pour les séries TV.

Depuis le 10 avril 2016, les nouvelles règles sont entrées en vigueur : si le codec x264 est bien gardé, le conteneur va lui changer - finis les fichiers portant l'extension MP4, ce seront maintenant des fichiers MKV (Matroska) que l'on pourra trouver sur la toile.

Séries TV: la scène délaisse le conteneur MP4 et passe au MKV photo
Daenerys est passée au MKV

Les raisons du changement de conteneur

Concrètement, la scène justifie ce changement de conteneur avec les évolutions des standards et de la qualité des encodages. Dans l'introduction des règles, on peut lire que "depuis la dernière révision du document qui date de 2012, TV-X264-SD a évolué et est devenu une section majeure à laquelle beaucoup de gens contribuent et dont beaucoup dépendent. Cette nouvelle révision vise à mettre à jour les standards pour 2016 et après."

Ces règles sont à l'intention des groupes de la scène uniquement (qui s'échangent les fichiers entre eux via des topsites) mais la plupart des fichiers finiront entre les mains du grand public, partagés sur des sites publics. Cela signifie donc que ces changements vont impacter des centaines de millions de personnes à travers le monde, indirectement, par simple effet domino.

Les règles sont très exhaustives et abordent tous les aspects techniques de l'encodage des fichiers : normes audio, vidéo, formats, sous-titres... jusqu'au nom des tags des fichiers mais ce qui importe avec la mouture 2016 est la partie concernant le conteneur.

BashPour les besoins du Centre de Kriya Yoga France, j'ai été amené à devoir convertir toute une floppée de fichiers MP3 au format Ogg Vorbis afin qu'il soient lus nativement en HTML5 dans les navigateurs compatibles avec la balise audio.

J'ai utilisé la commande avconv dans un terminal.

Convertir des MP3 en Ogg Vorbis

Voici le script que j'ai écrit pour me simplifier la vie et convertir ma liste de MP3 au format Ogg Vorbis:

for i in *.mp3; do avconv -i $i -codec:a libvorbis -aq 4 ${i/%mp3/ogg}; done

Cela recherche tous les fichiers MP3 du répertoire dans lequel on se trouve, utilise le codec libvorbis, encode dans une qualité supérieure ou égale à 128Kbps et nomme le fichier avec la bonne extension (.ogg pour l'Ogg Vorbis).

Convertir des Ogg Vorbis en MP3

Si vous souhaitez convertir des fichiers Ogg Vorbis au format MP3 :

for i in *.ogg; do avconv -i $i -codec:a libmp3lame -aq 2 ${i/%ogg/mp3}; done

Cela recherche tous les fichiers OGG du répertoire dans lequel on se trouve, utilise le codec libmp3lame, encode dans une qualité supérieure ou égale à 192Kbps et nomme le fichier avec la bonne extension (.mp3).

Jusqu'à très récemment, il m'était tout à fait possible d'avoir des caractères accentués dans des blocs de texte sous WordPress en utilisant le plugin Crayon Syntax Highlighter pour coloriser le code.

crayon-syntax-highlighter

Or depuis quelques temps tous les blocs en lang="text" ne permettent plus d'afficher les accents : je me retrouve avec des mots tronqués comme si le texte n'était pas encodé en UTF-8.

Problème : des caractères non-Unicode

Voici ce que donne la phrase "j'ai mangé une tarte à la crème à Noël" avec une colorisation par défaut avec Crayon Syntax Highlighter :

J'ai mangé une tarte à la crème à Noël.

Gloups! C'est totalement illisible, les accents deviennent un caractère mal encodé et certaines lettres adjacentes sont littéralement supprimées. Pas glop.

Solution : créer un alias

La solution que je propose est plus une rustine d'appoint qu'une véritable solution.

Je pense que le problème réside dans l'expression régulière des langages du plugin : certains langages (shell par exemple) n'acceptent pas les accents alors que d'autres (HTML par exemple) oui.

Je me suis rendu compte en changeant la langue du bloc que le langage batch affichait correctement les accents.

Comme je n'allais pas éditer tous mes articles pour changer le langage des blocs texte que j'ai utilisé jusqu'à maintenant, j'ai opté pour la création d'un alias.

Voici une petite liste des derniers ajouts, modifications et améliorations du site ces derniers mois :

  1. [*] PHP : déplacement de mes bouts de code du fichier functions.php pour les organiser dans un fichier-plugin.
  2. [*] HTML : ajout des meta Dublin Core sur la page d'accueil, passage des balises H2 en H1 pour les titres des articles, correction du code HTML5 parce que le validateur W3C a changé ses recommandations.
  3. [*] CSS : nettoyage du code CSS. J'ai remplacé les images et les sprites par des gradients CSS et utilisé les dashicons de WordPress au lieu d'images. Ajout de code non-valide sur les gradients pour prendre en charge Internet Explorer. Amélioration du menu.
  4. [+] Serveur : passage du serveur en IPv6.
  5. [+] Serveur : WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod.
  6. [+] Serveur : WordPress : héberger les images sur un sous-domaine.
  7. [+] WordPress : remplacement de mon ancien plugin de colorisation de syntaxe par Crayon Syntax Highlighter. Ajout d'Advanced Code Editor pour éditer les fichiers avec un véritable éditeur de code.
  8. [+] WordPress : les membres peuvent désormais ajouterune photo/avatar dans leur profil. Il est possible de supprimer son compte.
  9. [+] PHP / WordPress : remplacement du plugin de pagination et du plugin qui permet d'afficher des nombres différents d'article selon le type de page par des fonctions natives à WordPress, les liens des articles deviennent cliquables automatiquement, suppression des cookies de commentaires pour améliorer le cache.
  10. [+] CSS : création d'une feuille de style dédiée à l'impression des articles. On imprime uniquement les sections importantes de l'article et l'avatar de l'auteur est remplacé par le QR code qui renvoie vers l'article. Je suis content d'avoir fini de mettre cela en place!

J'ai travaillé sur pas mal de choses invisibles à l'oeil nu mais au final, je suis satisfait du résultat. Je vais bientôt m'atteler au chiffrement SSL et à la sécurisation du serveur mail.

Voici les quelques mises à jour du serveur et du site depuis quelques mois :

J'ai encore pas mal de projets dans les cartons mais actuellement, je manque cruellement de temps :/

webm-logoAujourd'hui, si veut publier une vidéo sur Internet qui soit lisible sur quasiment toutes les plateformes nativement, il peut être très intéressant d'utiliser le format WebM (proposé pour HTML5).

WebM est un format multimédia ouvert basé sur un conteneur dérivé de Matroska, qui regroupe des flux vidéos encodés en VP8 et des flux audios encodés en Vorbis1. Ce format fait partie des formats vidéos proposés pour la balise video de HTML5.

Après avoir encodé nos vidéos H.264 (MP4) avec qt-faststart pour la lecture progressive, nous allons désormais proposer deux formats de vidéo lorsque nous intégrerons nos propres vidéos : le MP4 (format propriétaire) et le WebM (format libéré) pour un accès universel sur toutes les plateformes.

Encoder une seule vidéo MP4 en WebM

Il suffit d'utiliser avconv comme ceci :

avconv -i example.mp4 example.webm

ce qui nous donne comme résultat :

avconv version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the Libav developers
  built on Apr  2 2013 17:02:36 with gcc 4.6.3
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'example.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 1
    compatible_brands: mp42avc1
    creation_time   : 2013-09-24 10:52:45
  Duration: 00:43:27.39, start: 0.000000, bitrate: 294 kb/s
    Stream #0.0(eng): Video: h264 (Main), yuv420p, 320x240, 217 kb/s, 14.97 fps, 14.97 tbr, 2500 tbn, 5k tbc
    Metadata:
      creation_time   : 2013-09-24 11:23:01
    Stream #0.1(eng): Audio: aac, 32000 Hz, stereo, s16, 73 kb/s
    Metadata:
      creation_time   : 2013-09-24 11:23:01
[buffer @ 0x183ec80] w:320 h:240 pixfmt:yuv420p
[libvpx @ 0x183a4c0] v1.0.0
Output #0, webm, to 'example.webm':
  Metadata:
    major_brand     : mp42
    minor_version   : 1
    compatible_brands: mp42avc1
    creation_time   : 2013-09-24 10:52:45
    encoder         : Lavf53.21.1
    Stream #0.0(eng): Video: libvpx, yuv420p, 320x240, q=-1--1, 200 kb/s, 1k tbn, 14.97 tbc
    Metadata:
      creation_time   : 2013-09-24 11:23:01
    Stream #0.1(eng): Audio: libvorbis, 32000 Hz, stereo, s16
    Metadata:
      creation_time   : 2013-09-24 11:23:01
Stream mapping:
  Stream #0:0 -> #0:0 (h264 -> libvpx)
  Stream #0:1 -> #0:1 (aac -> libvorbis)
Press ctrl-c to stop encoding
frame=39032 fps= 39 q=0.0 Lsize=   86385kB time=2607.34 bitrate= 271.4kbits/s    
video:63500kB audio:21841kB global headers:4kB muxing overhead 1.217530%

Cela prend un peu de temps suivant la taille du fichier mais c'est assez simple.

Encoder toutes les vidéos d'un dossier en Webm

Allez, plus efficace : voyons maintenant comment nous pouvons traiter tout un lot de fichiers. Nous allons encoder tous les fichiers MP4 d'un dossier pour faire des fichiers WebM.

Tout d'abord, on exporte la liste des fichiers à traiter dans un fichier nommé list :

ls -1 *.mp4 | sed -e 's:\.[^./]*$::' > list

La commande sed nous permet ici de récupérer la liste des fichiers tout en omettant l'extension des fichiers.

Ensuite, on lance une boucle qui convertit chaque fichier au format WebM :

for i in `cat list`; do avconv -i "$i".mp4 "$i".webm ; done

Et voilà! Simple et efficace.

Dernièrement, j'ai eu l'occasion de jouer avec l'intégration d'un lecteur vidéo en HTML5 pour jouer des vidéos encodées en H.264 (format .MP4) pour un client. Il se trouve qu'aucune vidéo ne se lançait directement : le lecteur chargeait le fichier entièrement (plus de 60 Mo) avant de daigner jouer la vidéo.

h264-logoLa solution est toute simple : de la même manière que l'on peut créer un fichier JPG progressif (qui se charge de haut en bas, sans attendre le chargement total du fichier), il est possible de commencer à lire une vidéo sans que cette dernière soit totalement chargée, grâce à qt-faststart.

qt-faststart

qt-faststart est un outil inclus avec FFmpeg qui ré-arrange un fichier H.264 de manière à ce que le "moov atom" soit devant les données, ce qui facilite la lecture sans attendre le chargement complet.

Si votre fichier MP4 est déjà créé, lancez la commande ainsi :

qt-faststart source_file.mp4 destination_file.mp4

Si vous souhaitez créez un fichier avec l'option faststart nativement, lancez l'encodage FFmpeg avec l'option :

-movflags +faststart 

Et voilà! Les vidéos streament proprement.

Voici les derniers ajouts au site depuis le début de l'année:

  • [+] vous pouvez désormais poster des vidéos en commentaire juste en donnant le lien texte de la vidéo (merci Anne-Gaëlle pour la sugggestion).
  • [+] le javascript est désormais chargé de manière asynchrone grâce à la librairie head.js. En pratique, la page (HTML, CSS, images) se charge et l'utilisateur peut interagir avec immédiatement, le code javascript est lui chargé après. Cela règle le problème que j'avais évoqué en novembre 2012.
  • [+] les gravatars sont désormais chargés depuis le site (et mis en cache par le serveur) au lieu d'être appelés depuis le site gravatar.com, cela limite le nombre de requêtes extérieures. Plugin : GravatarLocalCache.
  • [+] BASH : création d'un script qui répare toutes les tables et bases de données MySQL d'un serveur en cas de crash.
  • [*] réorganisation du fichier sitemap : j'ai retiré les pages archives, tags et catégories du fichier pour ne laisser que les articles et les pages, c'est-à-dire le contenu réel du site. Cela permet d'avoir une idée plus précise de ce qui est réellement indexé par Google : dans Google Webmaster Tools, j'ai maintenant 2,626 pages trouvées dont 2,606 indexées. Le reste ne l'était pas de toute manière.
  • [*] le bug des images corrigé cet hiver ne l'était en fait pas et pour cause : le fichier attachment.php contenait la même routine de vérification que le fichier single.php - celle qui me permet de rediriger quelqu'un qui appelle une page sans contenu (généralement un petit malin). Corrigé cette fois!
  • [*] correction d'un autre bug exotique affectant les images : perte du chemin des images.
  • [*] correction de 1500+ redirections de liens. Avec le temps, les sites changent de structure et les liens aussi. C'est là que l'on se rend compte que beaucoup de sites ferment au fil du temps. Merci Broken Link Checker.
  • [*] le site est intégralement validé en HTML5.
  • [+] Serveur : mise à jour des paquets LAMP avec les dépôts Dotdeb.
  • [*] Serveur : mise à jour vers Debian 7 Wheezy.

Prochaines idées d'optimisations sur lesquelles travailler :

  • soumettre les tablatures dans un fichier sitemap
  • héberger les images et le javascript sur un sous-domaine
  • activer le multisite pour héberger d'autres personnes sur le serveur ?

Ah, ce moment magique durant lequel tu constates que ta note PageSpeed monte à 99%, via GTmetrix :

pagespeed-99-201301

C'est beau, sachant qu'au niveau CSS, c'est la barre WordPress du haut qui génère l'overhead.

Prochaine étape : mettre les fichiers statiques sur un sous-domaine cookieless.

Il y a quelques semaines, la "scene" s'est réunie pour discuter des standards des releases et a décidé d'abandonner le format XviD (.avi) au profit du format x264 (.mp4) pour les releases en SD (Simple Definition). Analyse de la situation.

Pourquoi ce changement ?

La raison invoquée dans le document intitulé The SD x264 TV Releasing Standards 2012 est que "le x264 est devenu le codec vidéo le plus avancé de ces dernières années, capable de fournir une meilleure qualité et une meilleure compression que le XviD à de plus grandes résolutions SD. Il permet aussi un meilleur contrôle et une grande transparence des réglages d’encodage".

Les nouvelles règles sont donc édictées et les groupes qui ne s'y conformeront pas prennent le risque de voir leurs releases "nuked".

Ce document est signé par les groupes ASAP, BAJSKORV, C4TV, D2V, DiVERGE, FTP, KYR, LMAO, LOL, MOMENTUM, SYS, TLA et YesTV. Autant dire qu'à partir de maintenant, ce sera x264 pour tout le monde.

Qu'est-ce que cela change pour nous ?

Alors c'est simple, tout dépend de votre lecteur. Si vous lisez vos séries sur un iPod/iPhone/iPad, le MP4 ne posera aucun problème. Si votre platine DivX lit le MP4, aucun problème. Si vous avez une Freebox HD... vous l'avez dans le bab, il faudra convertir le fichier MP4 au format MKV (et je vous en parlerai très prochainement).

En gros, la scene a choisi un nouveau format bien moins répandu/lisible/universel que l'ancien. La raison évoquée (qualité d'image) me semble un peu éculée, étant donné que l'on reste en SD. Toujours est-il que toutes les releases sont maintenant en x264, ce qui signe l'arrêt de la diffusion des séries en XviD à moyen et long terme.

Rapport de faute d’orthographe

Le texte suivant sera envoyé à nos rédacteurs :