Je développe un application java sur macosx. Dans mon interface
graphique, j'ai des libellés de JButton qui contiennent des caractères
accentués. Quand j'exécute l'application sous Windows, mes caractères
accentués ne sont pas restitués correctement.
Existe-t-il des classes standards pour résoudre ce problème ou faut-il
tester l'"OS" et recoder les libellés ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrice Trognon
starfire wrote:
Bonjour
Je développe un application java sur macosx. Dans mon interface graphique, j'ai des libellés de JButton qui contiennent des caractères accentués. Quand j'exécute l'application sous Windows, mes caractères accentués ne sont pas restitués correctement. Existe-t-il des classes standards pour résoudre ce problème ou faut-il tester l'"OS" et recoder les libellés ?
Merci d'avance de vos réponses.
jlb
hi,
j'avais eu le problème et je l'avais solutionné par une option de compilation de javac, en -D quelque chose.
désolé je ne me souviens plus la solution précise, mais regarde sur google en cherchant dans les problèmes d'encodage des caractères c'est comme cela que j'etais tombé sur la "ruse".
--
Patrice Trognon http://www.javadevel.com
starfire wrote:
Bonjour
Je développe un application java sur macosx. Dans mon interface
graphique, j'ai des libellés de JButton qui contiennent des caractères
accentués. Quand j'exécute l'application sous Windows, mes caractères
accentués ne sont pas restitués correctement.
Existe-t-il des classes standards pour résoudre ce problème ou faut-il
tester l'"OS" et recoder les libellés ?
Merci d'avance de vos réponses.
jlb
hi,
j'avais eu le problème et je l'avais solutionné par une option
de compilation de javac, en -D quelque chose.
désolé je ne me souviens plus la solution précise, mais regarde
sur google en cherchant dans les problèmes d'encodage des caractères
c'est comme cela que j'etais tombé sur la "ruse".
Je développe un application java sur macosx. Dans mon interface graphique, j'ai des libellés de JButton qui contiennent des caractères accentués. Quand j'exécute l'application sous Windows, mes caractères accentués ne sont pas restitués correctement. Existe-t-il des classes standards pour résoudre ce problème ou faut-il tester l'"OS" et recoder les libellés ?
Merci d'avance de vos réponses.
jlb
hi,
j'avais eu le problème et je l'avais solutionné par une option de compilation de javac, en -D quelque chose.
désolé je ne me souviens plus la solution précise, mais regarde sur google en cherchant dans les problèmes d'encodage des caractères c'est comme cela que j'etais tombé sur la "ruse".
--
Patrice Trognon http://www.javadevel.com
Guillaume Desnoix
Je développe un application java sur macosx. Dans mon interface graphique, j'ai des libellés de JButton qui contiennent des caractères accentués. Quand j'exécute l'application sous Windows, mes caractères accentués ne sont pas restitués correctement.
La question essentielle est l'origine de ces libelles. S'ils sont codes dans le source, tu peux preciser le jeu de caracteres a la compilation ou bien convertir ton code source en ASCII avec la commande native2ascii (qui transforme les caracteres accentues comme e' en u00e9). S'ils proviennent d'une source externe, le plus simple est d'indiquer l'encoding dans le Reader.
Existe-t-il des classes standards pour résoudre ce problème ou faut-il tester l'"OS" et recoder les libellés ?
Il existe plusieurs classes pour gerer les jeux de caracteres mais la principale est java.io.Reader. Il n'y a normalement jamais besoin de tester l'OS. Tu disposes aussi de la propriete sesteme file.encoding.
Je développe un application java sur macosx. Dans mon interface
graphique, j'ai des libellés de JButton qui contiennent des caractères
accentués. Quand j'exécute l'application sous Windows, mes caractères
accentués ne sont pas restitués correctement.
La question essentielle est l'origine de ces libelles. S'ils sont codes
dans le source, tu peux preciser le jeu de caracteres a la compilation
ou bien convertir ton code source en ASCII avec la commande native2ascii
(qui transforme les caracteres accentues comme e' en u00e9). S'ils
proviennent d'une source externe, le plus simple est d'indiquer
l'encoding dans le Reader.
Existe-t-il des classes standards pour résoudre ce problème ou faut-il
tester l'"OS" et recoder les libellés ?
Il existe plusieurs classes pour gerer les jeux de caracteres mais la
principale est java.io.Reader. Il n'y a normalement jamais besoin de
tester l'OS. Tu disposes aussi de la propriete sesteme file.encoding.
Je développe un application java sur macosx. Dans mon interface graphique, j'ai des libellés de JButton qui contiennent des caractères accentués. Quand j'exécute l'application sous Windows, mes caractères accentués ne sont pas restitués correctement.
La question essentielle est l'origine de ces libelles. S'ils sont codes dans le source, tu peux preciser le jeu de caracteres a la compilation ou bien convertir ton code source en ASCII avec la commande native2ascii (qui transforme les caracteres accentues comme e' en u00e9). S'ils proviennent d'une source externe, le plus simple est d'indiquer l'encoding dans le Reader.
Existe-t-il des classes standards pour résoudre ce problème ou faut-il tester l'"OS" et recoder les libellés ?
Il existe plusieurs classes pour gerer les jeux de caracteres mais la principale est java.io.Reader. Il n'y a normalement jamais besoin de tester l'OS. Tu disposes aussi de la propriete sesteme file.encoding.
Guillaume Desnoix
Je développe un application java sur macosx. Dans mon interface graphique, j'ai des libellés de JButton qui contiennent des caractères accentués. Quand j'exécute l'application sous Windows, mes caractères accentués ne sont pas restitués correctement.
La question essentielle est l'origine de ces libelles. S'ils sont codes dans le source, tu peux preciser le jeu de caracteres a la compilation ou bien convertir ton code source en ASCII avec la commande native2ascii (qui transforme les caracteres accentues comme e' en u00e9). S'ils proviennent d'une source externe, le plus simple est d'indiquer l'encoding dans le Reader.
Existe-t-il des classes standards pour résoudre ce problème ou faut-il tester l'"OS" et recoder les libellés ?
Il existe plusieurs classes pour gerer les jeux de caracteres mais la principale est java.io.Reader. Il n'y a normalement jamais besoin de tester l'OS. Tu disposes aussi de la propriete sesteme file.encoding.
-- My desktop is worth a million of dollars. Put an icon on it. http://www.milliondollarscreenshot.com/
Je développe un application java sur macosx. Dans mon interface
graphique, j'ai des libellés de JButton qui contiennent des caractères
accentués. Quand j'exécute l'application sous Windows, mes caractères
accentués ne sont pas restitués correctement.
La question essentielle est l'origine de ces libelles. S'ils sont codes
dans le source, tu peux preciser le jeu de caracteres a la compilation
ou bien convertir ton code source en ASCII avec la commande native2ascii
(qui transforme les caracteres accentues comme e' en u00e9). S'ils
proviennent d'une source externe, le plus simple est d'indiquer
l'encoding dans le Reader.
Existe-t-il des classes standards pour résoudre ce problème ou faut-il
tester l'"OS" et recoder les libellés ?
Il existe plusieurs classes pour gerer les jeux de caracteres mais la
principale est java.io.Reader. Il n'y a normalement jamais besoin de
tester l'OS. Tu disposes aussi de la propriete sesteme file.encoding.
--
My desktop is worth a million of dollars. Put an icon on it.
http://www.milliondollarscreenshot.com/
Je développe un application java sur macosx. Dans mon interface graphique, j'ai des libellés de JButton qui contiennent des caractères accentués. Quand j'exécute l'application sous Windows, mes caractères accentués ne sont pas restitués correctement.
La question essentielle est l'origine de ces libelles. S'ils sont codes dans le source, tu peux preciser le jeu de caracteres a la compilation ou bien convertir ton code source en ASCII avec la commande native2ascii (qui transforme les caracteres accentues comme e' en u00e9). S'ils proviennent d'une source externe, le plus simple est d'indiquer l'encoding dans le Reader.
Existe-t-il des classes standards pour résoudre ce problème ou faut-il tester l'"OS" et recoder les libellés ?
Il existe plusieurs classes pour gerer les jeux de caracteres mais la principale est java.io.Reader. Il n'y a normalement jamais besoin de tester l'OS. Tu disposes aussi de la propriete sesteme file.encoding.
-- My desktop is worth a million of dollars. Put an icon on it. http://www.milliondollarscreenshot.com/
fabrice-pas-despame.bacchella
On Fri, 28 Oct 2005 20:25:12 +0200, Patrice Trognon wrote:
starfire wrote:
Bonjour
Je développe un application java sur macosx. Dans mon interface graphique, j'ai des libellés de JButton qui contiennent des caractères accentués. Quand j'exécute l'application sous Windows, mes caractères accentués ne sont pas restitués correctement. Existe-t-il des classes standards pour résoudre ce problème ou faut-il tester l'"OS" et recoder les libellés ?
Merci d'avance de vos réponses.
jlb
hi,
j'avais eu le problème et je l'avais solutionné par une option de compilation de javac, en -D quelque chose.
Une bonne solution pour RESOUDRE ce genre de problème, c'est de travailler entièrement en UTF-8.
On Fri, 28 Oct 2005 20:25:12 +0200, Patrice Trognon
<ptrognon@_SUPPRIMER_gmail.com> wrote:
starfire wrote:
Bonjour
Je développe un application java sur macosx. Dans mon interface
graphique, j'ai des libellés de JButton qui contiennent des caractères
accentués. Quand j'exécute l'application sous Windows, mes caractères
accentués ne sont pas restitués correctement.
Existe-t-il des classes standards pour résoudre ce problème ou faut-il
tester l'"OS" et recoder les libellés ?
Merci d'avance de vos réponses.
jlb
hi,
j'avais eu le problème et je l'avais solutionné par une option
de compilation de javac, en -D quelque chose.
Une bonne solution pour RESOUDRE ce genre de problème, c'est de
travailler entièrement en UTF-8.
On Fri, 28 Oct 2005 20:25:12 +0200, Patrice Trognon wrote:
starfire wrote:
Bonjour
Je développe un application java sur macosx. Dans mon interface graphique, j'ai des libellés de JButton qui contiennent des caractères accentués. Quand j'exécute l'application sous Windows, mes caractères accentués ne sont pas restitués correctement. Existe-t-il des classes standards pour résoudre ce problème ou faut-il tester l'"OS" et recoder les libellés ?
Merci d'avance de vos réponses.
jlb
hi,
j'avais eu le problème et je l'avais solutionné par une option de compilation de javac, en -D quelque chose.
Une bonne solution pour RESOUDRE ce genre de problème, c'est de travailler entièrement en UTF-8.
cfranco
wrote:
j'avais eu le problème et je l'avais solutionné par une option de compilation de javac, en -D quelque chose.
Une bonne solution pour RESOUDRE ce genre de problème, c'est de travailler entièrement en UTF-8.
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe, mais si on commence à travailler avec des gens qui ont des systèmes en langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne passaient pas correctement... (il pouvait les ouvrir, mais ça ne se compilait pas si par malheur il avait un caractère accentué dans une chaîne de caractère juste avant le " final, les deux caractères se "regroupant" en un seul du point de vue du compilateur... d'où une chaîne de caractères mal refermée)
j'avais eu le problème et je l'avais solutionné par une option
de compilation de javac, en -D quelque chose.
Une bonne solution pour RESOUDRE ce genre de problème, c'est de
travailler entièrement en UTF-8.
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe,
mais si on commence à travailler avec des gens qui ont des systèmes en
langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec
un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne
passaient pas correctement... (il pouvait les ouvrir, mais ça ne se
compilait pas si par malheur il avait un caractère accentué dans une
chaîne de caractère juste avant le " final, les deux caractères se
"regroupant" en un seul du point de vue du compilateur... d'où une
chaîne de caractères mal refermée)
j'avais eu le problème et je l'avais solutionné par une option de compilation de javac, en -D quelque chose.
Une bonne solution pour RESOUDRE ce genre de problème, c'est de travailler entièrement en UTF-8.
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe, mais si on commence à travailler avec des gens qui ont des systèmes en langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne passaient pas correctement... (il pouvait les ouvrir, mais ça ne se compilait pas si par malheur il avait un caractère accentué dans une chaîne de caractère juste avant le " final, les deux caractères se "regroupant" en un seul du point de vue du compilateur... d'où une chaîne de caractères mal refermée)
-- Christophe Franco
fabrice-pas-despame.bacchella
On Mon, 31 Oct 2005 12:19:25 +0200, (Christophe Franco) wrote:
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe, mais si on commence à travailler avec des gens qui ont des systèmes en langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne passaient pas correctement... (il pouvait les ouvrir, mais ça ne se compilait pas si par malheur il avait un caractère accentué dans une chaîne de caractère juste avant le " final, les deux caractères se "regroupant" en un seul du point de vue du compilateur... d'où une chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode est supposé justement résoudre ce genre de problème. Un seul codage pour tout le monde, japonais, indien, français ou truc (& les autres). Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16, BOM, pas BOM.
On Mon, 31 Oct 2005 12:19:25 +0200, cfranco@pobox.com (Christophe
Franco) wrote:
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe,
mais si on commence à travailler avec des gens qui ont des systèmes en
langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec
un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne
passaient pas correctement... (il pouvait les ouvrir, mais ça ne se
compilait pas si par malheur il avait un caractère accentué dans une
chaîne de caractère juste avant le " final, les deux caractères se
"regroupant" en un seul du point de vue du compilateur... d'où une
chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode
est supposé justement résoudre ce genre de problème. Un seul codage
pour tout le monde, japonais, indien, français ou truc (& les autres).
Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16,
BOM, pas BOM.
On Mon, 31 Oct 2005 12:19:25 +0200, (Christophe Franco) wrote:
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe, mais si on commence à travailler avec des gens qui ont des systèmes en langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne passaient pas correctement... (il pouvait les ouvrir, mais ça ne se compilait pas si par malheur il avait un caractère accentué dans une chaîne de caractère juste avant le " final, les deux caractères se "regroupant" en un seul du point de vue du compilateur... d'où une chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode est supposé justement résoudre ce genre de problème. Un seul codage pour tout le monde, japonais, indien, français ou truc (& les autres). Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16, BOM, pas BOM.
cfranco
wrote:
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe, mais si on commence à travailler avec des gens qui ont des systèmes en langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne passaient pas correctement... (il pouvait les ouvrir, mais ça ne se compilait pas si par malheur il avait un caractère accentué dans une chaîne de caractère juste avant le " final, les deux caractères se "regroupant" en un seul du point de vue du compilateur... d'où une chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode est supposé justement résoudre ce genre de problème. Un seul codage pour tout le monde, japonais, indien, français ou truc (& les autres). Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16, BOM, pas BOM.
On travaille sur Eclipse, et effectivement pour résoudre le "cas" de ces fichiers, on était obligés de les reprendre avec gvim pour corriger les caractères incorrects...
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe,
mais si on commence à travailler avec des gens qui ont des systèmes en
langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec
un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne
passaient pas correctement... (il pouvait les ouvrir, mais ça ne se
compilait pas si par malheur il avait un caractère accentué dans une
chaîne de caractère juste avant le " final, les deux caractères se
"regroupant" en un seul du point de vue du compilateur... d'où une
chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode
est supposé justement résoudre ce genre de problème. Un seul codage
pour tout le monde, japonais, indien, français ou truc (& les autres).
Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16,
BOM, pas BOM.
On travaille sur Eclipse, et effectivement pour résoudre le "cas" de ces
fichiers, on était obligés de les reprendre avec gvim pour corriger les
caractères incorrects...
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe, mais si on commence à travailler avec des gens qui ont des systèmes en langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne passaient pas correctement... (il pouvait les ouvrir, mais ça ne se compilait pas si par malheur il avait un caractère accentué dans une chaîne de caractère juste avant le " final, les deux caractères se "regroupant" en un seul du point de vue du compilateur... d'où une chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode est supposé justement résoudre ce genre de problème. Un seul codage pour tout le monde, japonais, indien, français ou truc (& les autres). Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16, BOM, pas BOM.
On travaille sur Eclipse, et effectivement pour résoudre le "cas" de ces fichiers, on était obligés de les reprendre avec gvim pour corriger les caractères incorrects...
-- Christophe Franco
Guillaume
wrote:
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe, mais si on commence à travailler avec des gens qui ont des systèmes en langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne passaient pas correctement... (il pouvait les ouvrir, mais ça ne se compilait pas si par malheur il avait un caractère accentué dans une chaîne de caractère juste avant le " final, les deux caractères se "regroupant" en un seul du point de vue du compilateur... d'où une chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode est supposé justement résoudre ce genre de problème. Un seul codage pour tout le monde, japonais, indien, français ou truc (& les autres). Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16, BOM, pas BOM.
On travaille sur Eclipse, et effectivement pour résoudre le "cas" de ces fichiers, on était obligés de les reprendre avec gvim pour corriger les caractères incorrects...
Le compilo est par defaut en ISO-8859-1. On peut lui indiquer de prendre
autre chose en entree. Mais le mieux reste qd meme de n'avoir que de l'ASCII dans le code source.
-- My desktop is worth a million of dollars. Put an icon on it. http://www.milliondollarscreenshot.com/
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe,
mais si on commence à travailler avec des gens qui ont des systèmes en
langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec
un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne
passaient pas correctement... (il pouvait les ouvrir, mais ça ne se
compilait pas si par malheur il avait un caractère accentué dans une
chaîne de caractère juste avant le " final, les deux caractères se
"regroupant" en un seul du point de vue du compilateur... d'où une
chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode
est supposé justement résoudre ce genre de problème. Un seul codage
pour tout le monde, japonais, indien, français ou truc (& les autres).
Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16,
BOM, pas BOM.
On travaille sur Eclipse, et effectivement pour résoudre le "cas" de ces
fichiers, on était obligés de les reprendre avec gvim pour corriger les
caractères incorrects...
Le compilo est par defaut en ISO-8859-1. On peut lui indiquer de prendre
autre chose en entree. Mais le mieux reste qd meme de n'avoir que de
l'ASCII dans le code source.
--
My desktop is worth a million of dollars. Put an icon on it.
http://www.milliondollarscreenshot.com/
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe, mais si on commence à travailler avec des gens qui ont des systèmes en langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne passaient pas correctement... (il pouvait les ouvrir, mais ça ne se compilait pas si par malheur il avait un caractère accentué dans une chaîne de caractère juste avant le " final, les deux caractères se "regroupant" en un seul du point de vue du compilateur... d'où une chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode est supposé justement résoudre ce genre de problème. Un seul codage pour tout le monde, japonais, indien, français ou truc (& les autres). Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16, BOM, pas BOM.
On travaille sur Eclipse, et effectivement pour résoudre le "cas" de ces fichiers, on était obligés de les reprendre avec gvim pour corriger les caractères incorrects...
Le compilo est par defaut en ISO-8859-1. On peut lui indiquer de prendre
autre chose en entree. Mais le mieux reste qd meme de n'avoir que de l'ASCII dans le code source.
-- My desktop is worth a million of dollars. Put an icon on it. http://www.milliondollarscreenshot.com/
Syrion
wrote:
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe, mais si on commence à travailler avec des gens qui ont des systèmes en langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne passaient pas correctement... (il pouvait les ouvrir, mais ça ne se compilait pas si par malheur il avait un caractère accentué dans une chaîne de caractère juste avant le " final, les deux caractères se "regroupant" en un seul du point de vue du compilateur... d'où une chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode est supposé justement résoudre ce genre de problème. Un seul codage pour tout le monde, japonais, indien, français ou truc (& les autres). Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16, BOM, pas BOM.
On travaille sur Eclipse, et effectivement pour résoudre le "cas" de ces fichiers, on était obligés de les reprendre avec gvim pour corriger les caractères incorrects...
Le compilo est par defaut en ISO-8859-1. On peut lui indiquer de prendre
autre chose en entree. Mais le mieux reste qd meme de n'avoir que de l'ASCII dans le code source.
Moi je vote pour la solution où tu précise le charset à la compilation si elle permet de générer des .class avec des chaînes portables. Sinon c'est en UTF-16BE qu'il faut bosser, c'est l'encodig Java par excellence. Windows utilise tantôt Cp1147 (cas général) tantôt UTF-16LE (exemple : logs windows) d'où l'idée de compiler correctement ou de mettre les caractères en u.... JE suis fondamentalement contre travailler en ASCII uniquement, je suis assez énervé que sous prétexte que les standards historiquement anglo-saxon on se trimballe des complexification dès qu'on sort du charset réduit compréhensible par le mangeur de burger moyen, ou dès qu'on veut classer par ordre alphabétique en plaçant le é après le e et non après le z. Heureusement, Java suit unicode.org utilise Locales et Collators.... mais on reste prisonnier de l'éditeur de code source qu'on utilise.
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe,
mais si on commence à travailler avec des gens qui ont des systèmes en
langues asiatiques, cela peut poser des problèmes... J'ai eu le cas
avec
un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne
passaient pas correctement... (il pouvait les ouvrir, mais ça ne se
compilait pas si par malheur il avait un caractère accentué dans une
chaîne de caractère juste avant le " final, les deux caractères se
"regroupant" en un seul du point de vue du compilateur... d'où une
chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode
est supposé justement résoudre ce genre de problème. Un seul codage
pour tout le monde, japonais, indien, français ou truc (& les autres).
Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16,
BOM, pas BOM.
On travaille sur Eclipse, et effectivement pour résoudre le "cas" de ces
fichiers, on était obligés de les reprendre avec gvim pour corriger les
caractères incorrects...
Le compilo est par defaut en ISO-8859-1. On peut lui indiquer de prendre
autre chose en entree. Mais le mieux reste qd meme de n'avoir que de
l'ASCII dans le code source.
Moi je vote pour la solution où tu précise le charset à la compilation
si elle permet de générer des .class avec des chaînes portables.
Sinon c'est en UTF-16BE qu'il faut bosser, c'est l'encodig Java par
excellence. Windows utilise tantôt Cp1147 (cas général) tantôt UTF-16LE
(exemple : logs windows) d'où l'idée de compiler correctement ou de
mettre les caractères en u....
JE suis fondamentalement contre travailler en ASCII uniquement, je suis
assez énervé que sous prétexte que les standards historiquement
anglo-saxon on se trimballe des complexification dès qu'on sort du
charset réduit compréhensible par le mangeur de burger moyen, ou dès
qu'on veut classer par ordre alphabétique en plaçant le é après le e et
non après le z. Heureusement, Java suit unicode.org utilise Locales et
Collators.... mais on reste prisonnier de l'éditeur de code source qu'on
utilise.
Je nuancerais un petit peu, cela fonctionne tant qu'on reste en Europe, mais si on commence à travailler avec des gens qui ont des systèmes en langues asiatiques, cela peut poser des problèmes... J'ai eu le cas avec un sous-traitant en Chine chez qui les fichiers de sources en UTF-8 ne passaient pas correctement... (il pouvait les ouvrir, mais ça ne se compilait pas si par malheur il avait un caractère accentué dans une chaîne de caractère juste avant le " final, les deux caractères se "regroupant" en un seul du point de vue du compilateur... d'où une chaîne de caractères mal refermée)
C'est pas lié plutôt à un problème d'environnement ? Parce que Unicode est supposé justement résoudre ce genre de problème. Un seul codage pour tout le monde, japonais, indien, français ou truc (& les autres). Mais après faut effectivement pas se tromper entre UTF-8 & UTF-16, BOM, pas BOM.
On travaille sur Eclipse, et effectivement pour résoudre le "cas" de ces fichiers, on était obligés de les reprendre avec gvim pour corriger les caractères incorrects...
Le compilo est par defaut en ISO-8859-1. On peut lui indiquer de prendre
autre chose en entree. Mais le mieux reste qd meme de n'avoir que de l'ASCII dans le code source.
Moi je vote pour la solution où tu précise le charset à la compilation si elle permet de générer des .class avec des chaînes portables. Sinon c'est en UTF-16BE qu'il faut bosser, c'est l'encodig Java par excellence. Windows utilise tantôt Cp1147 (cas général) tantôt UTF-16LE (exemple : logs windows) d'où l'idée de compiler correctement ou de mettre les caractères en u.... JE suis fondamentalement contre travailler en ASCII uniquement, je suis assez énervé que sous prétexte que les standards historiquement anglo-saxon on se trimballe des complexification dès qu'on sort du charset réduit compréhensible par le mangeur de burger moyen, ou dès qu'on veut classer par ordre alphabétique en plaçant le é après le e et non après le z. Heureusement, Java suit unicode.org utilise Locales et Collators.... mais on reste prisonnier de l'éditeur de code source qu'on utilise.
Guillaume
Le compilo est par defaut en ISO-8859-1. On peut lui indiquer de prendre autre chose en entree. Mais le mieux reste qd meme de n'avoir que de l'ASCII dans le code source.
Syrion:
JE suis fondamentalement contre travailler en ASCII uniquement, je suis assez énervé [...]
Quand j'ecris de n'avoir que de l'ASCII, ca signifie justement l'utilisation des sequences u####. En gros, on passe le code source a la moulinette native2ascii afin que les autres n'aient pas de probleme pour le compiler.
[...] compréhensible par le mangeur de burger moyen
Ils sont toujours geants les hamburgers, la-bas ;)
Heureusement, Java suit unicode.org utilise Locales et Collators
Et c'est une tres bonne chose.
mais on reste prisonnier de l'éditeur de code source qu'on utilise.
emacs?
-- My desktop is worth a million of dollars. Put an icon on it. http://www.milliondollarscreenshot.com/
Le compilo est par defaut en ISO-8859-1. On peut lui indiquer de
prendre autre chose en entree. Mais le mieux reste qd meme de n'avoir
que de l'ASCII dans le code source.
Syrion:
JE suis fondamentalement contre travailler en ASCII uniquement, je suis
assez énervé [...]
Quand j'ecris de n'avoir que de l'ASCII, ca signifie justement
l'utilisation des sequences u####. En gros, on passe le code source a
la moulinette native2ascii afin que les autres n'aient pas de probleme
pour le compiler.
[...] compréhensible par le mangeur de burger moyen
Ils sont toujours geants les hamburgers, la-bas ;)
Heureusement, Java suit unicode.org utilise Locales et Collators
Et c'est une tres bonne chose.
mais on reste prisonnier de l'éditeur de code source qu'on utilise.
emacs?
--
My desktop is worth a million of dollars. Put an icon on it.
http://www.milliondollarscreenshot.com/
Le compilo est par defaut en ISO-8859-1. On peut lui indiquer de prendre autre chose en entree. Mais le mieux reste qd meme de n'avoir que de l'ASCII dans le code source.
Syrion:
JE suis fondamentalement contre travailler en ASCII uniquement, je suis assez énervé [...]
Quand j'ecris de n'avoir que de l'ASCII, ca signifie justement l'utilisation des sequences u####. En gros, on passe le code source a la moulinette native2ascii afin que les autres n'aient pas de probleme pour le compiler.
[...] compréhensible par le mangeur de burger moyen
Ils sont toujours geants les hamburgers, la-bas ;)
Heureusement, Java suit unicode.org utilise Locales et Collators
Et c'est une tres bonne chose.
mais on reste prisonnier de l'éditeur de code source qu'on utilise.
emacs?
-- My desktop is worth a million of dollars. Put an icon on it. http://www.milliondollarscreenshot.com/
