Détecter le jeu de caractères

Bonjour tout le monde,

Ayant téléchargé des images d'origine asiatique je cherche à créer des raccourcis dessus.

Quelquefois ça marche, quelquefois non, paraît-il que le nom de fichier n'est pas "dans la plage attendue". Donc, pour le dire autrement, si on attend un nom de fichier entre 1 et 100 et que le nom est de 101, ça ne marche pas. Enfin ... si on veut lire ça au pied de la lettre.

Apparemment, il faut que je fasse attention au jeu de caractères dans lequel est reçu le nom, et je ne sais pas vraiment par où prendre ça.

Si, pour la création de raccourci, je sélectionne le fichier à la main dans l'explorateur (méthode "marteau-burin"), le raccourci est créé, mais si je le lis dans Visual Studio (par CreateShortcut) et que dans la fenêtre d'exécution je veux afficher le chemin de la cible, les caractères asiatiques sont remplacés par des points d'interrogation à l'affichage, dit autrement ils sont dans un jeu de caractères non pris en charge dans la fenêtre d'exécution de Visual Studio.

Code:

---

IWshShortcut link = (IWshShortcut)shell.CreateShortcut(strPathShortcut + ".lnk");

---

Alors que dans les cas où la création de raccourci génère une erreur, en revanche Visual Studio peut afficher les caractères en question.

Alors je veux bien faire une conversion, mais les méthodes que je connais pour faire ça nécessitent de connaître le jeu de caractères de départ et celui d'arrivée. D'où la question : comment m'y prendre pour savoir dans quel jeu de caractères est exprimé un nom de fichier ?

Pour avoir des points de repère j'ai affiché le contenu d'un nom caractère par caractère, j'obtiens
? fitarget.FullName[78]
12488 'ト'

Et là je me retrouve avec une autre question à poser. Comme vous le voyez, l'affichage de ce caractère occupe la largeur de deux caractères ASCII. Pourtant, fitarget.FullName[78].length vaut 1.

Pour connaître cette longueur occupée dans la mise en forme, afin de pouvoir aligner les colonnes, là aussi je pourrais utiliser la "méthode marteau-burin", et dans la chaîne résultat pour l'affichage du caractère chercher l'apostrophe avant et après, et calculer la différence.

J'imagine qu'il existe un moyen un peu plus ... "dans les clous" ?

Citation:

---

Envoyé par Gluups

Bonjour tout le monde,

Ayant téléchargé des images d'origine asiatique je cherche à créer des raccourcis dessus.

Quelquefois ça marche, quelquefois non, paraît-il que le nom de fichier n'est pas "dans la plage attendue". Donc, pour le dire autrement, si on attend un nom de fichier entre 1 et 100 et que le nom est de 101, ça ne marche pas. Enfin ... si on veut lire ça au pied de la lettre.

Apparemment, il faut que je fasse attention au jeu de caractères dans lequel est reçu le nom, et je ne sais pas vraiment par où prendre ça.

Si, pour la création de raccourci, je sélectionne le fichier à la main dans l'explorateur (méthode "marteau-burin"), le raccourci est créé, mais si je le lis dans Visual Studio (par CreateShortcut) et que dans la fenêtre d'exécution je veux afficher le chemin de la cible, les caractères asiatiques sont remplacés par des points d'interrogation à l'affichage, dit autrement ils sont dans un jeu de caractères non pris en charge dans la fenêtre d'exécution de Visual Studio.

Code:

---

IWshShortcut link = (IWshShortcut)shell.CreateShortcut(strPathShortcut + ".lnk");

---

Alors que dans les cas où la création de raccourci génère une erreur, en revanche Visual Studio peut afficher les caractères en question.

Alors je veux bien faire une conversion, mais les méthodes que je connais pour faire ça nécessitent de connaître le jeu de caractères de départ et celui d'arrivée. D'où la question : comment m'y prendre pour savoir dans quel jeu de caractères est exprimé un nom de fichier ?

Pour avoir des points de repère j'ai affiché le contenu d'un nom caractère par caractère, j'obtiens
? fitarget.FullName[78]
12488 'ト'

Et là je me retrouve avec une autre question à poser. Comme vous le voyez, l'affichage de ce caractère occupe la largeur de deux caractères ASCII. Pourtant, fitarget.FullName[78].length vaut 1.

Pour connaître cette longueur occupée dans la mise en forme, afin de pouvoir aligner les colonnes, là aussi je pourrais utiliser la "méthode marteau-burin", et dans la chaîne résultat pour l'affichage du caractère chercher l'apostrophe avant et après, et calculer la différence.

J'imagine qu'il existe un moyen un peu plus ... "dans les clous" ?

---

Hello, es-tu aller lire ce thread ? https://stackoverflow.com/a/4397875/14104317
Il me semble qu'il peut être utile dans ton cas.

Ah oui, ça m'a l'air de traiter du sujet, merci.
Je tâche de revenir là-dessus assez vite.

Ah, oui ...
J'ai regardé très vite, l'autre jour. Il était bien question de noms de fichiers, dans un jeu de caractères exotiques.
Mais on parle de sauvegarder le nom d'une pièce jointe à un mail, en effectuant un choix cohérent entre CRLF et espace, alors que mon propos était de sauvegarder un raccourci Windows.
UrlEncode pour un nom de pièce jointe ça semblait une bonne idée, mais pour la cible d'un raccourci, moins, on dirait.
Et comme il y a trois champs qui représentent le nom de fichier, au fil de plusieurs transformations (dans le fichier cible, dans le raccourci ...), il y a intérêt à vraiment être à ce qu'on fait.

Pour cette histoire de longueur du nom du fichier, j'en reste à mettre un point de repère avant et après, et évaluer la longueur de ce qui les sépare.
Élégant pas forcément, mais ça devrait être efficace. Euh, pour être franc, je dis ça avant d'avoir vraiment essayé.