Auteur/autrice : habett

Ma seconde machine est un mac sur lequel j’utilise Safari. Lors d’un partage d’URL, je constate que lorsque je copie l’adresse d’un site avec un accent dans le chemin, il embarque

https://jadetognet3.wixsite.com/cap-eana/je-découvre-mon-école-1

Alors que Chrome et Firefox utilisent

https://jadetognet3.wixsite.com/cap-eana/je-d%C3%A9couvre-mon-%C3%A9cole-1

C’est un biais de ces dernières années d’afficher dans la barre d’adresse l’URL déséchapée et de copier l’URL réelle. Safari a tort ce qui pose des problèmes lors de la réutilisation de l’URL (par exemple document traitement de texte) même si Pages.app s’en accommode fort bien.

Cela me semble l’occasion de s’amuser un peu avec Automator.app avec pour objectif de mettre un lien avec l’URL bien échappée et le libellé du lien bien normalisé donc deux expressions d’une même adresse.

Je crée donc un workflow qui accepte en entrée des URLs depuis Safari.app, puis j’utilise le module « Get current web page from Safari » (qui envoie l’URL brute échappée), puis le module « Run shell Script » dans lequel je sélectionne perl et « pass input as arguments ». Reste à copie ce script:

#!/usr/bin/perl
use URI::Escape;
$str = $ARGV[0];
$tito = uri_unescape($str);
print `echo "<meta charset="utf8"><a href="\&quot;$str\&quot;">$tito</a> " | textutil -stdin -format html -convert rtf -stdout | pbcopy`;

Le gros hook dans ce script est de bien inclure le meta charset dans le bout de html passé à textutil puis pbcopy (j’ai perdu pas mal de temps avec des problèmes d’encodage).

Plus qu’a créer un raccourci clavier dans les préférences d’accessibilité et le tour est joué. Cependant, sous Monterey, Automator.app est en cours de déprécation. Je passe conduire sur Shortcuts.app avec quelques hooks en raison de bugs de leur part ou d’incompréhensions de ma part. Reste que la solution suivante est fonctionnelle:

Je mets ici le script:

use URI::Escape;
$loco = $ARGV[0];
open(J,'<',$loco);
$str = <J>; 
chomp($str);
close(J);
print($str);
$tito = uri_unescape($str);
print `echo "<meta charset='utf8'><a href='$str'>$tito</a>" | textutil -stdin -format html -convert rtf -stdout | pbcopy`;

Cheers

use Unicode::Normalize;
sub sansaccents() {
my $s = shift();
my $d = NFKD( $s );
$d =~ s/\p{NonspacingMark}//g;
return $d;
}

Grand fan de l’initiative letsencrypt (https://letsencrypt.org/) dont parle souvent l’EFF (https://www.eff.org/) (je suis membre), j’ai eu des problèmes avec la vérification des certificats générés par ce service sur un serveur avec une installation un peu ancienne. curl et LWP me refusaient en raison de problèmes de certificats.
https://community.letsencrypt.org/t/certificate-verification-errors-when-using-curl/105335 a attiré mon attention sur le fait qu’il me manquait la ligne, à priori propre à apache 2,2 suivante, à adapter au bon domaine, dans ma config apache:
SSLCertificateChainFile /etc/letsencrypt/live/privatestash.org/chain.pem

Une fois en place, plus besoin de bypass de la vérification des certificats dans LWP (use IO::Socket::SSL; $ua->ssl_opts( SSL_verify_mode => IO::Socket::SSL::SSL_VERIFY_NONE, verify_hostname =>0);) et plus besoin des mêmes options dans curl (-k), ce qui est bien plus satisfaisant.

Le truc bizarre est que les browsers ne pâtissaient pas de ce point.