Ouais, c'est chiant ça…

Ceci dit, non merci, je ne veux pas utilise les touches directionnelles personnellement.

Étant droitier, ce n'est pas pour rien que ces touches là sont devenues célèbres comme secondes touches de direction.

Je me vois mal avec ma main gauche à droite de mon clavier avec ma main droite pas loin. Enfin c'est ptet une question de préférence habitude. Mais je suis beaucoup plus confortable (habitué ?) lorsque j'ai un main de chaque côté. (Puis ça réduit les mouvements nécessaires. L'air de rien c'est super important. Voir clavier BÉPO & co)

Ce que je trouve par contre que les développeurs auraient du faire depuis longtemps serait de :
1) Normaliser ça.
2) Les assigner à un nom (Les touches gauche, droite, haut et bas sont "souvent" référencables par leur nom non? Sinon évidemment, si c'est uniquement par leur code c'est "too bad"), tel que ALTERNATIVE_LEFT ou quelques chose ainsi, qui varieraient donc dynamiquement d'un clavier AZERTY à un clavier QWERTY. Etc.

Ou alors faut tenter de se venger et sortir plein de jeux avec les touches QZSD par défaut. Lulz. (#rire_jaune)

Et toc!

Oooouh, je connaissais pas inspect.getsource, c'est génial. ^-^

AttributeError: 'itertools.count' object has no attribute 'next'

Arf …

Le code suivant ne fonctionne donc plus en Python 3 :

>>> import itertools, collections
>>> value_to_numeric_map = collections.defaultdict(itertools.count().next)
>>> value_to_numeric_map['a']
0
>>> value_to_numeric_map['b']
1
>>> value_to_numeric_map['c']
2
>>> value_to_numeric_map['a']
0
>>> value_to_numeric_map['b']
1

La première solution venant à l'esprit serait d'avoir à instancier une variable :

>>> c = itertools.count()
>>> value_to_numeric_map = collections.defaultdict(lambda a: next(c))

Et ça fonctionne très bien.

Mais personnellement, je préfère lorsque ça reste one-line, donc voici une alternative one-line :

J'utilise lambda pour créer une encapsulation (closure).

value_to_numeric_map = collections.defaultdict((lambda c: (lambda: next(c)))(itertools.count()))

Lien précédent : http://www.olissea.com/mb/links/1/?ibR8_g

EDIT: J'ai trouvé ce problème ceci dit: https://bugs.php.net/bug.php?id=65045
Mais j'ignore si je suis vraiment concerné : ça dépend en effet si mon script capture ces séquences à problèmes mais il me semble qu'il ne capture que les séquences valides de 4 bytes, donc pas de problème normalement.

Également, j'ai pas trop compris comment ça se fait, mais lorsque j'applique htmlspecialchars sur les séquences données sur la page, l'output n'est pas vide. Ne devrait-il pas l'être (vu que htmlspecialchars renvoie stupidement une chaîne vide lorsqu'il reçoit de l'UTF-8 invalide normalement ?).

Mmmmmh.
</EDIT>

"Plop.

Après mainte péripéties et échecs, je pense avoir trouver quelque chose de "potable".

Voir le code avec coloration syntaxique (un peu différent, manque une source) : http://sebsauvage.net/paste/?e249576d75ee9946#jBpv2UCufTQ4UC2WnTtM11gfolfGkQi61brf11pFORU=

<?php

# "😒" est codé sur 4 bytes
$body = 'lol😒a☺';

echo 'before: ',$body,'<br />'; # Output: lol😒a☺
echo 'length: ',strlen($body),'<br />'; # Output: 11 (😒 = 4, ☺ = 3)

# Le but est de remplacer uniquement les caractères de plus de 3 bytes par leur entité HTML.
# Afin d'obtenir ce code dans le cas de notre exemple
echo '😒','<br />'; # Fourni par https://duckduckgo.com/?q=html+%F0%9F%98%92

# Récupération des caractères de plus de 3 bytes uniquement
# Source: http://stackoverflow.com/a/1401716/1524913
# $body = preg_replace('/[\xF0-\xF7][\x80-\xBF]{3}/', '�', $body); # Yeah! It works!

# Ne fonctionne pas. htmlentities ne connaît pas tous les caractères unicode ( http://stackoverflow.com/a/13942507/1524913 )
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return htmlentities($m[0], ENT_COMPAT, 'UTF-8');}, $body); # Ignore complètement 😒

# La solution proposée au lien précédemment cité : Ne fonctionne pas non plus
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return str_replace('\\u','&#x',trim(json_encode($m[0]),'"')).';';}, $body);
# Output: lol��a☺ car json_encode considère ça comme deux caractères de deux bytes et renvoie "\ud83d\ude12"

# Ne fonctionne pas ( http://php.net/manual/en/function.htmlentities.php#107985 )
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return mb_encode_numericentity($m[0], array(0x0, 0xffff, 0, 0xffff), 'UTF-8');}, $body); # Ignore complètement 😒

# Fonctionne !!! Mais renvoie &#128530 au lieu de 😒 (Pas vraiment un problème en soit)
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return mb_convert_encoding($m[0], 'HTML-ENTITIES', 'UTF-8');}, $body);

# Si on veut vraiment la version hexadécimal
$body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return '&#x'.dechex(substr(mb_convert_encoding($m[0], 'HTML-ENTITIES', 'UTF-8'), 2)).';';}, $body);

echo 'after: ',$body,'<br />'; # Output: lol😒a☺

?> "

Chouette lecture.

Important à savoir pour le bon vivre de toute communauté grandissante.

Je ne suis pas d'accord avec tout ceci dit. :)
Moi même ayant posé certaines de ces questions par le passé par exemple. (section "question impossible") Et même si je ne poserais pas ce genre de question sur Stack Overflow (par exemple) - et ça se comprend pourquoi mais lorsque j'ai personnellement posé ces questions (y a longtemps) c'était avec sincérité, car il faut commencer par là, quand on ne sait rien (et rien de mal à ça, on débute tous quelque part), histoire d'avoir les grandes lignes, des indications par où commencer, …

Juste avoir une fonction correcte, facile à utiliser, qui ne me renvoie pas une chaîne de caractère vide si l'input contient de l'utf-8 invalide.

Et, dût ma contrainte technique, la seule alternative que j'ai (ENT_IGNORE) est déconseillée … Doh.

( EDIT: [Je raconte ma vie]

Pis PHP ne cesse de m'épater dans le mauvais sens et plus j'investigue plus j'suis aberré.
M'enfin … ça n'a pas que du mauvais, ça m'aide à me forcer à faire plus de Python et moins de PHP.

Pour ceux qui continuent à me demander pourquoi je fais encore du PHP je répondrais que les vieilles habitudes ont la vie dure, qu'il faudrait que je transcrive tout mes scripts PHP vers Python, c'est beaucoup de boulot … tellement qu'on préfère souvent la simplicité de continuer les vieilles habitudes et/ou quand on a pas le choix / temps et qu'on a besoin que qu'une appli ou autre soit fonctionnelle dans les temps. Et malheureusement, j'ai encore trop de setup à faire pour que je puisse le faire via Python, mais ça vient ptit à ptit. ☺
)

EDIT 2:

Je pense que le plus simple/efficace serait, comme je l'avais fait une fois sans vraiment avoir étudier la question en profondeur, serait de juste réimplémenter la fonction via str_replace qui lui est apparemment 100% utf-8 safe.

À vérifier.

Petite mise à jour de PickyPaste.

La version indev (le lien que je viens de passer), renvoie le lien vers la version indev, c'est mieux.

À la proposition de Bronco, j'ai rajouté un chtit lien "Répondre via PickyPaste" si l'utilisateur a spécifié son adresse email.

Voilà, c'tout.

Quelle connerie…

J'ai ris à la fin par contre, le grand n'importe quoi :

"You’re as French as the fake Eiffel Tower in Las Vegas. You’re probably a sweet, enthusiastic and optimistic human being, and that’s precisely why France isn’t a place for you. Try Belgium instead."

Ahahah, la belle ironie ! =)

… On est HUMAINS avant tout. -.-'
Je devrais juste dire être vivant même je trouve.

(via http://shaarli.warriordudimanche.net/?f2J0Aw )

Site qui a l'air intéressant et contenant pas mal d'astuces et des news types "bonnes nouvelles" (et ça c'est chouette) …

Mais qui manque cruellement de sources dans beaucoup d'articles. :/

Au moins les pistes données ont l'avantages d'être intéressantes, donc je suis presque sûr qu'avec un peu d'effort personnel et de recherches sur le net, il y a moyen de confirmer (plus sérieusement / scientifiquement / whatev) quelques chouettes infos.