(car c'est toujours plus facile d'apprendre à taper sur un clavier physique correspondant à la map utilisée).
En fait, pas vraiment. Si tu as besoin d'un marquage quelconque sur ton clavier, c'est que tu regardes ton clavier, donc que tu apprends mal à t'en servir.
Par contre ça va être indispensable de sortir des claviers physiques avec les nouveaux marquages parce que rares sont les gens – y compris ceux dont une bonne partie du métier consiste à saisir des trucs au clavier – regardent leur clavier en tapant…
Le principal changement au quotidien c'est l'inversion des apostrophes française ’ et droite '. La française passe en accès directe, et la droite en altgr-,… ce qui est génial pour le français et très chiant pour certains langages de programmation.
La vraie question est : pourquoi on trouve sur presque tous les claviers du monde une apostrophe qui n'existe dans presque aucune langue du monde ?
Le / est en accès direct assez facile (en BÉPO y'a le m sur cette touche), tu as dû confondre avec la touche morte /.
Le ç est très logiquement en altgr-c. Je ne suis même pas sûr qu'il soit vraiment moins accessible qu'en BÉPO, où il est en accès direct mais au bout du petit doigt (touche * avec marquage AZERTY).
L'opposé de gamin, c'est adulte non ? Quoique quand je vois le comportement de certains « adultes » j'ai un doute (c'est une vérité générale et pas une attaque sur la personne à qui je réponds).
Cela dit, j'aime beaucoup l'image d'un type qui essaierait de programmer en C uniquement à l'aide de ses attributs. Ça doit vite être complexe quand il faut utiliser des combinaisons de touches.
Et douloureux.
Il y a un équivalent du BÉPO optimisé pour couilles ?
Supprimer le journal serait dommage vu les commentaires intéressants qu'il a généré. Mais on pourrait « remplacer la traduction par un résumé » (déjà vu).
J'ai répondu à la FSF que du coup, ça semblait incohérent et pas qu'à moi. Leur réponse :
I can only re-emphasise that we don't support the idea that all
possible kinds of works should be free, or even freely
re-distributable. What we say is that software should be free,
and that its documentation should be free
Eh bien, désolé, mais il va falloir supprimer cette traduction. J'ai posé la question (par mail), auquel ils m'ont répondu que :
Je peux traduire cette page… si je ne la montre à personne d'autre ! (« if you don't show it anybody else. »). Si on veut la publier, il faut suivre cette doc. Ça implique de traduire, de soumettre la traduction à leur propre équipe de traduction, ils la publient sur www.gnu.org et là seulement on peut re-publier leur traduction qui est obligatoirement sous CC BY-ND.
L'explication d'eingousef était la bonne. Pour eux, c'est une opinion, pas un logiciel ou un travail qui a un intérêt pratique, ils conservent le copyright pour éviter les mésinterprétations – et me renvoient vers cette source. Pour eux ce n'est pas incohérent avec leur message général.
En plus de ça, la majorité des eurodéputés a une proportion d'erreurs bien plus basse que ceux incriminés ici. Nos eurodéputés français seraient-ils si mauvais qu'ils n'arrivent pas à s'organiser là où la majorité de leurs collègues y parviennent très bien ?
Le fond de la question est : en quoi aurait-il été dommage de la jeter ?
C'est toujours un peu triste de jeter du travail déjà fait, mais vaut-il mieux publier une dépêche moyennement peu pertinente pour éviter de perdre une traduction, ou se dire que tant pis, ça n'a plus vraiment de sens, et l'abandonner ?
C'est de vraies questions et j'ai l'impression que le cœur de la dispute vient du fait que vous n'y apportez pas les mêmes réponses.
C'est assez vrai. Dans le cas de Java, l'effet est renforcé par :
L'historique du langage (fonctionnalités arrivées tard) que certains n'ont toujours pas intégrés (en réalité / dans leurs reproches)
Un langage (et un moteur d'exécution) qui comporte plus de subtilités qu'on pourrait le croire (comme la gestion mémoire), ou dont le fonctionnement change avec le temps (le garbage collector / le compilateur JIT)
Le fait que c'est un langage orienté Entreprise™ avec tout ce que ça implique comme :
Les équipes ultra-morcelées avec des gens qui bossent 3 mois sur un tout petit bout du code
Les projets très longs et très chers donc impossibles à refacto / réécrire
La faiblesse de la communauté open-source et de l'outillage qui peut arriver avec (ne serait-ce que des règles aussi idiotes qu'un formatage du code par défaut)
PHP me donnait plus l'impression de poser problème à cause de failles intrinsèques au langage (PHP 4 était une jolie collection d'incohérences) ; JS plus à cause de sa communauté et de son mode de fonctionnement ultra-éclaté.
PS : les prérequis éditeurs, par contre c'est une vraie plaie. Dédicace à IBM qui vends des logiciels Java qui ne fonctionnent que sur une JVM IBM (J9, maintenant libéré sous le nom OpenJ9 et propriétés de la fondation Eclipse). Mais c'est généralement des limitations arbitraires.
Ca bouffe un tas de ram puisque tu dois fixer un minimum/maximum
Ça consomme la RAM que tu lui demande. Libérer de la RAM, ça veut dire passer le GC, donc c'est consommateur, donc tant qu'on peut éviter, on évite. Pendant très longtemps les JVM ont considéré que ce que tu lui donne en max, ils peuvent le consommer sans problème, Java 12 a justement une évolution pour rendre la RAM libérée au plus vite.
Cela dit, le vrai problème de la gestion de la RAM avec la JVM, c'est les développeurs qui confondent garbage collector avec c'est magique j'ai plus besoin de gérer la RAM, et donc qui développent des programmes qui sont en gros une fuite mémoire géante. Et qui accusent la JVM de leur propre merde ensuite.
ça log comme ça veut et ça ne respecte pas les logrotate
Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.
Ah oui et la tendance naturelle à crasher au moindre pépin, par exemple sur un lag de BDD c'est vraiment génial.
Là encore, ça dépend principalement de comment tu as codé ton application.
En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.
Mais c'est bien plus facile d'accuser la JVM que de se remettre en question, je suppose.
même Microsoft qui est une grande union (d'actionnaire, de développeurs…) s'y est cassé les dents avec Windows Mobile arrivé trop tard sur le marché du coup déjà saturé.
J'ai eu l'occasion d'avoir un téléphone sous Windows Mobile 5.0 à l'été 2005, soit avant l'arrivée de l'iPhone et de quasiment tous les smartphones. Microsoft ne s'est pas pété les dents sur le marché du smartphone parce qu'ils sont arrivés trop tard avec Windows Mobile, mais parce qu'ils ont fait une collection hallucinante de mauvais choix :
Ergonomie catastrophique (Windows Mobile avait à peu près la tronche d'un Windows de bureau, sur un téléphone bien plus petit qu'un smartphone actuel)
Stabilité inexistante
Performances horribles
N'a pas pris le virage des smartphones tels qu'ils se sont développés à partir de 2008
etc (dont sans doute plein de choix douteux quant à leur intégration et les applications tierces).
Ils ont fini par redresser le tir et Windows Mobile 8 et surtout 10 n'étaient techniquement pas de mauvais produits, mais c'était beaucoup trop tard… par contre, objectivement ils étaient là avant presque tout le monde !
J'ai déjà répondu au gros du message plus bas, avant que tu ne le postes. Je trouves ça triste de vouloir restreindre l'incroyable richesse des langues mondiales, et de vouloir imposer un système d'écriture qui n'est pas celui de l'incroyable majorité de la population mondiale (pas même du français, à cause des diacritiques).
Cela dit :
on devrait utiliser du utf-16 ou utf-32; où les caractères sont de taille fixe.
PS : tu mélanges un peu tout. Unicode a prévu des classes de caractères. Pour la programmation, il suffit de n'accepter comme identifiants que ce qui est un caractère réel, pas un symbole ou une espace etc.
Je ne m'étonne guère de votre intervention. En postant ici, comme d'habitude, je pensais m'attirer la foudre…Et bingo !
Pourquoi tu as posté alors ? Si tu sais qu'on ne veut pas de ta publicité et que tu n'en retireras rien… contentes-toi de ne pas poster. Ça t'éviteras une perte d'énergie, et de venir chouiner en public en faisant des généralités de ton cas particulier.
Et ce sera infiniment plus agréable pour tout le monde.
Déjà l'honnêteté intellectuelle m'oblige à préciser qu'en réalité,tant qu'on parle de la JVM ICU permet déjà ce genre de chose (en plus complet mais avec une API plus compliquée, et sans garantie quant à la gestion des catégories, cf ci-dessous).
Et quelques précisions pour répondre aux commentaires ci-dessus.
Bien évidemment, ce genre d'outil ne doit servir en aucun cas à forcer du simple ASCII. Unicode est un progrès gigantesque dans un monde où les outils de l'état massacrent encore les noms et prénoms de ses propres citoyens (ceux qui ont une diacritique dans leur nom ou prénom savent à quel point elle est souvent supprimée). Ne nous servons pas de ces possibilités pour régresser, merci.
C'est pour ça qu'il y a des outils pour récupérer des alias et surtout des catégories sur les caractères ; et surtout que les outils de gestion des confusions permettent de gérer des catégories de caractères « de base ». Par exemple pour une application en Français, on voudrait d'autoriser / ne détecter les risques de confusion qu'au sein d'une classe de caractères. Par exemple, une application en français voudrait pouvoir éviter les chaines qui contiennent des caractères que l'on peut confondre avec des caractères latins mais qui n'en sont pas (les caractères latins sont considérés comme légitimes). Une application en russe voudrait elle que ce soit les caractères cyrilliques qui sont légitimes. Je vous renvoie à la doc pour plus de détails1
Aujourd'hui ce qu'il manque à confusables-homoglyphs, c'est l'équivalent des skeleton de ICU, c'est-à-dire une fonctionnalité qui permet d'enregistrer une version « normalisée » d'une chaine de caractères. Cette version n'est pas utilisable à l'affichage, mais permet des comparaisons : deux chaines de même squelette peuvent être confondues. En enregistrant le squelette dans un champ ad hoc, on peut autoriser par exemple des pseudonymes avec n'importe quels caractères, tout en interdisant facilement tout autre pseudonyme homoglyphe.
Enfin, tout l'intérêt des exemples était de montrer que dans certains cas, il n'y a absolument aucun moyen graphique de discerner deux homoglyphes. En réalité l'exemple des noms de domaines était repiqué de la doc d'origine, mais est assez mauvais parce que les navigateurs vont afficher le nom de domaine canonique, donc http://www.xn--faebook-6pf.com/ et http://www.xn--microsft-sbh.com/ – en plus du fait que les utilisateurs font rarement attention à ce qu'il y a dans la barre d'URL.
Celle du projet Python d'origine, j'ai oublié de publier la doc Java… ↩
D'autre part, au-delà du troll sur Java, je serais curieux de voir le concept poussé dans d'autres langages, pour voir si ça fonctionne vraiment au-delà de la théorie.
J'ai testé uniquement avec une JVM OpenJDK 11. Si j'y pense, j'essaierai avec une OpenJ9 11 (anciennement IBM, maintenant fondation Eclipse) – mais ça attendra lundi que le PC sur lequel c'est installé soit réparé.
[^] # Re: Avec du bépo dedans
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal La norme française de dispositions de clavier a été publiée. Évalué à 3.
En fait, pas vraiment. Si tu as besoin d'un marquage quelconque sur ton clavier, c'est que tu regardes ton clavier, donc que tu apprends mal à t'en servir.
Par contre ça va être indispensable de sortir des claviers physiques avec les nouveaux marquages parce que rares sont les gens – y compris ceux dont une bonne partie du métier consiste à saisir des trucs au clavier – regardent leur clavier en tapant…
La connaissance libre : https://zestedesavoir.com
[^] # Re: Avec du bépo dedans
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal La norme française de dispositions de clavier a été publiée. Évalué à 6. Dernière modification le 05 avril 2019 à 15:23.
Ils l'ont légèrement modifiée, ce sera la 1.1.
Le principal changement au quotidien c'est l'inversion des apostrophes française
’et droite'. La française passe en accès directe, et la droite enaltgr-,… ce qui est génial pour le français et très chiant pour certains langages de programmation.La vraie question est : pourquoi on trouve sur presque tous les claviers du monde une apostrophe qui n'existe dans presque aucune langue du monde ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: tout ça pour ça
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Claviers français : 2 dispositions normalisées ! L’Afnor nous propose BÉPO et un nouvel AZERTY. Évalué à 2. Dernière modification le 04 avril 2019 à 20:00.
Le
/est en accès direct assez facile (en BÉPO y'a lemsur cette touche), tu as dû confondre avec la touche morte/.Le
çest très logiquement en altgr-c. Je ne suis même pas sûr qu'il soit vraiment moins accessible qu'en BÉPO, où il est en accès direct mais au bout du petit doigt (touche*avec marquage AZERTY).La connaissance libre : https://zestedesavoir.com
[^] # Re: Macron
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Claviers français : 2 dispositions normalisées ! L’Afnor nous propose BÉPO et un nouvel AZERTY. Évalué à 4.
Les maniaques japonophiles qui écrivent Tōkyō vont être contents aussi :)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 2.
L'opposé de gamin, c'est adulte non ? Quoique quand je vois le comportement de certains « adultes » j'ai un doute (c'est une vérité générale et pas une attaque sur la personne à qui je réponds).
Cela dit, j'aime beaucoup l'image d'un type qui essaierait de programmer en C uniquement à l'aide de ses attributs. Ça doit vite être complexe quand il faut utiliser des combinaisons de touches.
Et douloureux.
Il y a un équivalent du BÉPO optimisé pour couilles ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: leçon de vie
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Festival d'installation : Jusqu'où et comment pactiser avec le diable ?. Évalué à 5.
Supprimer le journal serait dommage vu les commentaires intéressants qu'il a généré. Mais on pourrait « remplacer la traduction par un résumé » (déjà vu).
La connaissance libre : https://zestedesavoir.com
[^] # Re: La FSF m'a répondu, il n'a pas les droits.
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Festival d'installation : Jusqu'où et comment pactiser avec le diable ?. Évalué à 6.
J'ai répondu à la FSF que du coup, ça semblait incohérent et pas qu'à moi. Leur réponse :
La connaissance libre : https://zestedesavoir.com
[^] # La FSF m'a répondu, il n'a pas les droits.
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Festival d'installation : Jusqu'où et comment pactiser avec le diable ?. Évalué à 7. Dernière modification le 01 avril 2019 à 14:54.
Eh bien, désolé, mais il va falloir supprimer cette traduction. J'ai posé la question (par mail), auquel ils m'ont répondu que :
La connaissance libre : https://zestedesavoir.com
[^] # Re: As-tu les droits?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Festival d'installation : Jusqu'où et comment pactiser avec le diable ?. Évalué à 3. Dernière modification le 01 avril 2019 à 11:19.
Tiens, je vais leur demander pourquoi, par curiosité.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 4.
Apparemment pour bien programmer en C, il semble nécessaire de taper au clavier non pas avec ses doigts mais avec ses testicules.
Ce qui m'amène deux remarques :
La connaissance libre : https://zestedesavoir.com
[^] # Re: une explication de Mélenchon
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Félonie au parlement européen. Évalué à 9.
En plus de ça, la majorité des eurodéputés a une proportion d'erreurs bien plus basse que ceux incriminés ici. Nos eurodéputés français seraient-ils si mauvais qu'ils n'arrivent pas à s'organiser là où la majorité de leurs collègues y parviennent très bien ?
La connaissance libre : https://zestedesavoir.com
# Et ça continue…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Félonie au parlement européen. Évalué à 4.
https://www.nextinpact.com/brief/directive-droit-d-auteur---13-eurodeputes-affirment-s-etre-trompes-lors-du-vote-8264.htm
La connaissance libre : https://zestedesavoir.com
[^] # Re: On se rapproche doucement des types sommes
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 2.
De ce que je vois des dernières fonctionnalités, j'ai plus l'impression qu'ils lorgnent du côté de Kotlin.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Alors ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Il y a six mois Linus décidait de changer, a‐t‐il réussi ?. Évalué à 4.
Le fond de la question est : en quoi aurait-il été dommage de la jeter ?
C'est toujours un peu triste de jeter du travail déjà fait, mais vaut-il mieux publier une dépêche moyennement peu pertinente pour éviter de perdre une traduction, ou se dire que tant pis, ça n'a plus vraiment de sens, et l'abandonner ?
C'est de vraies questions et j'ai l'impression que le cœur de la dispute vient du fait que vous n'y apportez pas les mêmes réponses.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 4.
C'est assez vrai. Dans le cas de Java, l'effet est renforcé par :
PHP me donnait plus l'impression de poser problème à cause de failles intrinsèques au langage (PHP 4 était une jolie collection d'incohérences) ; JS plus à cause de sa communauté et de son mode de fonctionnement ultra-éclaté.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 3.
PS : les prérequis éditeurs, par contre c'est une vraie plaie. Dédicace à IBM qui vends des logiciels Java qui ne fonctionnent que sur une JVM IBM (J9, maintenant libéré sous le nom OpenJ9 et propriétés de la fondation Eclipse). Mais c'est généralement des limitations arbitraires.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 10.
Ça consomme la RAM que tu lui demande. Libérer de la RAM, ça veut dire passer le GC, donc c'est consommateur, donc tant qu'on peut éviter, on évite. Pendant très longtemps les JVM ont considéré que ce que tu lui donne en max, ils peuvent le consommer sans problème, Java 12 a justement une évolution pour rendre la RAM libérée au plus vite.
Cela dit, le vrai problème de la gestion de la RAM avec la JVM, c'est les développeurs qui confondent garbage collector avec c'est magique j'ai plus besoin de gérer la RAM, et donc qui développent des programmes qui sont en gros une fuite mémoire géante. Et qui accusent la JVM de leur propre merde ensuite.
Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.
Là encore, ça dépend principalement de comment tu as codé ton application.
En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.
Mais c'est bien plus facile d'accuser la JVM que de se remettre en question, je suppose.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Choix facile
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Navigateur web, l'impossible choix. Évalué à 6.
J'ai eu l'occasion d'avoir un téléphone sous Windows Mobile 5.0 à l'été 2005, soit avant l'arrivée de l'iPhone et de quasiment tous les smartphones. Microsoft ne s'est pas pété les dents sur le marché du smartphone parce qu'ils sont arrivés trop tard avec Windows Mobile, mais parce qu'ils ont fait une collection hallucinante de mauvais choix :
Ils ont fini par redresser le tir et Windows Mobile 8 et surtout 10 n'étaient techniquement pas de mauvais produits, mais c'était beaucoup trop tard… par contre, objectivement ils étaient là avant presque tout le monde !
La connaissance libre : https://zestedesavoir.com
# Langues
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Conférence : «Le logiciel libre face à l'informatique» - Richard Stallman - 29/03 - ISTIC Rennes. Évalué à 5.
Pourquoi le résumé et la bio sont en anglais si la conférence est en français ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est très bien fait
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien coloriser avec le deep learning des photos noires et blancs. Évalué à 4.
Une photo noir et blanc d'un paysage sur Mars donne des résultats très étonnants (et ma foi assez jolis).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Microsоft.com, Faϲebook.com
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche confusable-homoglyphs : une bibliothèque pour gérer les caractères qui se ressemblent. Évalué à 2. Dernière modification le 19 mars 2019 à 21:56.
J'ai déjà répondu au gros du message plus bas, avant que tu ne le postes. Je trouves ça triste de vouloir restreindre l'incroyable richesse des langues mondiales, et de vouloir imposer un système d'écriture qui n'est pas celui de l'incroyable majorité de la population mondiale (pas même du français, à cause des diacritiques).
Cela dit :
Les caractères UTF-16 n'ont pas une taille fixe (même si ce n'est pas la même gestion qu'avec UTF-8).
PS : tu mélanges un peu tout. Unicode a prévu des classes de caractères. Pour la programmation, il suffit de n'accepter comme identifiants que ce qui est un caractère réel, pas un symbole ou une espace etc.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Mais bien-sur !
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Elphyrecoin : la cryptomonnaie au service de l'opensource. Évalué à 10.
Pourquoi tu as posté alors ? Si tu sais qu'on ne veut pas de ta publicité et que tu n'en retireras rien… contentes-toi de ne pas poster. Ça t'éviteras une perte d'énergie, et de venir chouiner en public en faisant des généralités de ton cas particulier.
Et ce sera infiniment plus agréable pour tout le monde.
La connaissance libre : https://zestedesavoir.com
# Quelques précisions…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche confusable-homoglyphs : une bibliothèque pour gérer les caractères qui se ressemblent. Évalué à 8. Dernière modification le 15 mars 2019 à 17:24.
Hello,
Déjà l'honnêteté intellectuelle m'oblige à préciser qu'en réalité,tant qu'on parle de la JVM ICU permet déjà ce genre de chose (en plus complet mais avec une API plus compliquée, et sans garantie quant à la gestion des catégories, cf ci-dessous).
Et quelques précisions pour répondre aux commentaires ci-dessus.
Je précise que l'outil fait de la détection multi-caractères :
©et(c)vont être considérés comme pouvant être confondus (dans les deux sens).Bien évidemment, ce genre d'outil ne doit servir en aucun cas à forcer du simple ASCII. Unicode est un progrès gigantesque dans un monde où les outils de l'état massacrent encore les noms et prénoms de ses propres citoyens (ceux qui ont une diacritique dans leur nom ou prénom savent à quel point elle est souvent supprimée). Ne nous servons pas de ces possibilités pour régresser, merci.
C'est pour ça qu'il y a des outils pour récupérer des alias et surtout des catégories sur les caractères ; et surtout que les outils de gestion des confusions permettent de gérer des catégories de caractères « de base ». Par exemple pour une application en Français, on voudrait d'autoriser / ne détecter les risques de confusion qu'au sein d'une classe de caractères. Par exemple, une application en français voudrait pouvoir éviter les chaines qui contiennent des caractères que l'on peut confondre avec des caractères latins mais qui n'en sont pas (les caractères latins sont considérés comme légitimes). Une application en russe voudrait elle que ce soit les caractères cyrilliques qui sont légitimes. Je vous renvoie à la doc pour plus de détails1
Aujourd'hui ce qu'il manque à confusables-homoglyphs, c'est l'équivalent des skeleton de ICU, c'est-à-dire une fonctionnalité qui permet d'enregistrer une version « normalisée » d'une chaine de caractères. Cette version n'est pas utilisable à l'affichage, mais permet des comparaisons : deux chaines de même squelette peuvent être confondues. En enregistrant le squelette dans un champ ad hoc, on peut autoriser par exemple des pseudonymes avec n'importe quels caractères, tout en interdisant facilement tout autre pseudonyme homoglyphe.
Enfin, tout l'intérêt des exemples était de montrer que dans certains cas, il n'y a absolument aucun moyen graphique de discerner deux homoglyphes. En réalité l'exemple des noms de domaines était repiqué de la doc d'origine, mais est assez mauvais parce que les navigateurs vont afficher le nom de domaine canonique, donc http://www.xn--faebook-6pf.com/ et http://www.xn--microsft-sbh.com/ – en plus du fait que les utilisateurs font rarement attention à ce qu'il y a dans la barre d'URL.
Celle du projet Python d'origine, j'ai oublié de publier la doc Java… ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: Unicode
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Des emojis en SQL ? C'est possible… et on peut aller au-delà !. Évalué à 2.
D'autre part, au-delà du troll sur Java, je serais curieux de voir le concept poussé dans d'autres langages, pour voir si ça fonctionne vraiment au-delà de la théorie.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Unicode
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Des emojis en SQL ? C'est possible… et on peut aller au-delà !. Évalué à 2.
J'ai testé uniquement avec une JVM OpenJDK 11. Si j'y pense, j'essaierai avec une OpenJ9 11 (anciennement IBM, maintenant fondation Eclipse) – mais ça attendra lundi que le PC sur lequel c'est installé soit réparé.
La connaissance libre : https://zestedesavoir.com