Tu as bien raison, je me suis mélangé un peu les pinceaux.
J'essaye de reprendre :
- Par défaut la ligne de commande n'est pas en UTF-8. Mais une locale 8-bit (histoire, histoire).
- Si l'input est avec la même locale, tu ne peux jamais avoir un caractère Unicode pas dans la locale (si tu ne touche pas aux caractères), pas de soucis (wcout convertit dans la locale).
- Si ton programme parle la même langue que l’utilisateur, miracle ça marche car la locale 8-bit a tes caractères.
- Problème : tu as un caractère qui vient d'ailleurs (exemple : nom de fichier que tu veux afficher, en Russe dans la console sur ton OS français), tu peux faire wcout si tu as envie, la locale est CP-850 et ton russe se fait virer
- Ne fantasme pas sur Windows ça pue, sous Linux c'est exactement pareil, j'en ai aussi chié avec Linux quand celui-ci n'est pas en UTF-8 (genre des vieilles RHEL en fr_FR plutôt que fr_FR.UTF-8). La seule différence est que toutes les distros ont aujourd'hui fait le grand saut vers UTF-8, pas Windows.
- Du coup, j'ai du "code magique" (pas de moi, on m'a filé l'astuce) : "_setmode(_fileno(stdout), _O_U8TEXT);_setmode(_fileno(stderr), _O_U8TEXT);". Qui fait que le term me file du UTF-8 quelque soit la locale réelle et accepte du UTF-8 quelque soit la locale réelle (il l'affiche même!), tout en mettant du UTF-8 sur les redirections (>fichier, parce que ça fait chier mes utilisateur d'avoir la locale du term dans un fichier texte en 2012). Bref, je configure le term en UTF-8 contre la config de l'utilisateur car Windows sait causer UTF-8 quad on lui demande, c'est jsute que par défaut ça ne l'est pas. Je pourrai sans doute faire pareil sous Les Linux, mais les Linux sans UTF-8 se font rares maintenant (même en embarqué) et donc pas de besoin vraiment.
Bref, les merdes de Windows, je connais et je (sur)vis avec. Pas besoin de merdes supplémentaires avec un compilo qui ne sais pas convertir dans la locale de l'utilisateur alors que ce même utilisateur lui a filé la chose juste avant avec exactement la même locale.
[^] # Re: Je cherche à comprendre
Posté par Zenitram (site web personnel) . En réponse à la dépêche Le langage D. Évalué à 4.
Tu as bien raison, je me suis mélangé un peu les pinceaux.
J'essaye de reprendre :
- Par défaut la ligne de commande n'est pas en UTF-8. Mais une locale 8-bit (histoire, histoire).
- Si l'input est avec la même locale, tu ne peux jamais avoir un caractère Unicode pas dans la locale (si tu ne touche pas aux caractères), pas de soucis (wcout convertit dans la locale).
- Si ton programme parle la même langue que l’utilisateur, miracle ça marche car la locale 8-bit a tes caractères.
- Problème : tu as un caractère qui vient d'ailleurs (exemple : nom de fichier que tu veux afficher, en Russe dans la console sur ton OS français), tu peux faire wcout si tu as envie, la locale est CP-850 et ton russe se fait virer
- Ne fantasme pas sur Windows ça pue, sous Linux c'est exactement pareil, j'en ai aussi chié avec Linux quand celui-ci n'est pas en UTF-8 (genre des vieilles RHEL en fr_FR plutôt que fr_FR.UTF-8). La seule différence est que toutes les distros ont aujourd'hui fait le grand saut vers UTF-8, pas Windows.
- Du coup, j'ai du "code magique" (pas de moi, on m'a filé l'astuce) : "_setmode(_fileno(stdout), _O_U8TEXT);_setmode(_fileno(stderr), _O_U8TEXT);". Qui fait que le term me file du UTF-8 quelque soit la locale réelle et accepte du UTF-8 quelque soit la locale réelle (il l'affiche même!), tout en mettant du UTF-8 sur les redirections (>fichier, parce que ça fait chier mes utilisateur d'avoir la locale du term dans un fichier texte en 2012). Bref, je configure le term en UTF-8 contre la config de l'utilisateur car Windows sait causer UTF-8 quad on lui demande, c'est jsute que par défaut ça ne l'est pas. Je pourrai sans doute faire pareil sous Les Linux, mais les Linux sans UTF-8 se font rares maintenant (même en embarqué) et donc pas de besoin vraiment.
Bref, les merdes de Windows, je connais et je (sur)vis avec. Pas besoin de merdes supplémentaires avec un compilo qui ne sais pas convertir dans la locale de l'utilisateur alors que ce même utilisateur lui a filé la chose juste avant avec exactement la même locale.