site java en japonais

[phiphi]

bonjour,
quelqu'un aurait-il des infos concernant les contraintes linguistiques lors de l'implémentation de ce genre de site, aussi bien au niveau de la base de données, des jsp, du Java, du HTML. Enfin, bref toute information qui serait utile.
Merci

[icebreak]

Déja un sujet pour la partie Technologie.

Ensuite, moi perso je code "en japonais" en PHP dans le cadre de mon boulot. Devant faire des progs billingues, mes pages sont en UTF-8 sans BOOM (pour les sessions).

Ma base est toujours MySQL.
Avant elle était en LATIN 1 mais avec la page de caractères UTF-8
Depuis la dernière version de MySQL, en local, j'ai aussi la collation de caractères. J'ai fait plusieurs tests et ça merdé a l'affichage sous Phpmyadmin mais ça rendait bien.

Pour pallier le problème de l'affichage car je veux aussi voir mes données en japonais dans ma base et faire des recherches dessus, j'ai opter pour une collation UTF-8 mais mes données Française et japonaise sont en binaires. Donc champs différents et pour les longs texte c'est du BLOB.

Bien sur, si tu ne codes qu'en japonais, Alléluia, ça sera facilité par du Shitf-js tout bête, utilisé par toutes les pages Web nippone pratiquement.
Sauf au niveau du mail ou c'est de l'ISO. ISO-****-JP (A toi de remplacer les étoiles par les vrai chiffres, je les ai pas de tête.).

Donc pour le java, je pense que c'est ton type de fichier surtout auquel tu dois faire attention. J'opte toujours pour l'UTF-8 de toutes les façons.

Donc

[phiphi]

merci pour ces informations précieuses.
connais-tu un site qui traite du sujet ?

[icebreak]

Très peu, mais quand tu parles de codage avec le japonais, y a en général le Blog d'Erwan et aussi celui de Glandium.
http://glandium.org/

http://loisant.org/
http://glandium.org/

J'ai gardé un fichier de Glandium sur mon ordi. Donc c'Est copyright Glandium. Si il veut je l'enleverai de ce post.

******************************************
Unicode est souvent présenté comme le saint Graal des problèmes de codages de caractères et la solution ultime aux problèmes de m17n (Multilingualization). Mais tel n'est pas mon avis. J'ai souvent pesté à droite à gauche à ce propos, il est temps de synthétiser le tout, et d'y ajouter mes dernières (mauvaises) expériences.

Unicode ? Késako ?
Tout d'abord, rappelons ce qu'est Unicode et pourquoi ce code "unifié" a été créé. Comme le rappelle brièvement Erwan, l'informatique nous venant des États-Unis, le tout premier des codages de caractères standardisé, ASCII (American Standard Code for Information Interchange), codé sur 7 bits et offrant par conséquent 127 caractères, ne comprend que l'alphabet latin de base, et donc pas, pour nous français, les signes diacritiques, ni les autres caractères "spéciaux" des langues à alphabet plus ou moins latin, et encore moins les idéogrammes, pictogrammes, et autre caractères utilisés dans les langues comme l'hébreu, le chinois, le mongol, le russe, etc.

Une des premières extensions à l'ASCII (et je parle d'extension, pas de modification sauvage et incompatible sur 7 bits comme il y en a aussi eu) a donc été l'alphabet latin n°1, certainement mieux connu sous son code ISO : 8859-1. Il permet donc de supporter une grande partie des langues européennes plus quelques autres : Allemand, Anglais, Basque, Catalan, Danois, Écossais, Espagnol, Féroïen, Finnois, Français, Galicien, Irlandais, Islandais, Italien, Néerlandais, Norvégien, Portugais, Sud-Africain et Suédois. Évidemment, même si en comparaison de l'ASCII, un grand nombre de langues peuvent être écrites dans ce codage, les langues à caractères non-latins sont toujours condamnées à ne pas pouvoir être codées. D'autres codages ISO 8859 ont progressivement comblé les trous pour des caractères comme les caractères Arabes, Hébreux, Turcs, Grecs, etc. et d'autres codages comme le Big5, le HZ, l'EUC-JP, le Shift-JIS, l'EUC-KR, le TIS-620, etc. sont apparus pour les caractères Chinois, Japonais, Coréens, etc.

Et encore, je ne mentionne pas tous les codages spécifiques à DOS/Windows, aux Macintosh, ou autres, puisque chacun a apporté sa propre solution au même problème : comment diable coder les caractères de la langue ciblée par mon produit ? ni même les sortes de "méta-codages" comme l'ISO-2022. Il suffit d'ouvrir le menu View > Character Coding de Mozilla Firefox pour se faire une frayeur (et il ne supporte pas tout), ou encore de taper la ligne de commande iconv -l.

Notons qu'à quelques exceptions (on citera notamment le caractère \, qui est devenu ¥ dans les codages japonais), ils sont pour la plupart compatibles avec l'ASCII.

Devant autant de codages différents, sachant qu'un bon nombre fait double emploi (il n'y a qu'à voir le nombre de codages pour le Chinois ou le Turc), certains se sont dit qu'il fallait résoudre le problème et unifier le codage. Ainsi naquit Unicode.

Unicode, UCS-2,4 , UTF-7,8,16,32, Au secouuuuuurs !
Beaucoup de termes/acronymes sont utilisés autour d'Unicode, éclaircissons un peu le tableau :

Unicode est le terme générique pour désigner le standard ISO 10646 (en vérité ce sont 2 choses différentes, mais les 2 étant synchronisés, l'amalgamme est autorisé).
UCS est l'acronyme pour Universal Character Set. C'est ce qui est définit par le standard Unicode.
UCS-2, UCS-4 désignent 2 ensembles (l'un englobant l'autre) pour coder tous les caractères de toutes les langues humaines qui ont été, qui sont et qui seront écrites, sur, respectivement, 16 bits (2 octets) et 32 bits (4 octets). Note : même si UCS-4 est codé sur 32 bits, en fait seulement 31 sont utilisés. L'ensemble Unicode représente donc 2^31 caractères.
UTF est l'acronyme pour Unicode Transformation Format.
UTF-7, UTF-8, UTF-16 et UTF-32 désignent différentes façons de coder de manière plus "pratique" l'ensemble Unicode, sur respectivement 7, 8, 16 et 32 bits. Il est à noter que "codé sur n bits" dans ce cas ne signifie pas que l'ensemble des caractères est codé sur n bits (ce qui ne ferait que 255 caractères possibles dans le cas où n = , mais par "blocs" de n bits. UTF-8 code ainsi l'ensemble des codes représentables en UCS-4 avec des longueurs variables de 1 à 6 octets suivant les caractères. C'est pourquoi il est le plus populaire et répandu : les caractères du codage ASCII sont représentés tels quels en UTF-8.
Pour des informations plus précises, reportez-vous à la FAQ sur UTF.

Toutes les langues passées, présentes et à venir...
C'est ce qu'Unicode propose. Même si aujourd'hui des caractères comme les hiéroglyphes n'ont pas encore trouvé leur place dans Unicode, la place ne manque pas et en réalité, Unicode est prévu pour s'étendre à de tels ensembles de caractères, si le besoin s'en fait ressentir (Il y a même un sous-ensemble aujourd'hui réservé pour le Klingon, c'est dire... et ils n'excluent pas d'inclure Tengwar ou d'autres scripts fantaisistes)

La place ne manque pas... 2^31 caractères. Autrement dit plus de 2 milliards de caractères.

...et pourtant...
Et pourtant, dans un but d'"unification", les caractères Chinois, Japonais et Coréens ont été regroupés, mélangés, dans un seul et même sous-ensemble (Unihan). Pourquoi ? Faisons un peu d'histoire.

Au début était le verbe. Non, rien à voir. En fait si, un peu. Pour simplifier, le japonais et le coréen ont été des langues parlées avant d'être écrites, et comme les chinois avaient déjà un système d'écriture plutôt pas mal (disons que c'était le plus proche géographiquement), les japonais et les coréens ont importé les caractères chinois. Ainsi sont nés kanjis et hanjas, versions respectivement japonaise et coréenne des caractères chinois. Mais si au début les caractères étaient les mêmes, au fil du temps, chaque langue a vu l'écriture évoluer dans des différentes directions, si bien qu'aujourd'hui il existe de nombreuses différences entre tous ces caractères.

Mais si tous les caractères ne sont pas différents, pourquoi ne pas simplifier et regrouper tout ça ? vous demandez-vous peut-être. C'est plutôt une bonne idée, en fait, et c'est ce qu'ont fait les gens qui ont pensé Unicode. Le problème, c'est qu'ils ont considéré des caractères comme étant identitiques alors qu'ils ne le sont pas. Il faut quand même dire qu'un bon nombre de caractères différents ont effectivement obtenus des codes différents, mais d'après l'étude d'un japonais qui a comparé les caractères de plusieurs polices de caractères chinois, coréens et les définitions Unicode, il s'avère qu'un bon nombre de caractères ont été oubliés dans cette chasse aux caractères différents. Entre les caractères qui sont carrément différents entre le chinois, le coréen et le japonais, et ceux qui se ressemblent suffisamment pour que ça passe, mais qui ne sont pas exactement corrects, on est loin d'un monde parfait.

Polices de caractères
Aujourd'hui, des polices de caractères existent pour bon nombre d'ensemble de caractères (y compris les Tengwars) et il devient de plus en plus aisé d'afficher des textes multilingues, grâce notamment à l'Unicode, il faut le dire. La preuve en est le présent site web, qui mélange japonais, coréen, et français (et un peu d'anglais, des fois). Le mélange est d'autant plus facile qu'un codage unique est utilisé. Il serait techniquement possible d'utiliser des codages différents, mais il faut avouer que ce serait un travail laborieux.

Mais il y a un inconvénient. Aujourd'hui, aucune police de caractère n'implémente la totalité des glyphes de l'Unicode, et peu en implémentent un sous-ensemble assez vaste (pour la simple raison qu'une police, en général, est faite avec une "cible linguistique"), si bien qu'un système d'affichage se doit de composer les polices pour arriver à afficher un texte multilingue. Pour visionner le site ici présent, pour peu que la page contienne à la fois japonais, français et coréen (comme dans ce message, par exemple), votre système a certainement utilisé 2 ou 3 polices différentes. Dans un cas comme celui-ci, où le format de données (XHTML) contient des méta-données importantes pour ce processus de rendu (attribut xml:lang pour indiquer la langue du contenu), c'est assez facile, il suffit de prendre la police qui correspond à la langue. Vous aurez sans-doute remarqué dans Mozilla que vous pouvez définir différentes polices pour différentes langues (Image 1), il est recommandé de configurer tout ça finement, afin d'utiliser les polices adéquates en fonction de la langue. Il est cependant à noter qu'à cause de ce bug de Mozilla, ce processus simple ne s'applique pas ici.


Image 1 - Boîte de dialogue "Fonts & Colors" de Mozilla Firefox
À la place d'utiliser plusieurs polices différentes de manière "consciente", il va demander à tout afficher avec une certaine police donnée, celle définie pour la langue globale du document (qu'il arrive à déterminer correctement). C'est aussi ce qu'il va se passer si, contrairement à ce site, aucune information "locale" de langue n'est fournie. C'est aussi ce qu'il se passe dans la plupart des cas quand une application demande l'affichage d'un texte. Elle va demander l'affichage de ce texte dans la police définie pour l'affichage.

Sous X Window (je ne connais pas le fonctionnement des autres systèmes d'affichage pour le cas présent, mais j'imagine que le processus doit être assez similaire), dans un tel cas, le système va utiliser la police demandée, et au cas où la glyphe demandée n'existe pas dans cette police, une liste de polices de remplacement est utilisée pour trouver une police qui elle, contiendrait le caractère voulu. Par une telle composition, on peut avoir une police "virtuelle" qui définit un large sous-ensemble d'Unicode.

Mais c'est là que se trouve le principal problème. Une police de caractère à un style, une façon d'écrire les caractères, si on veut. Et d'une police à une autre, ce style change. Quand il s'agit d'une police occidentale et d'une police japonaise, la différence entre les caractères est telle qu'on n'y prend pas garde, mais, pour prendre un cas simple mais ennuyeux, un bon nombre de polices occidentales définissent les glyphes pour les hiraganas et les katakanas japonais, mais pas pour les kanjis. Dans le cas où le processus de "fallback" est utilisé et où la police occidentale a été la première utilisée, on se retrouve avec des hiraganas qui ne sont pas forcément en accord visuel avec les kanjis qui les accompagnent. Parfois même le processus de "fallback" n'est pas implémenté, et on se retrouve juste avec le carré "glyphe non-définie". C'est ce qui m'arrive dans bon nombre d'applications qui utilisent la police "Bitstream Vera Sans" sans "fallback", et m'affichent un carré à la place du caractère ー comme dans コーヒー (par exemple dans OpenOffice.org pour ne citer que lui).

L'exemple inverse est aussi observable, si on définit une police japonaise pour afficher un texte français. Bien souvent, ces polices ne contiennent pas les glyphes pour les caractères à signes diacritiques des langues à alphabet latin, et le résultat quand on demande à un programme tel que Gimp d'afficher le mot "œdème" dans la police "Kochi Mincho" (Image 2) n'est pas celui qu'on espère, du fait que la police utilisée pour les caractères 'œ' et 'è' n'est pas stylisée de la même manière que "Kochi Mincho", du fait du "fallback".


Image 2 - Le mot "œdème" écrit avec la police "Kochi Mincho"
Évidemment, on peut s'arranger pour utiliser un ensemble de polices convenables dans la liste de "fallback" pour que ce genre d'incohérence graphique n'arrive pas, en configurant finement fontconfig, par exemple, mais d'une part, ça demande un effort supplémentaire, et d'autre part, ça soulève un autre problème :

Récemment, je me suis mis au Coréen, en conséquence de quoi j'ai installé des polices pour afficher du texte coréen, puisque mon système en était jusqu'alors dépourvu. Jusq'ici, j'étais habitué à mes conflits franco-japonais d'affichage et aux carrés de "glyphe non-définie", mais l'installation de ces polices m'a ajouté un nouveau problème : un conflit japono-coréen.

Comme expliqué plus haut, les coréens et les japonais ont ceci en commun dans leur histoire qu'ils ont repris les caractères chinois pour écrire leur propre langue qui jusque là n'avait pas de système d'écriture. Ensuite les évolutions locales des langues ont changé les caractères, et l'histoire coréenne a même vu l'utilisation des caractères chinois avoisiner le vide absolu. Aujourd'hui, les Coréens n'utilisent que très peu les hanjas, mais suffisamment pour que les polices de caractères coréennes contiennent toujours de quoi afficher les textes plus vieux que l'"abandon" des hanjas dans la pratique courante. Mais voilà, les coréens et les japonais ont beau avoir importé les mêmes caractères, ils n'ont pas forcément importé les mêmes. On pourrait résumer la situation en disant que les kanjis et les hanjas sont des sous-ensembles des caractères chinois, qui ont une grande base en commun, mais qui n'ont pas la même portée : les hanjas comprennent des caractères chinois qui ne figurent pas dans les kanjis et vice-versa.

Comme les polices ont leur cible, et qu'il n'est franchement pas dans l'intérêt de "perdre du temps" à styliser des caractères qui ne seront pas utilisés dans la police, les polices coréennes ne définissent donc pas l'ensemble complet Unihan. Par conséquent, demander d'afficher un texte japonais avec une police coréenne aboutit à une abhérrance graphique (Image 3), alors que le même texte rendu par une police japonaise est graphiquement cohérent (Image 4).


Image 3 - Le bout de phrase 「当店の雰囲気」 écrit avec la police "Ungungseo"

Image 4 - Le bout de phrase 「当店の雰囲気」 écrit avec la police "Kochi Mincho"
Or donc, après avoir installé les polices coréennes, celles-ci se sont retrouvé sur le chemin du processus de fallback, générant ainsi de nouveaux problèmes d'affichage, voire de nouveaux problèmes de carrés de "glyphe non-définie". Évidemment, je pourrais certainement m'arranger pour faire s'afficher le japonais correctement, en rechangeant ma configuration de fallback, mais ce serait alors au détriment du Coréen. Bon, d'accord, il y a peu de chance que j'affiche du Coréen comprenant des hanjas... Mais qu'adviendra-t-il le jour où je me mettrai au chinois ? À nouveau le même problème... et cette fois, il faudra que je fasse la balance entre afficher parfaitement un texte dans un système d'écriture au détriment des autres, étant donné qu'il est impossible que les 3 soient correctement affichés au même moment par cet algorithme. Je passerai sur les problèmes de cohérence graphique entre les hanjas et l'hangul (type de tracé des traits, etc.) et les problèmes des caractères différents entre le Coréen, le Chinois et le Japonais, mais j'imagine que vous voyez bien le fond du problème.

La seule solution à l'heure actuelle serait d'avoir une police qui comprend tous les caractères de tous les systèmes d'écritures, donc en fait une police qui implémente tous les caractères Unicode. Ou plutôt plusieurs, parce qu'on n'est jamais satisfait des polices qu'on utilise et qu'on aime bien ne pas avoir une environnement monotone. (titres dans telle police, texte dans telle autre, etc.)

En voulant résoudre le problème du codage, les gens d'Unicode semblent avoir oublié le fond du problème m17n, et par conséquent, un fichier texte plat en UTF-8 ne saurait être satisfaisant pour savoir quelle police utiliser ou plutôt dans quelle langue est écrit le texte ; on doit avoir recourt à des méta-données, telles que le xml:lang qui figure dans le xhtml (modulo les bugs de navigateurs).

Bref, Unicode n'est pas la solution en soi. Ça aide pas mal, ça simplifie un peu le problème, mais le fond du problème est toujours là, et quitte à devoir utiliser des méta-données pour séparer les informations linguistiques, avoir un système de codage unique n'est pas si primordial, l'information primordiale étant la méta-donnée. Le codage changerait à chaque section de langue différente, ce ne serait pas pire que ce que c'est actuellement avec l'Unicode. Il suffit de voir comment les navigateurs web, clients mail savaient afficher divers textes de diverses langues bien avant de basculer à l'Unicode...

Mon avis à moi et je le partage, c'est que le plus important était plutôt de définir un méta-codage (à la ISO-2022, mais en plus global), plutôt que d'uniformiser le tout en oubliant la moitié du problème. Rappelez-vous comme il est simple de choisir la police d'affichage quand on a la méta-information par rapport à quand on a un simple texte Unicode.

[erwan]

Maintenant que tout le monde sait ce qu'est l'unicode, pour en revenir a Java c'est tout unicode et depuis longtemps.

Conclusion : aucun probleme pour le japonais et Java, a condition que les polices de caractere japonaises soient bien installees (ce qui n'est pas forcement toujours evident).

[icebreak]

C'est vrai que c'était pas totalement cohérent, mais l'Unicode m'a sauvé la vie pour le PHP.
Pour les polices, MS gothics et Mincho, mais elles sont partout non ?

Tiens tu connais Jbrowse, Erwan ?
J'ai téléchargé Moji, mais j'avoue que les fonctions de Jbrowse sur Moji serait génial comme :

1 - Ajout de Furigana (<ruby>)
2 - Pas besoin de valider pour avoir la signification d'un mot. Suffirais juste de souligner ou de passer dessus.

Sinon c'est génial.

[tchotto]

Salut à tous et à toutes !

Bon aperçu de ce que permet l'informatique ! on ne retiendra pas tout ! Mais ....
Icebreak, merci pour ce " cours " qui nous donne une idée de ce qui sert de trame derrière tout ce que l'on emploie en informatique sans le savoir

Et qui permet de passer de l'écriture d'une langue à l'autre à l'aise et tout naturellement , comme si de rien n'était !
Les coulisses de l'écriture informatique ! Fascinant ! Quel travail là-derrière ...pour rendre tout cela compatible , complémentaire et harmonieux finalement !
On en ressent les " tenants " et les " aboutissants " !
Bon travail et succès pour le bien de nous tous !

[icebreak]

Le cours il est de Glandium.
Il m'a énormément aidé sinon j'aurais surement fait du S-jis et de l'ISO pour els pages français, mais pour la base j'étais bien embêté.

[sozaburokano]

Salut,
Dsl de revenir sur le sujet...mais j'ai rien compris au discours.

Je cherche à dev. un site dont l'affichage de certaines données seront en japonais .
J'use de PSPad, mais quand j'écris en jap des "????" s'affichent.
-> j'use du bloc note tout bete (pas encore essayé homesite)

je mets en en tete
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">

en charset j'ai essayé UFT-8 et EUC-JP.. rien à faire, rien ne s'affiche dans mon navigateur... !

De plus, je vais user d'une BD mysql où les infos seront enregistrées en jap après avoir été saisies via formulaire en jap..


Je me demande ce que ce sera quand je vais tenter le XML.

[sozaburokano]

slt,

ben là j'ai commencé à développer..

- Je ne peux pas écrire en japonais dans mes éditeurs.
- Par contre, le japonais est ok quand je ne passe par formulaire sur mon site en developpement.
- Ces kanji sont enregistrés en code ascii dans MySql.
- Aucun pb pour l'affichage. PAr contre, mes moteurs de recherche ne marchent pas.. ils ne retrouvent pas le kanji dans la base. J'ai remarqué qu'il le codait ainsi %E7%9F%B3 ???


Suite à ce problème, vais mettre les meta aujourdui.
------------------------------------------------------

OKay ! ca marche ! tu as raison..
Les kanji sont codés ainsi ds la base : 夜
j'avais un gros problème avec les accents.

Mais c bon..
------------------------------------------------------
Je retire ce que j'ai dit !!
rien ne marche ! il affiche ce qu'il peut