(Copyright : J.W. Breen - 1998)
Ceci est une conversion rapide et sans mise en forme du fichier xjdic23.inf en HTML.
SOMMAIRE
XJDIC est un dictionnaire électronique japonais-anglais conçu pour fonctionner dans un environnement de fenêtrage X11. En particulier, il peut être lancé dans l'environnement Xterm qui fournit un support pour la langue japonaise, comme on peut le trouver dans Kterm, Xterm internationalisé, Aixterm, etc.
Il est basé sur JDIC et JREADER qui ont été développés pour fonctionner sous MS-DOS, sur PC IBM et clones.
Les fonctionnalités de XJDIC sont :
Depuis la V2.0, XJDIC est disponible sous deux formes : un programme autonome et un couple de programmes client/serveur. Dans ce dernier cas, XJDIC devient un client envoyant des requêtes à un programme tiers, XJDSERVER, qui peut être sur le même système ou sur une autre machine hôte. Un seul programme XJDSERVER peut être utilisé par de nombreux programmes XJDIC. Voir le fichier xjdic23.install pour plus de détails.
Le code source et la documentation de XJDIC sont diffusés ici sous les termes de la licence publique générale GNU (GPL). Tous les usages de ce logiciel sont aux risques de l'utilisateur et il n'y a aucune garantie quant à ses performances. Des copies de ce logiciel peuvent être distribuées par tout moyen conforme aux termes de la licence GPL.
Les fichiers EDICT et KANJIDIC sont aussi disponibles gratuitement, mais sont couverts par les conditions de leurs propres copyright et licence, et ne sont pas sous licence GPL.
Tous les affichages en japonais dans XJDIC sont en kana et en kanji, si vous ne pouvez pas au moins déchiffrer les hiragana et les katakana, ce programme n'est pas pour vous. L'auteur n'a aucune intention de produire une quelconque version utilisant le japonais romanisé.
La commande de lancement de XJDIC est :
[SA: Mode Autonome (stand-alone), CL: Client, SV: Serveur]
-d dictionnaire-chemin_et_nomdufichier [SA,SV]
Le chemin et le nom du fichier du dictionnaire japonais-anglais à utiliser. S'il y a plus d'un dictionnaire à utiliser, vous devrez employer plusieurs options "-d". Si cette option n'est pas présente, seul le fichier de dictionnaire EDICT sera utilisé, ainsi que le fichier d'indexation edict.xjdx. Ils doivent être réunis dans le même répertoire courant, ou dans un répertoire spécifié dans les variables d'environnement de XJDIC. Le dictionnaire peut également être spécifié dans le fichier .xjdicrc (voir ci-dessous).
-k kanji_dictionnaire-chemin_et_nomdufichier [SA,SV]
Le chemin et le nom du fichier du dictionnaire de kanji à utiliser. S'il n'est pas présent, seul le fichier de dictionnaire KANJIDIC sera utilisé, ainsi que le fichier d'indexation kanjidic.xjdic. Ils doivent être réunis dans le même répertoire courant, ou dans le répertoire spécifié dans les variables d'environnement de XJDIC. Le dictionnaire peut également être spécifié dans le fichier .xjdicrc (voir ci-dessous).
-j code_export_japonais (j, e ou s) [SA,CL]
XJDIC utilise le code "New-JIS" comme méthode d'export par défaut. Ce qui devrait convenir si vous fonctionnez sous Kterm. D'autres environnements, qui sont internationalisés (comme par exemple Aixterm) supportent seulement les codes EUC ou Shift-JIS. XJDIC peut être paramétré pour utiliser ces codes par les options en ligne de commande "-j e" ou "-j s". Tapez "-j j" pour rétablir New-JIS (le code par défaut).
-v [SA,CL]
Pour désactiver la fonction de prise en compte des inflections verbales ("de-inflection function").
-K [SV]
Pour éviter que le serveur ne s'établisse lui-même comme démon, c'est-à-dire en programme d'arrière-plan indépendant d'un terminal. (Cette option est principalement destinée au déboguage.)
-P nnnnn [CL,SV]
Pour contraindre la version client/serveur à utiliser le port UDP nnnnn, au lieu du port par défaut (47512). (Ce numéro de port peut également être défini dans le fichier .xjdicrc.)
-S adresse_serveur [CL]
Pour informer le client que le serveur est situé à une adresse spécifique du réseau. (Cette adresse peut également être définie dans le fichier .xjdicrc.)
-E [CL,SA]
Pour signaler au programme qu'il fonctionne en mode EUC, et ainsi l'empêcher d'interpréter les kanji 3 bytes du jeu de caractères JIS X 0212, commençant par un hex 8F, comme du Shift-JIS.
-h [CL,SV,SA]
Cette option a pour résultat l'affichage d'un simple sommaire des options en ligne de commande.
-c [CL,SV,SA]
Pour spécifier le chemin et le nom d'un fichier de contrôle devant être utilisé à la place du fichier par défaut ".xjdirc".
-C [CL,SA]
Pour spécifier le nom d'un fichier mémento (clipboard) devant être utilisé à la place du fichier "clipboard" par défaut.
-V [CL,SA]
Pour désactiver l'utilisation de l'affichage en négatif des résultats.
Comme décrit ci-dessous, l'invite par défaut de XJDIC est paramétrée pour la recherche de mots clefs. Il pourra cependant réagir à certaines frappes non-alphabétiques et les traiter comme des instructions pour changer de mode opératoire, ou pour activer certaines fonctions spéciales. Ces commandes sont décrites ci-dessous comme elles apparaissent dans le texte et sont récapitulées dans l'Appendice A.
D. SAISIE DES CLEFS DE RECHERCHE
XJDIC opère dans deux modes : dictionnaire japonais-anglais et dictionnaire de kanji.
Dans le cas du dictionnaire japonais-anglais, les clefs de recherche sont saisies en réponse au message d'invite "XJDIC [nom] SEARCH KEY:". Le "[nom]" peut être soit le nom du dictionnaire courant, soit "[GLOBAL]" dans le cas d'une utilisation de l'option de recherche globale. Les clefs de recherche peuvent être en anglais (généralement saisies au clavier), en kana et/ou en kanji (entrées via un programme front-end comme Kinput2, ou en utilisant le convertisseur interne romaji/kana (voir ci-dessous), ou encore copiées depuis une autre fenêtre en utilisant les fonctions X11 de la souris.)
Pour invoquer le convertisseur romaji/kana, vous avez deux possibilités :
(Un mode d'affichage alternatif est possible, utilisant le format "brut" d'EDICT. Ce mode, qui est surtout utile lorsqu'on procède à la mise à jour du dictionnaire, peut être activé par la commande "|".)
Une ligne n'est affichée qu'une fois par recherche, sans considération du nombre de correspondances qu'elle contient.
S'il résulte de la recherche un nombre d'entrées supérieur à ce que l'écran peut afficher, un message d'invite apparaît en bas de l'écran vous proposant d'afficher l'écran suivant. Quand toutes les correspondances de la recherche ont été affichées, le mot clef est abrégé à un caractère et l'affichage normal reprend.
La recherche de clefs en kana est insensible au fait qu'elles soient en katakana ou en hiragana, cependant, il est à noter que les conventions pour les voyelles longues diffèrent entre les mots japonais et les garaigo (N.D.T. : mots japonais d'origine étrangère). La saisie de mots clefs anglais est insensible à la casse.
L'affichage du résultat de la recherche se fait dans "l'ordre du dictionnaire", c'est-à-dire dans l'ordre alphabétique pour une recherche en anglais et dans l'ordre du code JIS pour les recherches en japonais. Le classement JIS est très proche du classement "gojuuon" des kanas utilisé dans les dictionnaires japonais, excepté qu'il sépare les syllabes par les marquages diacritiques nigori et maru.
Si le mot utilisé pour la recherche dans le dictionnaire est composé d'un kanji accompagné de deux hiragana ou plus, les kanas sont comparés aux inflexions courantes des verbes et des adjectifs. Si un résultat est trouvé, la recherche est d'abord faite pour la forme entière ou "forme du dictionnaire" du mot. Les combinaisons possibles des inflections ou des conjugaisons sont contenues dans le fichier vconj.
La fonction de non prise en compte des inflections ("de-inflection function") peut être activée ou désactivée en utilisant la commande ":".
Il est possible d'installer plusieurs "filtres" réduisant l'affichage aux entrées du dictionnaire contenant certaines chaînes de caractères, ou supprimant l'affichage des entrées comportant certaines séquences. Cette fonction est utile si l'utilisateur veut éviter le grand nombre de noms propres présents dans le dictionnaire. Voir la section FILTRES ci-dessous pour plus de détails et savoir comment installer de tels filtres de séquences. Ces filtres peuvent être activés ou désactivés individuellement par la commande ";".
De plus, il est possible de définir ou d'isoler par un filtrage une séquence "unique" devant être présente dans une ligne pour qu'elle soit affichée. Cela peut être fait par la commande " ' " (simple guillemet droit). Cette séquence peut être en anglais, kana ou kanji. Il est par exemple possible de rechercher des entrées comportant un kanji particulier avec une lecture spécifique en définissant cette lecture comme filtre et en effectuant la recherche du kanji.
(À noter que l'utilisation des filtres nécessite quelques précautions, particulièrement pour des clefs de recherche qui ont potentiellement de nombreux sens, car le programme peut être très ralenti par l'examen des entrées en fonction des requêtes ou exclusions des filtres.)
Comme option supplémentaire, il est possible de restreindre une recherche pour un mot clef en anglais aux mots qui ont été marqués dans le dictionnaire comme ayant une priorité haute. Ce marquage consiste à ajouter un "@" à ces mots. Ce mode de "recherche prioritaire" est activé ou désactivé par la commande "+". Ces mots anglais "prioritaires" sont affichés en négatif.
À noter qu'il est possible d'utiliser plusieurs dictionnaires, comme spécifié dans la ligne de commande ou dans le fichier .xjdicrc, et de sélectionner le dictionnaire que l'on veut utiliser pour la recherche en utilisant les commandes "=", "^" ou "_". Voir la section ci-dessous concernant les dictionnaires additionnels.
Depuis la V2.3, XJDIC intègre une option "mémento" ("clipboard"), invoquée par la commande "{". Une fois en mode mémento, XJDIC lit un fichier appellé "clipboard" (par défaut, un autre fichier pouvant être spécifié en ligne de commande ou dans le fichier de contrôle), et si ce fichier a changé depuis sa dernière lecture, la première ligne est utilisée comme clef de recherche. XJDIC ne répond pas du tout au clavier dans ce mode ; pour sortir, le mémento doit contenir la séquence "quit".
XJDIC peut sélectionner un kanji individuellement par plusieurs techniques, et afficher les informations le concernant. Ce caractère peut ensuite être "copié-collé" pour une recherche dans le dictionnaire principal, et ainsi afficher toutes les entrées commençant ou contenant ce caractère.
Le dictionnaire principal de kanji utilisé par XJDIC est KANJIDIC, quelques détails à ce propos sont inclus ci-dessous. Ce fichier contient les 6 355 kanji du code JIS X 0208-1990. En supplément, le fichier KNJD212 est disponible pour ajouter les 5 801 kanji supplémentaires du jeu de caractères JIS X 0212-1990. Ces deux fichiers peuvent être combinés et utilisés comme un fichier unique.
La recherche dans le dictionnaire de kanji peut être lancée en entrant "" (N.D.T. : une paire de guillemets), ce qui doit faire apparaître le message "KANJI LOOKUP TYPE:" Le type de recherche du kanji est spécifié en entrant une des lettres suivantes :
J - Par son code "JIS". Il s'agit d'un code standard à quatre chiffres en hexadécimal utilisé pour identifier chaque caractère japonais. Il est aussi possible de saisir les quatre chiffres du code Kuten précédés d'un "k" et les 4 chiffres du code Shift-JIS précédés d'un "s". (Si vous utilisez les entrées KANJD212 dans votre fichier de kanji, vous pouvez le spécifier en utilisant un "h" devant les codes JIS ou Kuten. Les kanji JIS X 0212 n'ont pas de code Shift-JIS.)
C - Par un des codes identifiants présents dans le dictionnaire de kanji. Les codes présents dans KANJIDIC sont :
(Pour la recherche de bushu, il vous sera également demandé le nombre de traits, et seul le kanji réunissant la combinaison bushu/nombre de traits sera affiché. Si vous voulez afficher tous les kanji correspondant à ce bushu, entrez 0 comme nombre de traits et appuyez sur "Entrée".)
(D'autres codes seront peut-être ajoutés, vérifiez pour cela le fichier kanjidic.doc.)
M - Par sa "signification" anglaise.
L - Entame une recherche de kanji multiradicale, dans laquelle l'utilisateur peut définir jusqu'à 10 radicaux composant le kanji. Voir ci-dessous (d).
R - Lance un affichage de tous les bushu accompagnés de leur numéro.
Si aucun code identifiant n'est entré, XJDIC suppose qu'il s'agit d'une recherche d'un kanji ou d'un yomikata.
Une fois que les critères de recherche ont été fournis par une des techniques décrites ci-dessus, XJDIC affiche le kanji correspondant à ces critères. Cet affichage peut avoir une de ces deux formes :
Dans la forme étendue de l'affichage, les informations qui suivent sont affichées :
À noter qu'il est possible de supprimer l'affichage de certains champs par l'utilisation de la directive "kdnoshow" dans le fichier .xjdicrc.
À ce stade, l'utilisateur peut demander l'affichage de toutes les expressions composées contenant ce caractère en utilisant la souris pour sélectionner le kanji et le rentrer comme clef d'une recherche dans le dictionnaire principal.
XJDIC a deux modes pour afficher les expressions composées contenant une séquence particulière d'un ou plusieurs kanji. Soit l'affichage est restreint aux seuls composants débutant par cette séquence, soit tous les composants contenant la séquence seront affichés. Quand XJDIC charge ces données, c'est dans le mode le plus restreint, cependant il est possible de basculer dans l'autre mode en utilisant la clef "/".
Le fichier EDICTEXT, associé au dictionnaire principal EDICT, contient des informations supplémentaires concernant une selection d'entrées d'EDICT. En règle générale, le fichier EDICTEXT contient un ou deux paragraphes d'informations supplémentaires, incluant des exemples de l'utilisation du mot ou de la phrase en japonais. Le fichier EDICT comporte un marqueur "[qv]" apparaissant avec l'entrée et indiquant que des informations supplémentaires sont disponibles.
Il est possible de sélectionner et d'afficher les informations du fichier EDICTEXT depuis XJDIC, en générant un fichier edictext.xjdx valide.
Pour afficher les informations du fichier EDICTEXT, vous devez invoquer le mode approprié en pressant la touche "]", et copier-coller le mot clef en kanji ou kana dans la zone de recherche. S'il y a une entrée dans le fichier EDICTEXT qui correspond au mot clef d'EDICT, elle sera affichée.
Le système de sélection multiradicale des kanji utilise un volumineux fichier où les kanji sont identifiés par tous les radicaux qui les composent. Ce fichier a été très soigneusement mis au point par Michael Raine en 1994/1995, avec l'intention de faciliter la recherche des kanji par cette méthode. Le fichier de Michael, ainsi que la technique de base d'identifier plus d'un radical par kanji, a été utilisé par Derc Yamasaki pour ajouter cette fonction à JWP (depuis la version 1.2) et a également été utilisé par Dan Crevier pour son programme Unidict (qui n'est plus mis à jour au moment où j'écris ceci). Cette technique est seulement applicable aux 6 355 kanji JIS X 0208.
À noter que les "radicaux" utilisés dans cette classification des kanji sont pour la plupart des radicaux "classiques", plus un nombre d'autres éléments se rencontrant communément. Pour utiliser cette technique efficacement, une connaissance des radicaux et des éléments est nécessaire. Une méthode d'utilisation consiste à lancer le programme xjdrad, inclus dans les fichiers d'XJDIC, dans une autre fenêtre. Ce programme affiche tous les radicaux et les éléments, et pourra être utilisé comme une source de données à copier-coller dans la zone de recherche d'XJDIC.
Presser "L" à la suite du message "KANJI LOOKUP TYPE:" basculera XJDIC dans le Mode Recherche de Radical (Radical Lookup Mode) et fera apparaître le message d'invite "Lookup Code:". Le programme restera dans ce mode jusqu'à ce que l'utilisateur demande à retourner dans le mode normal en pressant la touche "X".
Les éléments qui peuvent être entrés après le message d'invite "Lookup Code:" sont :
Pour quitter XJDIC, taper Ctrl-D. Ctrl-C fonctionnera, mais devrait laisser echo éteint. Entrer Ctrl-Z lors du message d'invite "SEARCH KEY:" mettra le programme en veille. Il pourra être rappelé en tapant "fg" au message d'invite de la ligne de commande Unix. (Le programme quittera également avec la commande "bye" pour rester compatible avec les versions antérieures.)
Les informations sur les commandes basiques peuvent être obtenues en tapant "?". Un sommaire des options en ligne de commande peut être obtenu dans XJDIC avec l'option "-h". La licence publique GNU peut être affichée en tapant "!".
G. CONVERSION ROMAJI VERS KANA
Pour saisir une clef de recherche en kana, débutez votre frappe par "@" (hiragana) ou par "#" (katakana), puis rentrez la clef en romaji : elle sera convertie en kana durant la frappe. La conversion romaji->kana est presque identique à celle utilisée par des logiciels front-end comme Kinput, MOKE et d'autres traitements de texte japonais. Par exemple, pour un petit tsu, vous pourrez taper soit une double consonne, par exemple shippai, soit t-, ce qui donne shit-pai et pour n vous pouvez taper n' si nécessaire (comme par exemple dans hon'ya). La plupart du temps, la saisie en romaji ordinaire Hepburn ou kunrei fonctionne. Notez que le romaji suit le style kana concernant les voyelles longues. Tokyo doit être écrit toukyou et PAS tookyoo.
Les actuelles règles de conversion romaji vers kana sont définies dans le fichier romkana.cnv. Ce fichier fournit les règles pour la saisie de tous les caractères kana. Il peut, toutefois, être édité si vous voulez ajouter des tracés supplémentaires, par exemple pour des constructions modernes de katakana mora.
Kterm peut fonctionner avec les jeux de codes JIS, EUC ou Shift-JIS (comme spécifié par la ligne de commande, ou par Ctrl-bouton_central_de_la_souris). XJDIC utilise en interne EUC et affiche en (new) JIS, EUC ou Shift-JIS. New-JIS est utilisé par défaut, et les autres codes peuvent être spécifiés par une option en ligne de commande ou dans le fichier .xjdicrc. Il acceptera en import n'importe quel type de code.
En fait, les opérations de XJDIC sont plus fluides en mode JIS. Cela est dû au fait qu'il détecte la séquence de fin shift out, présente dans ce code et lance immédiatement la recherche dans le dictionnaire. Il est ainsi possible de copier une séquence d'un document qu'on est en train de lire et de lancer une recherche, uniquement à l'aide de la souris. (L'entrée d'une séquence de kana/kanji en réponse à presque tous les messages d'invite de XJDIC aboutira à une recherche dans le dictionnaire de cette séquence.)
Notez que si vous utilisez les kanji supplémentaires du jeu de caractères JIS X 0212-1990, vous devrez utiliser un environnement approprié, comme Kterm avec le correctif (patch) X11R6. Dans un tel environnement, seuls les codes JIS et EUC seront disponibles et le code Shift-JIS ne pourra pas afficher les kanji JIS X 0212.
Les performances de XJDIC dépendent du nombre de dictionnaires utilisés, habituellement un ou plusieurs dictionnaires japonais <-> anglais et le dictionnaire de kanji, qui est une extension du dictionnaire EDICT de MOKE, écrit par l'auteur, ainsi que le fichier du dictionnaire de caractères KANJIDIC, compilé par l'auteur depuis des sources variées. EDICT compte maintenant plus de 100 000 entrées et KANJIDIC comporte une entrée pour chaque kanji du standard JIS X 0208-1990.
(En complément, vous trouverez plusieurs fichiers de données, comprenant : un fichier de radicaux, radicals.tm, compilé initialement par Theresa Martin pour le programme JDIC ; le fichier romkana.cnv de conversion romaji-kana ; le fichier vconj des inflexions verbales qui a été compilé par l'auteur, à partir d'un ancien fichier .hlp de MOKE.)
Le format de chaque entrée dans EDICT est :
ou
kana /Anglais_1/Anglais_2/..../
KANJIDIC est une compilation d'informations sur chaque kanji du standard JIS X 0208. Il a pour format :
Kanji hex_JIS_code Unnnn Bnnn Snn
Où N, H, B, S et G marquent respectivement le numéro Nelson, Halpern, bushu, le nombre de traits et la classe (scolaire). Le code Pn-n-n est le code SKIP d'Halpern pour trouver les kanji. Les lectures on sont en katakana et les lectures kun en hiragana. Pour une information complète sur ce fichier, se reporter au fichier kanjidic.doc.
XJDIC a une option lui permettant de supporter de multiples fichiers de dictionnaires. Pour utiliser cette option, les fichiers des dictionnaires additionnels doivent être rendus utilisables par un fichier .xjdx approprié et identifiés par XJDIC via l'option en ligne de commande "-d", ou via le fichier .xjdicrc, dans les lignes "dicfile". Notez que si vous spécifiez des dictionnaires supplémentaires, vous devrez indiquer à XJDIC tous les dictionnaires que vous utilisez, y compris EDICT, et vous devrez indiquer le chemin complet jusqu'à ces fichiers.
On peut accéder à ces dictionnaires additionnels des façons suivantes :
Plus de dix jeux de filtres peuvent être spécifiés en utilisant les lignes "filt" dans .xjdicrc. Ils permettent de n'afficher que les entrées contenant, ou ne contenant pas, certaines séquences de texte.
Il y a trois types de filtres :
filt f t on|off "nom du filtre" séquence_1 séquence_2 ....
où :
t - le type du filtre (0, 1 or 2)
on|off - définit le statut initial du filtre
"nom du filtre" - les " " délimitent le nom du filtre, ne devant pas excéder 50 caractères.
séquence_n - un espace doit séparer les séquences devant faire partie de l'opération de filtrage. Jusqu'à 10 séquences par filtre, chacune de 10 caractères maximum.
[Ce filtre, s'il est activé, évitera l'affichage d'entrées qui ne se rapportent qu'à des noms propres.]
filt 1 0 "Ne montrer que les noms de lieux" (pl, pl)
[Ce filtre permet d'utiliser XJDIC comme un dictionnaire des localités.]
filt 2 1 "Supprimer les expression familières" (col) (col.)
Configurez avec prudence vos filtres, car leurs requêtes peuvent obliger XJDIC à examiner un grand nombre d'entrées du dictionnaire et il peut en résulter un affichage ralenti des résultats. Notez que quand une entrée correspond à une condition fixée par un filtre, aucune recherche supplémentaire n'est menée pour cette entrée.
Comme mentionné plus haut, il est possible de définir ou d'isoler par un filtrage une séquence "unique" devant être présente dans une ligne pour qu'elle soit affichée. Cela peut être fait par la commande " ' " (simple guillemet droit). Cette séquence peut être en anglais, kana ou kanji. Il est ainsi possible, par exemple, de chercher les expressions composées de deux kanji, en définissant l'un comme filtre pour chercher l'autre. Il s'agit ici d'un filtre de type 0.
Les utilisateurs du programme JREADER, écrit par l'auteur, remarqueront qu'XJDIC n'a pas de fonctions de notation. C'est parce que X11 rend possible la saisie dans d'autres fenêtres d'éditeurs de texte comme Jstevie ou Nemacs, au lieu de l'édition d'un simple fichier de notation.
JREADER avait aussi une fonction d'examen des composants des kanji, absente d'EDICT, grâce au fichier kanji->kana de MOKE (wsktok.dat). Si vous souhaitez avoir cette fonctionnalité dans XJDIC, fournissez-vous le fichier wsktok.dat, et utilisez-le comme dictionnaire additionnel.
XJDIC utilise un fichier de contrôle appelé ".xjdicrc". XJDIC recherchera ce fichier dans le répertoire identifié par les variables d'environnement de XJDIC, dans le répertoire home et finalement dans le répertoire en cours. Un nom de fichier peut également être défini avec l'option en ligne de commande "-c".
XJDIC fonctionnerait très bien sans un fichier .xjdicrc, mais c'est une façon facile de définir différentes options, et c'est le seul moyen de configurer des filtres pour rechercher ou supprimer l'affichage de certains champs de KANJIDIC.
.xjdicrc contient les lignes de texte suivantes :
line_type
Les line_types sont :
[SA: Mode autonome (stand-alone), CL: Client, SV: Serveur]
Détails de la configuration des filtres (voir la section FILTRES).
omode e|j|s [SA,CL]
Définit le code pour l'affichage à l'écran : EUC, JIS ou Shift-JIS.
kanamode
Définit les hiragana comme mode de saisie par défaut.
dicdir chemin_vers_le_fichier [SA,SV,CL]
Définit l'emplacement des fichiers de dictionnaires et de données. Le programme cherchera d'abord dans ce répertoire, puis dans le fichier local actif. Cela concerne tous les fichiers à l'exception du mémento et du fichier de contrôle lui-même. Notez que cette ligne doit apparaître avant les lignes dicfile, etc.
dicfile chemin_vers_le_fichier [SA,SV]
Les noms des dictionnaires (par défaut : edict).
kdicfile chemin_vers_le_fichier [SA,SV]
Nom du dictionnaire de kanji (par défaut : kanjidic).
romfile chemin_vers_le_fichier [SA,CL]
Fichier de conversion en romaji (par défaut : romkana.cnv).
verbfile chemin_vers_le_fichier [SA,CL]
Fichier de conjugaisons (par défaut : vconj).
radfile chemin_vers_le_fichier [SA,CL]
Fichier des numéros de radicaux/bushu (par défaut : radicals.tm).
radkfile chemin_vers_le_fichier [SA,CL]
Fichier des radicaux/kanji pour la recherche multiradicale (par défaut : radkfile).
jverb on|off [SA,CL]
Activer ou désactiver la fonction de non prise en compte des inflections verbales.
kdnoshow ABCDE... [SA,CL]
Déclaration des champs de KANJIDIC devant être supprimés de l'affichage. Par exemple, "kdnoshow YMQ" empêchera l'affichage des informations Pin Yin des indices Four-Corner et Morohashi.
exlist and from but .... ....
Déclaration des mots communs de 3 lettres ou plus devant être exclus des fichiers .xjdx générés par XJDXGEN. Il peut y avoir plusieurs lignes "exlist" dans le fichier.
clipfile [SA,CL]
Définit le nom du fichier à utiliser pour le mémento.
gnufile [SA,CL]
Définit le nom du fichier de la licence publique générale GNU (GPL). (Par défaut "gnu_licence".)
rvdisplay on | off [SA,CL]
Définit le paramétrage initial de l'affichage des résultats en négatif. (Par défaut sur on.)
En plus du fichier de configuration .xjdirc, XJDIC requiert la présence de cinq autres fichiers :
Voir le document xjdic23.install pour des informations sur la compilation de XJDIC et la configuration des fichiers d'index et de dictionnaires.
Notez qu'il a deux options de compilation pour XJDIC. Vous pouvez l'installer comme un programme autonome ou comme un couple client/serveur. Vous pouvez également spécifier le module qui effectuera la recherche dans les fichiers des dictionnaires (au choix programme autonome ou serveur), maintenir tous les fichiers de dictionnaires et d'index dans la RAM, utiliser un bus partagé (memory-mapped I/O) (par défaut) ou encore opérer par un mécanisme de demande-pagination sur ces fichiers. La première méthode prendra évidemment plus de RAM et d'espace de swap, mais sera habituellement plus rapide, alors que la dernière tournera plus lentement mais coexistera plus facilement avec d'autres programmes et pourra fonctionner sur des configurations plus modestes. Voir le fichier xjdic23.install pour plus de détails sur ces options.
Assurez-vous d'avoir l'exécutable XJDIC dans votre chemin d'exécution et que les fichiers du dictionnaire, d'index et des radicaux soient dans votre dossier courant, ou à un emplacement spécifié dans le fichier .xjdicrc.
XJDIC n'était au début qu'une refonte de mes précédents programmes JDIC/JREADER qui furent écrits pour PC et clones. La plus grande partie du code provient de JREADER. Il a été augmenté, mais en règle générale les versions d'XJDIC suivaient celles de JDIC/JREADER.
En produisant XJDIC, je me suis beaucoup appuyé sur l'environnement japonais tel qu'il est fournit par Kterm, avec pour résultat que XJDIC est plus léger que JDIC ou JREADER. J'ai également opté pour une approche différente du dictionnaire de kanji. Alors que pour JDIC/JREADER j'utilisais un fichier compressé du dictionnaire de kanji, avec des fichiers d'index séparés pour les numéros Nelson, nombre de traits, yomikata... (originellement conçu par Stephen Chung pour son traitement de texte JWP), dans XJDIC, j'ai employé la même approche d'indexation et de consultation qu'avec le dictionnaire principal.
Le format d'affichage de XJDIC n'est peut-être pas aussi élégant que celui de JDIC et JREADER, principalement parce que je n'ai pas vraiment le contrôle d'aspects essentiels, comme la fenêtre et la taille de la police. Cela est plus que compensé par les avantages inhérents à un environnement de fenêtrage.
XJDIC ne gagnera aucun prix pour sa convivialité, parce que totalement dénué de fenêtres bondissantes, d'ascenseurs, de boutons pour telle ou telle fonction et qu'il compte sur l'utilisateur pour utiliser un ensemble de commandes se résumant à des lettres, le plus souvent sans aide mnémotechnique. Il y a plusieurs raisons à cela :
Cameron Blackwood m'a aidé pour le code cbreak, Paul Burchard a fourni les versions purement BSD de ce programme, Hitoshi Doi (qui l'a fait fonctionné sur un DEC Alpha 64-bit) a mis en évidence la faiblesse de mes hypothèses sur la longueur systématique en 4 bytes des grands nombres entiers, Hank Cohen m'a montré comment détecter la taille d'une fenêtre. L'aide la plus précieuse dans les versions récentes m'a été fournie par William Maton, qui a mené des tests très poussés et a suggéré de nombreuses améliorations de fonctionnement.
J'ai été grandement aidé dans la conversion du code pour le fonctionnement en mode client/serveur par l'excellent livre Internetworking with TCP/IP Vol III (BSD Sockets) de Comer & Steven's.
Une mention spéciale pour Andrew Moore, mon ancien administrateur système du Département, qui a travaillé dur et longtemps, en 1992, pour installer Wnn/Kterm/Kinput sur notre réseau DEC5000/3000/2000 (Ultrix) sans connaître un seul mot de japonais. Comme c'était certainement la première installation sur Ultrix en dehors du Japon, on peut dire que ce fut un vrai exploit. Les temps ont changé, la plupart de mes travaux sur la V2.0 et suivantes ont été faits sur "marvin", mon 486 personnel, tournant sous Linux. Le JE (Japanese Environment) de Linux marche formidablement bien et c'est un vrai plaisir de l'utiliser. La V2.3 a été achevée sur une Redhat Linux 5.0, ce qui m'a obligé à me confronter à un environnement plus POSIX.
Les sources sont maintenant disponibles pour le monde et sont sujettes aux limitations GPL. Il a été installé avec succès sur de nombreuses plates-formes Unix. Un portage/refonte très réussi sur Macintosh a été entrepris par Dan Crevier pour aboutir au très populaire programme MacJdic qui a été classé récemment parmi les 100 premiers programmes Mac au Japon.
Comme toujours, les commentaires et les remarques constructives sont les bienvenues.
Les améliorations de la Version 1.1 sont :
** Ces options sont aussi incluses dans la V2.5 de JDIC/JREADER.
APPENDICE A - SOMMAIRE DES COMMANDES
(Cet appendice contient une copie des informations affichées par XJDIC en réponse à la commande _?_).
À l'invite XJDIC SEARCH KEY : répondre par une séquence de caractères ASCII, kana et/ou
kanji à rechercher dans le dictionnaire courant (précédéé de @ ou # pour invoquer une
conversion de romaji vers hiragana ou katakana.)
COMMANDE PAR LETTRES
\ entrer dans le mode dictionnaire de kanji ? affiche cette aide
_ sélectionne les dictionnaires =/^ fait défiler vers le haut/bas la liste des dictionnaires
' active/désactive le filtre de séquence unique ; active/désactive les filtres généraux
/ active le mode composants_du_kanji - active/désactive l'affichage étendu des kanji
$ définit les diction. de la recherche globale % active/désactive le mode de recherche gobale
] affiche les extensions du dictionnaire : active/désactive les inflections des verbes
+ active la priorité aux clefs en anglais | active/désactive le mode d'affichage non édité
[ active/désactive correspondance exacte & active/désactive le mode de saisie en kana
{ bascule vers la saisie via mémento } active/désactive l'affichage en négatif des résultats
* affiche les statistiques de la page de mémoire tampon Ctrl-D pour quitter
! affiche la licence gnu Ctrl-Z pour suspendre
Dans le mode dictionnaire de kanji, le message d'invite est : KANJI LOOKUP TYPE:.
Les réponses sont :
un kanji seul, ou une lecture kana (par défaut)
j suivi d'un code JIS hexadécimal à 4 chiffres pour un kanji
j suivi d'un k et du code Kuten à 4 chiffres pour un kanji
(précédez d'un h le code pour les kanji JIS X 0212)
j suivi d'un s et du code Shift-JIS héxadécimal à 4 chiffres pour un kanji
m suivi de la signification (en anglais) du kanji
c suivi d'un numéro d'index comme Nnnn (Nelson), Bnn (bushu), etc.
r affiche l'ensemble des radicaux et leurs numéros
l bascule le programme en mode recherche par radicaux
APPENDICE B - PROTOCOLE DE XJDSERVER
INTRODUCTION
Cet appendice explique le protocole de messages utilisé par la version client/serveur d'XJDIC V2.0 et suivantes. Cette documentation est fournie ici au cas où d'autres développeurs de logiciels souhaiteraient développer des programmes clients qui feraient appel aux fonctionnalités de recherche du programme serveur (XJDSERVER).
Ce texte ne décrit que le protocole. Pour une compréhension complète, le lecteur devra examiner le code dans les modules xjdserver.c et xjdclient.c.
VUE D'ENSEMBLE DU PROTOCOLE SERVEUR
Le programme XJDSERVER est un moteur de recherche pour dictionnaire apatride (stateless). Il ne retient aucune information quelles que soient les précédentes requêtes ou recherches. C'est au programme client de garder la trace de l'objet de la recherche et de fournir tous les détails pour chaque requête. Chaque transaction passant par le serveur est activée par un message adressé par le client. Le serveur traite la requête et renvoie une réponse.
Les messages dans le protocole de XJDSERVER sont transmis entre le client et le serveur via UDP (User Datagram Protocol), qui est un des protocoles Internet. Le serveur utilise la librairie de socket BSD, par laquelle il maintient un socket passif UDP en écoute pour les requêtes sur son port. Le port par défaut est 47512, mais l'installateur peut le modifier, et client comme serveur peuvent paramétrer un numéro de port en ligne de commande.
Le format des requêtes (REQUEST) et réponses (RESPONSE) est exposé ci-dessous :
typedef struct {
long xjdreq_checksum;
short xjdreq_type;
short xjdreq_seq;
short xjdreq_dicno;
long xjdreq_indexpos;
short xjdreq_schlen;
unsigned char xjdreq_schstr[21]; } REQ_PDU;
typedef struct {
long xjdrsp_checksum;
short xjdrsp_type;
short xjdrsp_seq;
long xjdrsp_resindex;
short xjdrsp_hitposn;
short xjdrsp_reslen;
long xjdrsp_dicloc;
unsigned char xjdrsp_resstr[512]; } RSP_PDU;
(Tous les champs entiers short et long ont leurs bytes dans "l'ordre réseau.")
Le champ check-sum consiste simplement en une somme arithmétique de tous les champs du message, à l'exception du champ check-sum lui-même. Si le serveur reçoit un message avec un check-sum incorrect, il est ignoré. Le champ numéro de séquence est retourné au client, uniquement pour qu'il puisse identifier l'ensemble requête/réponse.
Les types de messages, comme définit dans xjdic.h, sont :
. #define XJ_FIND 1 /* find entry */ . #define XJ_ENTRY 2 /* get this entry according to index */ . #define XJ_OK 3 /* find/entry_get succeeded */ . #define XJ_NBG 4 /* find/entry_get failed */ . #define XJ_PROTE 5 /* protocol error - server only */ . #define XJ_HULLO 6 /* just send back an XJ_OK */ . #define XJ_GET 7 /* get this entry, wo checking any match*/Le message XJD_HULLO est classiquement utilisé par le client à l'inititalisation pour vérifier la disponibilité du serveur. À la réception de ce message, le serveur retournera une réponse XJD_OK. Dans ce message, il renverra le nombre de fichiers de dictionnaires disponibles dans son champ xjdrsp_hitposn, et dans la séquence xjdrsp_resstr les noms de ces dictionnaires sous le format suivant :
. #0nom_du_fichier0#1nom_du_fichier1#2...Le XJD_FIND ordonne au serveur de trouver l'entrée dans le dictionnaire xjdreq_dicno qui contient la *première* occurence (dans l'ordre de la liste des marqueurs) de la clef identifiée par les caractères initiaux xjdreq_schlen de la séquence xjdreq_schstr. Si aucun résultat n'est trouvé, un message XJD_NBG est retourné. Si un résultat est trouvé, un message XJD_OK est retourné avec les 511 premiers caractères de l'entrée dans xjdrsp_resstr, la position de la clef parmi les entrées dans xjdrsp_hitposn et le numéro de l'entrée dans le fichier d'index .xjdx dans xjdrsp_resindex.
La requête XJD_ENTRY est similaire à la requête XJD_FIND, excepté qu'elle spécifie dans xjdreq_indexpos le numéro d'index de l'entrée qu'elle veut ; en général majoré d'1 par rapport à la dernière entrée retournée. Si le marqueur associé à l'entrée correspond à la clef, un message XJD_OK contenant l'entrée est retourné, ou dans le cas contraire un message XJD_NBG. Ainsi, ce message renvoie, dans le champ xjdrsp_resindex, la position du caractère correspondant à l'entrée dans le dictionnaire, pour permettre au client de supprimer l'affichage d'entrées comportant des résultats multiples.
VUE D'ENSEMBLE DU PROTOCOLE CLIENT
Comme décrit plus haut, le client envoie des requêtes au serveur et reçoit des réponses. Comme le protocole n'a pas de support d'erreur, les logiciels client et serveur doivent prendre en charge cette tâche. Dans le protocole de XJDSERVER, comme c'est presque toujours le cas avec les serveurs apatrides (stateless server), la plus grande partie de la détection et de la récupération des erreurs de communication est prise en charge par le client.
En particulier, le client doit gérer les problèmes associés au temps que mettent les messages à parcourir le réseau. Dans une zone de réseau local le délai sera habituellement très court, mais pourra s'allonger considérablement si le client utilise une zone encombrée d'un vaste réseau pour communiquer avec le serveur. Dans le protocole décrit plus haut, le client utilise une valeur de dépassement de délai (time-out value) pour détecter si des requêtes ou réponses ont été perdues ou corrompues par le réseau. Comme réglé trop haut, ce délai aurait pour résultat une détection trop lente des erreurs, et trop bas entraînerait des retransmissions inutiles, le protocole client détecte la durée d'un cycle requête/réponse et ajuste la valeur du délai en conséquence.
Le traitement des erreurs basiques est effectué comme suit :
En août 1995, le protocole client/serveur a été testé avec succès entre un client en Australie et un serveur au Canada, et vice versa. Cela a marché de façon stable, bien que plutôt lente, ce qui a bien sûr donné lieu à des retards de cycles de communication. D'autres essais internationaux ont été menés à des dates plus récentes.
APPENDICE C - LES KANJI JIS X 0212-1990
Depuis la V2.2, XJDIC supporte, en tant qu'option, les kanji supplémentaires du standard JIS X 0212-1990. Ces commentaires sont là pour aider les utilisateurs souhaitant utiliser cette option.
Pour utiliser les kanji JIS212, vous devez utiliser XJDIC dans Kterm, qui a été modifié pour supporter ce jeu de caractères. Un correctif spécial pour Kterm X11/R6 est disponible à cet effet, notamment sur de nombreux ftp japonais. Le fichier de police .bdf est aussi nécessaire pour ces caractères. Cette version de Kterm supporte aussi les codes chinois et coréen, mais ne supportera pas l'encodage Shift-JIS.
En interne, XJDIC utilise le codage EUC-3 pour stocker et manipuler les caractères JIS212. Il s'agit d'un code 3-bytes avec le premier byte sous la forme 0x8F. XJDXGEN a été modifié pour générer des index corrects pour ce code.
Faisant partie du dispositif général de support des kanji JIS212, le fichier d'information KANJID212 a été mis en forme. Ce fichier est au même format que le fichier principal JIS208 KANJIDIC.
Depuis la V2.3 de XJDIC, les fonctions de dictionnaire de kanji ont été étendues pour supporter les kanji JIS212. Pour les utiliser, fusionnez le fichier KANJIDIC et KANJD212 en un seul fichier, indexez-le en utilisant XJDXGEN et spécifiez ce fichier comme étant le fichier du dictionnaire de kanji. Dans l'affichage des entrées de kanji, les kanji JIS212 ont leurs codes JIS et Kuten préfixés d'un "1-". Il n'y a pas de code Shift-JIS pour les kanji JIS212. Pour sélectionner un kanji JIS212 en utilisant son code JIS ou Kuten, faites précéder le code d'un "h".
Une version allégée du fichier de dictionnaire EDICT, EDICTH, a été mise au point et intègre les kanji JIS212.
Il y a peu de possibilités d'éditer les kanji JIS212. J'ai cru comprendre que MULE supportait ces kanji, mais je ne peux pas le confirmer. J'ai modifié le clone vi "Jstevie" pour supporter les fichiers encodés en EUC contenant les kanji JIS 212. Mais jusqu'à présent, je n'ai aucun moyen pour imprimer des textes contenant des kanji JIS212.
Traduction : Raphaël Carrand (raphael.carrand@free.fr)