Overblog Suivre ce blog
Administration Créer mon blog
7 février 2013 4 07 /02 /février /2013 17:52

Manchester Mark I

 

 

 

 



Le Manchester Mark I était un des premiers ordinateurs électroniques. Il fut développé à l'université de Manchester à partir de la Small-Scale Experimental Machine (SSEM), le premier ordinateur électronique à programme enregistré (en) en mémoire du monde. Il était également appelé Manchester Automatic Digital Machine (MADM) (« machine numérique autonome de Manchester »)1. Les travaux furent lancés en août 1948 et la première version fut opérationnelle en avril 1949. Un programme écrit pour chercher des nombres premiers de Mersenne fonctionna sans erreur pendant neuf heures dans la nuit du 16 au 17 juin 1949.

Le fonctionnement correct de la machine fut largement couvert par la presse britannique, qui utilisa l'expression « cerveau électronique » pour le décrire aux lecteurs. Cette description provoqua une réaction du directeur du département de neurochirurgie de l'université de Manchester, à l'origine d'un long débat sur la possibilité pour un ordinateur électronique d'être vraiment créatif.

L'objectif initial du développement du Mark I était de fournir un outil de calcul situé dans l'université de Manchester, pour permettre aux chercheurs de prendre de l'expérience dans l'utilisation en pratique d'ordinateurs, mais il devint aussi très rapidement un prototype sur lequel fut basée la conception du Ferranti Mark I. Le développement cessa à la fin de 1949, et la machine fut mise au rebut à la fin de 1950. Elle fut remplacée en février 1951 par un Ferranti Mark I, le premier ordinateur généraliste commercialisé du monde2.

Du point de vue historique, l'innovation essentielle du Mark I est l'inclusion de registres d'index, une innovation qui facilita la lecture séquentielle par un programme d'un vecteur de mots en mémoire. Trente-quatre brevets furent déposés à la suite du développement de la machine, et nombre d'idées dont était issue sa conception furent incorporées par la suite dans des produits commerciaux tels que les IBM 701 et 702 et le Ferranti Mark I. Frederic Calland Williams et Tom Kilburn, qui dirigèrent la conception de la machine, conclurent de leur expérience avec le Mark I que les ordinateurs seraient plus utilisés pour des applications scientifiques que dans le domaine des mathématiques pures. En 1951, ils commencèrent le développement du successeur du Mark I, doté d'une unité de calcul en virgule flottante. Cette machine, appelée Meg, exécuta son premier programme en 1954.

 

Contexte

 

 

 

Article détaillé : Histoire de l'informatique.

 

 

 

Principe de l'architecture de von Neumann.

 

 

 

 

 

En 1936, le mathématicien Alan Turing publia une définition d'une « machine à calculer universelle », un calculateur dont le programme était enregistré sur une bande, avec les données sur lesquelles il travaillait. Turing prouva qu'une telle machine était capable de résoudre tout problème mathématique pour lequel il est possible d'écrire un algorithme3. Pendant les années 1940, Turing et d'autres, comme Konrad Zuse, développèrent l'idée d'enregistrer le programme et les données dans la mémoire d'un ordinateur, au lieu d'une bande4, mais on considère généralement que c'est le mathématicien John von Neumann qui a défini cette architecture d'ordinateur, sur laquelle le Manchester Mark I était basé5.

La construction d'un ordinateur à architecture de von Neumann dépendait de la disponibilité d'un support de mémoire approprié. La Small-Scale Experimental Machine (SSEM), le premier ordinateur à programme enregistré en mémoire du monde, construit par l'université de Manchester, avait démontré la viabilité de l'enregistrement du programme en mémoire et du tube de Williams, une forme primitive de mémoire informatique basée sur un tube cathodique (CRT) standard, en exécutant son premier programme en juin 19486. Les premiers ordinateurs électroniques étaient généralement programmés par recâblage, ou par des panneaux de contrôle. Au contraire des ordinateurs modernes, ils n'avaient pas de programme séparé enregistré en mémoire. Il pouvait falloir plusieurs jours pour reprogrammer l'ENIAC, par exemple7 . D'autres chercheurs développaient des ordinateurs à programme enregistré en mémoire, notamment le Pilot ACE au National Physical Laboratory, l'EDSAC à l'université de Cambridge, l'EDVAC par l'armée américaine8. La SSEM et le Mark I se distinguaient essentiellement par l'utilisation de tubes de Williams comme support de mémoire, au lieu de lignes de délai au mercure9.

Le développement de la SSEM commença vers août 1948. Conçue essentiellement comme un prototype pour le Manchester Mark I, elle devait fournir à l'université un outil de calcul plus réaliste10. En octobre 1948, Ben Lockspeiser, scientifique en chef du gouvernement britannique, assista à une démonstration du prototype du Mark I au cours d'une visite à l'université de Manchester. Lockspeiser fut si impressionné par ce qu'il vit qu'il lança immédiatement un contrat gouvernemental avec l'entreprise locale Ferranti pour fabriquer une version commerciale de la machine, le Ferranti Mark I11. Dans sa lettre à l'entreprise, datée d'octobre 1948, Lockspeiser autorise la compagnie à « lancer le projet dont nous avons parlé, c'est-à-dire construire une machine à calculer électronique selon les instructions du professeur F. C. Williams »12 . À partir de ce moment, le développement du Mark I avait l'objectif supplémentaire de fournir à Ferranti le design sur lequel baser leur machine commerciale13. Le contrat du gouvernement avec Ferranti dura cinq ans à partir de novembre 1948, pour un montant estimé à 35 000 £ par an, soit environ 950 000 £ de 201011.

Développement et conception

 

 

 

Schéma de fonctionnement montrant les tubes de Williams en vert. Le tube C contient l'instruction actuelle et son adresse, A est l'accumulateur, M contient les opérandes d'une multiplication, et B contient les registres d'index, qui servent à modifier le comportement des instructions.

 

 

 

 

 

La SSEM avait été conçue par l'équipe de Frederic Calland Williams, Tom Kilburn et Geoff Tootill. Deux étudiants les rejoigrent pour développer le Mark I : D. B. Edwards et G. E. Thomas. Le travail commença en août 1948. Le projet eut bientôt le double objectif de fournir à Ferranti le design sur lequel baser leur machine commerciale, le Ferranti Mark I, et de construire un ordinateur qui permettrait aux chercheurs de se rendre compte de l'utilisation possible d'une telle machine en pratique. La première des deux versions du Manchester Mark I, la version intermédiaire, fut opérationnelle en avril 1949 Cependant, cette première version n'avait pas les instructions nécessaires pour qu'un programme puisse transférer des données entre la mémoire principale et la nouvelle mémoire secondaire magnétique. Il fallait donc le faire en arrêtant la machine et en effectuant le transfert à la main. Ces instructions manquantes furent incorporées dans la version finale, qui fonctionnait complètement en octobre 194913.' La machine contenait 4 050 tubes électroniques et consommait 25 kilowatts14. Pour augmenter la fiabilité, des CRT spécialement fabriqués par General Electric Company furent utilisés dans la machine au lieu des tubes standard utilisés dans la SSEM2.

Le Mark I utilisait des mots de 40 bits, contre 32 bits pour la SSEM. Chaque mot contenait soit un nombre de 40 bits, soit deux instructions machine de 20 bits. La mémoire principale consistait en deux tubes de Williams contenant chacun une page de 32 mots de 40 bits. Un tambour magnétique capable d'enregistrer 32 pages supplémentaires étendait cette mémoire ; la capacité du tambour atteignait 128 pages dans la version finale. Le tambour de 30 cm15, appelée roue magnétique au début, contenait une série de pistes magnétiques parallèles à sa surface, chacune dotée de sa propre tête de lecture/écriture. Chaque piste contenait 2 560 bits, soit 2 pages (2 x 32 x 40 bits). Une révolution du tambour prenait 30 millisecondes. Pendant ce temps, il était possible de transférer les deux pages vers la mémoire principale ; cependant, le temps de transfert réel dépendait de la latence, le temps qu'il fallait à une page pour arriver sous la tête de lecture/écriture. L'écriture de pages dans le tambour prenait environ le double du temps de lecture13. La vitesse de rotation du tambour était synchronisée avec l'horloge principale, ce qui permettait l'ajout de tambours supplémentaires. Les données étaient enregistrées sur le tambour en utilisant une technique de modulation de phase que l'on appelle encore aujourd'hui codage Manchester16.

Le jeu d'instructions de la machine fut augmenté de 7 pour la SSEM à 26 au début, multiplications effectées par le matériel incluses. La version finale comptait 30 instructions. Dix bits de chaque mot étaient réservés pour représenter le code de l'instruction. Le temps d'exécution normal d'une instruction était 1,8 milliseconde, mais la multiplication était bien plus lente, en fonction de la taille de l'opérande17.

L'innovation la plus significative de la machine fut peut-être l'incorporation de registres d'index, que l'on trouve sur tous les ordinateurs modernes. La SSEM avait deux registres, réalisés par des tubes de Williams ; l'accumulateur (A) et le compteur ordinal (C). Comme les noms A et C étaient déjà pris, le tube contenant les deux registres d'index, appelés B-lines à l'origine, fut appelé B. Le contenu de ces registres pouvait être utilisé pour modifier le comportement d'instructions de programme, ce qui facilitait le parcours d'un vecteur de nombres enregistrés en mémoire. Le Mark I avait aussi un quatrième tube, (M), qui contenait les opérandes d'une multiplication16.

 

 

 

 

Programmation

 

 

 

Section de ruban perforé montrant comment un mot de 40 bits était représenté sous la forme de 8 caractères de 5 bits.

 

 

 

 

 

Sur les 20 bits utilisés pour chaque instructions de programme, 10 contenaient le code de l'instruction, ce qui permettait de représenter 1 024 (210) instructions distinctes. La machine en avait 26 au départ10, ce nombre passa à 30 avec l'ajout des codes d'instructions permettant aux programmes de contrôler le transfert de données entre le tambour magnétique et la mémoire principale à tube cathodique. Sur la version intermédiaire, les programmes étaient entrés par des interrupteurs, et la sortie était affichée sous la forme d'une série de points et de traits sur un écran cathodique appelé périphérique de sortie, exactement comme sur la SSEM à partir de laquelle le Mark I avait été développé. Cependant, la machine finale, terminée en octobre 1949, bénéficiait en plus d'un téléscripteur avec un lecteur de ruban perforé à 5 trous13.

Le mathématicien Alan Turing, qui avait été nommé au poste symbolique de directeur adjoint au laboratoire des machines à calculer de l'université de Manchester en septembre 194810 , inventa un schéma de codage en base 32 basé sur le code Baudot, un standard pour les téléscripteurs, grâce auquel les programmes et les données pouvaient être lus et écrits sur le ruban de papier18. Le code Baudot associe un seul caractère à chacune des 32 (25) valeurs qui peuvent être représentées sur 5 bits. Ainsi, « 10010 » représente « D », « 10001 » représente « Z », et ainsi de suite. Turing ne changea que quelques-uns des codes standard ; par exemple, « 00000 » et « 01000 », qui signifient « aucun effet » et « retour à la ligne » dans le code de téléscripteur, étaient représentés par les caractères « / » et « @ », respectivement. Le zéro binaire, représenté par la barre oblique, était le caractère le plus fréquent dans les programmes et les données, ce qui produisait des séquences de la forme « /////////////// ». Un des premiers utilisateurs suggéra que le choix de Turing de la barre oblique était un choix subconscient de sa part, une représentation de la pluie vue à travers une vitre sale, reflétant le temps « réputé lugubre » de Manchester19.

Comme le Mark I avait des mots de 40 bits, il fallait huit caractères de téléscripteur de 5 bits pour représenter chaque mot. Ainsi, par exemple, le mot binaire « 10001 10010 10100 01001 10001 11001 01010 10110 » était représenté sur le papier par ZDSLZWRF. Le contenu de tout mot de la mémoire pouvait aussi être modifié via le clavier du téléscripteur et écrit sur son imprimante. La machine fonctionnait en interne en binaire, mais pouvait réaliser les conversions de décimal en binaire et de binaire en décimal nécessaires à ses entrées et sorties, respectivement15 .

Aucun assembleur n'avait été créé pour le Mark I. Il fallait écrire et entrer les programmes sous forme binaire, représentés par huit caractères de 5 bits pour chaque mot de 40 bits ; les programmeurs étaient encouragés à mémoriser les codes Baudot modifiés pour se faciliter le travail. Les données étaient lues et écrites par un lecteur de ruban perforé contrôlé par un programme. Le Mark I n'avait pas de système d'interruptions matérielles ; le programme continuait après le début d'une lecture ou d'une écriture jusqu'à l'arrivée d'une autre instruction de lecture ou d'écriture. À ce moment, la machine attendait que la première opération se termine20 .

Le Mark I n'avait que quelques routines de base pour les entrées/sorties en guise de système d'exploitation au Mark I2. Comme dans la SSEM à partir de laquelle il avait été développé, et au contraire de la convention moderne, les nombres étaient enregistrés en machine avec le bit de poids fort à gauche ; ainsi, « 1 » était représenté sur 5 bits par « 10000 », au lieu de « 00001 », le standard actuel. Les nombres négatifs étaient représentés par le complément à deux, comme sur la plupart des ordinateurs actuels. Dans cette représentation, la valeur du bit de poids fort dénote le signe d'un nombre : les nombres positifs ont un 0 à cette position et les nombres négatifs un 120. Donc, l'intervalle des nombres que l'on pouvait enregistrer dans chaque mot de 40 bits allait de −239 à +239−1 (de −549 755 813 888 à +549 755 813 887).

Premiers programmes

Le premier programme réaliste exécuté sur le Mark I chercha des nombres premiers de Mersenne, début avril 194921, qui fonctionna sans erreur pendant neuf heures dans la nuit du 16 au 17 juin 1949. L'algorithme fut écrit par Max Newman, chef du département de mathématiques à l'université de Manchester ; Kilburn et Tootill écrivirent le programme. Turing écrivit plus tard une version optimisée du programme, surnommée le « Mersenne Express »16. Le Manchester Mark I continua son travail utile sur les mathématiques entre 1949 et 1950, y compris une recherche sur l'hypothèse de Riemann et des calculs d'optique22.

Suites du projet

Tootill fut prêté par l'université de Manchester à Ferranti pendant quatre mois à partir d'août 1949 pour continuer le travail sur la conception du Ferranti Mark I23 . Le Manchester Mark I fut démonté et mis au rebut vers la fin de 195024 et remplacé quelques mois plus tard par le premier Ferranti Mark I, le premier ordinateur généraliste commercialisé du monde2.

Entre 1946 et 1949, l'équipe qui travaillait sur le Mark I et son prédécesseur, la SSEM, comptait environ quatre personnes en moyenne. Pendant cette période, 34 brevets furent déposés, sur la base du travail de l'équipe, par le ministère de l'équipement des armées puis par son successeur, le National Research Development Corporation (« Agence nationale de développement de la recherche »)1. En juillet 1949, IBM invita Williams aux États-Unis, tous frais payés, pour discuter de la conception du Mark I. L'entreprise exploita par la suite sous licence plusieurs des idées brevetées développées pour la machine, y compris le tube de Williams, pour la conception de ses propres ordinateurs, les 701 et 70225. L'innovation du Manchester Mark I qui influença le plus ses successeurs fut peut-être son incorporation de registres d'index, pour lesquels le brevet fut déposés aux noms de Williams, Kilburn, Tootil et Newman1.

Kilburn et Newman conclurent que les ordinateurs seraient plus utilisés pour des applications scientifiques que dans le domaine des mathématiques pures, et décidèrent de développer une nouvelle machine qui inclurait une unité de calcul en virgule flottante. Le travail commença en 1951. Le résultat fut une machine, appelée Meg, ou la megacycle machine, qui exécuta son premier programme en mai 1954. Elle était plus petite et plus simple que le Mark I, et beaucoup plus rapide dans la résolution de problèmes mathématiques. Ferranti produisit une version de Meg dans laquelle les tubes de Williams étaient remplacés par des tores magnétiques. Ce design fut vendu sous le nom de Ferranti Mercury26.

Impact culturel

Le fonctionnement correct du Manchester Mark I et de son prédécesseur, la SSEM, fut largement couvert par la presse britannique, qui utilisa l'expression « cerveau électronique » pour décrire les machines27. Lord Louis Mountbatten avait déjà introduit ce terme dans un discours donné à l'Institution britannique des ingénieurs radio le 31 octobre 1946, discours dans lequel il avait prédit l'évolution des ordinateurs primitifs disponible à cette époque28. L'enthousiasme qui suivit l'annonce, en 1949, du premier ordinateur moderne provoqua une réaction à laquelle ses développeurs ne s'attendaient pas : Sir Geoffrey Jefferson, professeur de neurochirurgie à l'université de Manchester, à qui on avait demandé de prononcer le discours de remise de la médaille Lister en juin 1949, choisit comme sujet L'esprit de l'homme mécanique. Son objectif était de discréditer le projet Manchester29. Dans son discours, il dit :

« Tant qu'une machine ne pourra pas écrire un sonnet ou composer un concerto en raison des pensées et des émotions qu'elle ressent, et non par le tirage au sort de symboles, nous ne pourrons pas admettre qu'une machine égale un cerveau ― c'est-à-dire, non seulement l'écrire, mais aussi savoir qu'elle l'a écrit. Aucune machine ne peut éprouver le plaisir d'avoir réussi, de douleur quand ses tubes fondent, être affectée par la flatterie, être attristée par ses fautes, être charmée par le sexe, être en colère ou malheureuse quand elle n'obtient pas ce qu'elle veut29. »

Le Times publia un article sur le discours de Jefferson le jour suivant, ajoutant que Jefferson prédisait que « le jour ne viendrait jamais où les gracieuses pièces de la Royal Society seraient converties en garages pour héberger ces nouveaux venus ». Ceci fut interprété comme une attaque directe contre Newman, qui avait obtenu une bourse de la Society pour continuer le travail de l'équipe Manchester. En réponse, il écrivit un article pour le Times dans lequel il affirmait qu'il y avait une forte ressemblance entre la structure du Mark I et le cerveau humain30. L'article de Newman contenait un entretien avec Turing, qui ajoutait :

« Ce n'est qu'un avant-goût de ce qui viendra, et que l'ombre de ce qui sera. Nous avons besoin d'expérience avec la machine avant de vraiment connaître ses capacités. Il faudra peut-être des années avant que nous réalisions les nouvelles possibilités, mais je ne vois pas pourquoi elle devrait rester en-dehors d'un quelconque champ normalement couvert par l'intellect humain et, à terme, le concurrencer sur un pied d'égalité31. »

 

 

 

 

Portail de l’informatique Portail de l’informatique

 

Repost 0
31 juillet 2012 2 31 /07 /juillet /2012 02:17

 

Javascript.svg

 
Apparu en 1995
Auteur Brendan Eich
Développeur Netscape Communications Corporation
Dernière version stable 2.0[+/−]
Paradigme Multi-paradigme
Typage dynamique, faible
Normes ECMA-262
ISO/IEC 16262
Dialectes JavaScript, JScript, ECMAScript
Influencé par Self, Perl, C, Java
Implémentations SpiderMonkey, Rhino, KJS, JavaScriptCore
Site Web Mozilla

 

 

 

 

JavaScript est un langage de programmation de scripts principalement utilisé dans les pages web interactives. C'est un langage orienté objets à prototype, c'est-à-dire que les bases du langage et ses principales interfaces sont fournies par des objets qui ne sont pas des instances de classes, mais qui sont chacun équipés de constructeurs permettant de générer leurs propriétés, et notamment une propriété de prototypage qui permet d'en générer des objets héritiers personnalisés.

Le langage a été créé en 1995 par Brendan Eich pour le compte de Netscape Communications Corporation. Le langage actuellement à la version 1.7 est une implémentation du standard ECMA-262. La version 1.8 est en développement et intégrera des éléments du langage Python. La version 2.0 du langage est prévue pour intégrer la 4e version du standard ECMA.

Histoire 

Le langage a été créé en 1995 par Brendan Eich pour le compte de la Netscape Communications Corporation, qui s'est inspiré de nombreux langages, notamment de Java mais en simplifiant la syntaxe pour les débutants[1].

LiveScript et Mosaic Communications Corporation 

Brendan Eich a initialement développé un langage de script côté serveur, appelé LiveScript, pour renforcer l'offre commerciale de serveur HTTP de Mosaic Communications Corporation. La sortie de LiveScript intervient à l'époque où la NCSA force Mosaic Communications Corporation à changer de nom pour devenir Netscape Communications Corporation.

Netscape travaille alors au développement d'une version orientée client de LiveScript. Quelques jours avant sa sortie, Netscape change le nom de LiveScript pour JavaScript. Sun Microsystems et Netscape étaient partenaires, et la machine virtuelle Java de plus en plus populaire. Ce changement de nom servait les intérêts des deux sociétés.

Netscape et ECMAScript

En décembre 1995, Sun et Netscape annoncent[2] la sortie de JavaScript. En mars 1996, Netscape met en œuvre le moteur JavaScript dans son navigateur Web Netscape Navigator 2.0. Le succès de ce navigateur contribue à l'adoption rapide de JavaScript dans le développement web orienté client. Microsoft réagit alors en développant JScript, qu'il inclut ensuite dans Internet Explorer 3.0 en août 1996 pour la sortie de son navigateur.

Netscape soumet alors JavaScript à Ecma International pour standardisation. Les travaux débutent en novembre 1996, et se terminent en juin 1997 par l'adoption du nouveau standard ECMAScript. Les spécifications sont rédigées dans le document Standard ECMA-262.

Concepts

JavaScript est décrit comme un complément à Java dans un communiqué de presse[2] commun de Netscape et Sun Microsystems, daté du 4 décembre 1995. Cette initiative a contribué à créer auprès du public une certaine confusion entre les deux langages, proches syntaxiquement mais pas du tout dans leurs concepts fondamentaux, et qui perdure encore aujourd'hui.

Le propos de JavaScript est de manipuler de façon simple des objets, au sens informatique, fournis par une application hôte.

Le standard ECMAScript

La troisième édition d'ECMAScript, parue en 1999 correspond à la version 1.5 de JavaScript. Sa mise en œuvre par Microsoft est JScript. Adobe pour sa part, met en œuvre ces spécifications dans son langage ActionScript.

Mise en œuvre

SpiderMonkey est le nom de la mise en œuvre en langage C du langage JavaScript utilisé dans Gecko, le moteur de rendu développé par Mozilla. SpiderMonkey est disponible sous la licence « MPL/GPL/LGPL tri-license ».

Versions du langage

Les versions récentes du langage JavaScript ont pour origine les spécifications de la norme ECMA-262 définissant ECMAScript. JavaScript est un sur-ensemble d'ECMAScript développé par la fondation Mozilla et par Adobe lui ajoutant les fonctionnalités suivantes :

Version 1.5

Interpréteur basé sur les spécifications ECMA-262 3e édition.

Version 1.6

Toutes les fonctionnalités de la version 1.5 plus :

  • E4X
  • extension de l'objet Array
  • rapprochement des objets String et Array

pour en savoir plus (en)

Version 1.7

Toutes les fonctionnalités de la version 1.6 plus :

  • générateurs (instruction yield)
  • itérateurs
  • définition de tableaux par compréhension (var evens = [i for (i in range(0, 21)) if (i% 2 == 0)];)
  • définition de portée locale (instruction let)
  • assignation déstructurante (renvoi de valeurs multiples : [a,b] = maFonction())

pour en savoir (en)

Version 1.8 

Toutes les fonctionnalités de la version 1.7 plus :

  • extension des fermetures d'expressions
  • extension des expressions génératrices
  • plus d'extras pour les tableaux

pour en savoir (en)

Version 2.0 

Interpréteur basé sur les spécifications du langage ECMAScript Edition 4 (aujourd'hui obsolète et remplacée par ES3.5), un standard rédigé par l'ECMA dans le document ECMA-262 4e édition.

  • Mise en œuvre des spécifications ES4 en collaboration avec Adobe: projet Tamarin.

Utilisation

Dans une page Web

Du code JavaScript peut être intégré directement au sein des pages Web, pour y être exécuté sur le poste client. C'est alors le navigateur Web qui prend en charge l'exécution de ces programmes appelés scripts.

Généralement, JavaScript sert à contrôler les données saisies dans des formulaires HTML, ou à interagir avec le document HTML via l'interface Document Object Model, fournie par le navigateur (on parle alors parfois de HTML dynamique ou DHTML). Il est aussi utilisé pour réaliser des services dynamiques, parfois futiles, strictement cosmétiques ou à des fins ergonomiques.

JavaScript n'est pas limité à la manipulation de documents HTML et peut aussi servir à manipuler des documents SVG, XUL et autres dialectes XML .

Incompatibilités

Netscape et Microsoft (avec JScript dans Internet Explorer) ont développé leur propre variante de ce langage qui chacune supporte presque intégralement la norme ECMAScript mais possède des fonctionnalités supplémentaires et incompatibles, rarement utilisées dans le cadre de la programmation de pages web. Pourtant les scripts JavaScript sont souvent la source de difficultés. Le plus souvent, elles sont dues non à des problèmes de portabilité du langage (les différentes mises en œuvre respectant assez bien la norme ECMAScript), mais à la prise en charge des différentes versions des modèles d'objets (DOM) fournis par les navigateurs.

Face à ce problème on utilise souvent une construction du type :

 if (monObjet.methode) { monObjet.methode(); } 

Il est toutefois préférable d'utiliser une comparaison sur le type :

 if (typeof(monObjet.methode) !== 'undefined') { monObjet.methode(); } 

Ou mieux encore :

 if (typeof(monObjet.methode) === 'function') { monObjet.methode(); } 

On vérifie ainsi que monObjet a bien une mise en œuvre de methode que l'on peut alors utiliser. Le plus souvent, si un navigateur ne gère pas la methode de monObjet, il gère une méthode comparable methode2, et on peut alors adapter le code JavaScript au navigateur qui l'exécute :

 if (monObjet.methode) { monObjet.methode(); } else if (monObjet.methode2) { monObjet.methode2(); } 

Une autre méthode consiste à vérifier, côté serveur, le navigateur utilisé par le client et d'envoyer le code correspondant.

AJAX

JavaScript est un des composants essentiels de la technique AJAX (Asynchronous Javascript And XML). La plupart des applications AJAX utilisent l'objet XMLHTTPRequest (XHR) pour envoyer une requête à un script serveur, et parser dynamiquement les résultats de ce dernier via DOM. Internet Explorer est le premier à proposer ce composant, sous forme d'un ActiveX, et ce dès la fin des années 90. Ce n'est qu'en 2002 que les développeurs commencent massivement à l'utiliser. Les versions d'Internet Explorer antérieures à la 7 ne géraient pas l'objet XHR tel que décrit dans les standards du W3C mais proposaient un contrôle ActiveX équivalent (à partir de la version 5), ce qui impose des fourches dans le code, tel que montré ci-dessus.

AJAX est une des technologies phares du mouvement Web 2.0 qui définit les interfaces riches permettant à l'internaute une plus grande interactivité avec la page Web.

JSON

JSON (JavaScript Object Notation) est un format utilisant la notation des objets JavaScript pour transmettre de l'information structurée, d'une façon plus compacte et plus proche des langages de programmation, que XML.

Malgré l'existence du DOM et l'introduction récente de E4X (voir ci-dessous) dans la spécification du langage JavaScript, JSON reste le moyen le plus simple d'accéder à des données, puisque chaque flux JSON n'est rien d'autre qu'un objet JavaScript sérialisé. De plus, malgré son lien historique (et technique) avec JavaScript, JSON reste un format de données structurées, et peut être utilisé facilement par tous les langages de programmation.

Toutes ces raisons sont probablement la cause de l'existence de l'acronyme AJAJ, en marge d'AJAX, où le format JSON est utilisé à la place du format XML, pour des résultats identiques.

Internet Explorer 8 intègre un support natif du format JSON[3].

Autres utilisations 

JavaScript peut également être utilisé comme langage de programmation sur un serveur HTTP. Initialement, il était proposé sur les serveurs de Netscape, par la suite distribués par Sun Microsystems sous les noms iPlanet et Sun ONE, mais JScript peut aussi être utilisé sur les serveurs Internet Information Services de Microsoft. JScript peut d'ailleurs servir pour scripter une plate-forme Microsoft Windows via Windows Scripting Host (WSH).

On peut encore citer ActionScript, utilisé dans Macromedia Flash qui est aussi une mise en œuvre d'ECMAScript. Il permet de manipuler tous les éléments de l'animation, considérés comme des objets.

JavaScript est enfin utilisé dans la plate-forme de développement Mozilla, sur laquelle sont basés plusieurs logiciels comme des navigateurs Web, pour des tâches relatives à l'interface utilisateur et de communication interne (Exemple : les extensions de Firefox et Thunderbird sont installées à base de fichiers XPI utilisant le JavaScript. Voir aussi Prefs.js).
Depuis 2004, l'objet "js" de l'environnement de programmation graphique Max/MSP, permet d'ouvrir une fenêtre pour programmer en JavaScript, au sein même d'un programme Max/MSP.

JavaScript est aussi utilisé dans un contenu BIFS pour l'exploitation des événements. Pour cela la spécification BIFS fournit un nœud Script pour incorporer de l'ECMAScript.

Javascript peut être utilisé pour scripter les applications Adobe (Photoshop, Illustrator...), ce qui permet d'avoir des scripts indépendants de la plate-forme (Mac/Windows).

La suite bureautique OpenOffice.org permet d'utiliser JavaScript comme langage de macros (Linux/Mac/Solaris/Windows).

JavaScript est aussi utilisable en shell[4] ou avec les gadgets Vista.

Particularités du langage

Portée des variables

 // Portée dans une fonction function testA(nombre) { i = nombre; // affecte i globalement return i*2; } function testB(nombre) { var i = nombre; // affecte i localement return i*2; } var i = 1; alert(testA(2)); // affiche 4 alert(i); // affiche 2 car testA a modifié i globalement alert(testB(3)); // affiche 6 alert(i); // affiche 2 car testB a modifié i localement 
 <br/> // Portée dans une boucle var i = -1; for (var i = 1; i < 10; i++) {} alert(i); // affiche 10, étrangement n'affiche pas -1 car le i du for est accessible après la boucle // rien pour donner confiance en JavaScript for (i = 1; i < 10; i++) {} alert(i); // affiche 10 

Fonctions anonymes

Une fonction anonyme est, comme son nom l'indique, une fonction qui n'a pas de nom.

 //Exemple 1 var maFonction = function(message) { alert(message); } // affiche: ceci est un test maFonction('ceci est un test'); 
 <!-- Exemple 2 --> <html> <body onload="setTimeout( function() {   alert( 'chargement de la page terminé il y a une seconde et demie' )   }, 1500 );"> </body> </html> 

Fermetures

Les fermetures sont une caractéristique aussi puissante que méconnue du langage. Il s'agit de la possibilité, pour une expression, d'accéder à des variables qui ne sont plus à sa portée.

 //Exemple de fermeture function ajouteur(nombre) { function ajoute(valeur) { return valeur + nombre; } return ajoute; } var ajoute10 = ajouteur(10); ajoute10(1); // retourne 11 

Dans l'exemple ci-dessus, la fonction interne ajoute10 a toujours accès au paramètre effectif nombre malgré le fait que l'appel à la fonction ajouteur soit terminé.

Prototypes

Un prototype est un objet JavaScript qui est utilisé lors d'un échec de résolution d'un nom sur son objet parent. Ce mécanisme est un type d'héritage : l'héritage par prototype.

 function MonPrototype() { this.a = 1; this.b = function() { return 'prototype'; } this.e = 3; } function MaClasse() { this.c = 2; this.d = function() { return 'classe'; } this.e = 4; } MaClasse.prototype = new MonPrototype(); monObjet = new MaClasse(); monObjet.a; // 1 monObjet.b(); // 'prototype' monObjet.c; // 2 monObjet.d(); // 'classe' monObjet.e; // 4 

Séparation des instructions

En C, chaque instruction se termine par un point-virgule. Cette pratique a fait du point-virgule une obligation dans de nombreux langages inspirés de la syntaxe du C.

JavaScript est plus souple, permettant à une fin de ligne de marquer implicitement la fin d'une instruction. Le but est de faciliter l'usage du langage aux personnes inexpérimentées en programmation informatique. Mais cette souplesse introduit des effets inattendus[5] :

 return true; 

Le parseur JavaScript comprend cela comme deux instructions :

 return; true; 

alors que le programmeur pensait plus probablement à la seule instruction :

 return true; 

Les ouvrages de programmation avancés en JavaScript mettent en garde contre les effets inattendus de la déduction automatique de fin d'instruction et conseillent d'écrire un point-virgule à la fin de chaque instruction, ce qui n'empêche pas les surprises lorsqu'on oublie le point-virgule.

E4X

Les versions récentes de la mise en œuvre du langage JavaScript de SpiderMonkey supportent l'E4X. Il s'agit d'un support natif de XML ainsi que d'un support natif d'une syntaxe d'accès aux données XML (sorte de XPath)

Exemple :

 var xml = <menu id="file" value="File"> <popup> <menuitem value="New" onclick="CreateNewDoc()" /> <menuitem value="Open" onclick="OpenDoc()" /> <menuitem value="Close" onclick="CloseDoc()" /> </popup> </menu> 

Exemple d'accès aux données :

 xml.popup.menuitem.(@value == 'New').@onclick 

L'exemple ci-dessus récupère la fonction correspondant à l'action "New". Le résultat de l'évaluation est "CreateNewDoc()".

Autre exemple :

 var item = 2; xml.popup.menuitem[item].@value 


Le résultat de l'évaluation est "Close".

 

 

.


Repost 0
13 juin 2012 3 13 /06 /juin /2012 19:54

Hacker (sécurité informatique)


Un hacker est une personne qui montre une véritable passion pour la compréhension du fonctionnement intime des systèmes, ordinateurs et réseaux informatiques en particulier1.

En sécurité informatique, un hacker est un spécialiste dans la maîtrise de la sécurité informatique et donc des moyens de déjouer cette sécurité. Certains d'entre eux utilisent ce savoir-faire dans un cadre légal et d'autres l'utilisent hors-la-loi.

Hacker, dans sa signification relayée par les médias de masse, se réfère aux chapeaux noirs (pirate informatique). Afin de lever l'ambiguïté sur le terme hacker, cracker est souvent utilisé pour désigner les black hats, le démarquant ainsi de la culture académique des hackers telle que définie par Eric Raymond2.

 

 

 

 

Terminologie

Le jargon informatique classe les hackers en plusieurs catégories en fonction de leurs objectifs, de leur compétence et de la légalité de leurs actes. Ce vocabulaire fait référence aux films de western, où le héros porte un chapeau blanc, et les méchants portent des chapeaux noirs.

  • Les chapeaux blancs ou White hat : professionnels de la sécurité informatique (consultants en sécurité, administrateurs réseaux...) effectuant des tests d'intrusions en accord avec leurs clients et la législation en vigueur afin de qualifier le niveau de sécurité de systèmes. Certains hackers se considèrent comme white hat alors qu'ils transgressent les lois, leur but étant de prévenir les responsables des failles de leurs systèmes.
  • Les chapeaux noirs ou Black hat : créateurs de virus, cyber-espions, cyber-terroristes ou cyber-escrocs, agissant la plupart du temps hors-la-loi dans le but soit de nuire, de faire du profit ou d'obtenir des informations. Ces hackers n'ont pas la même éthique que les White hats et sont souvent malveillants. Les plus malveillants sont alors appelés crashers.
  • Les chapeaux gris ou Grey hat : s'ils n'hésitent pas à pénétrer dans les systèmes sans y être autorisés, ils n'ont pas de mauvaises intentions. C'est souvent l'« exploit informatique » qui les motive, une façon de faire la preuve de leur agilité. Cette catégorie recouvre le large panel de personnes se situant entre le black hat et le white hat.
  • Les script kiddies ou Lamer, littéralement « gamins qui utilisent des scripts » : sans grande compétence, ceux-ci piratent surtout par désir de se faire remarquer, en utilisant des programmes codés par d'autres. Ces personnes ne sont pas à proprement parler des hackers, mais elles se considèrent généralement comme tels.
  • les hacktivistes : agissant afin de défendre une cause, il n'hésitent pas à transgresser la loi pour attaquer des organisations afin de les paralyser ou d'obtenir des informations.

Il serait réducteur de généraliser le cas et d'en déduire que les white hats sont les gentils et les black hats sont les méchants. En effet, de nombreux débats se font entre les deux camps et aucun camp n'a réussi à prouver que le sien était la voie à suivre. De nombreux white hats ne servent que leurs intérêts alors que d'autres black hats protègent ceux des autres. C'est d'ailleurs un sujet de troll récurrent.

Associations de hackers célèbres

Les principaux groupes de hackers sont :

  • Chaos Computer Club (groupe allemand, le plus grand groupe de hackers européen, créé en 1981). Attention à ne pas confondre avec son homonyme français.
  • The Cult of the Dead Cow (créateur de Back Orifice 2000, un logiciel de prise de contrôle à distance)
  • 2600 (groupe hacker new-yorkais ; la fréquence du sifflet du Captain Crunch était de 2600 Hz) ; et la branche 2600 pour la France.
  • Hacking For Girliez (groupe de hackers féminins) ; responsable de nombreux piratages de sites comme ceux de la NASA, du New York Times ou de la firme Motorola.

Manifestations de hackers

Depuis la fin des années 1980, certains groupes organisent des « manifestations » régulières, comme :

D'autres rassemblements changent de nom à chaque fois, comme ceux organisés initialement par ce groupe des Pays-Bas uni autour du magazine Hack-Tic :

Hackers célèbres

  • Daniel J. Bernstein : auteur de qmail et djbdns, également mathématicien et cryptographe.
  • Bill Landreth : auteur du best-seller Le Pirate de l'Informatique : Guide de la sécurité informatique en 1985.
  • Kevin Mitnick : s'infiltra dans certains des plus grands sites internet sécurisés, comme celui du Pentagone.
  • Steve Wozniak : le cofondateur d'Apple a commencé par travailler sur des outils destinés au phreaking.
  • Islam Brahimi : connu pour avoir accédé illégalement à plusieurs ordinateurs reliés à Internet en créant l'un des plus grands reseaux Botnet de 500 000 ordinateurs inféctés.
  • H.D Moore3 : créateur de Metasploit
  • Jon Ellch : plus connu sous le pseudonyme de Johnny Cash, il a particulièrement fait parler de lui en 2006 en démontrant avec son acolyte David Maynor l'existence de vulnérabilités dans les pilotes Wi-Fi, dont ceux d'Apple.
  • Joanna Rutkowska : elle s'est fait connaitre de la communauté en 2006 grâce à la fameuse Blue Pill, un rootkit exploitant la technologie de virtualisation Pacifica d'AMD pour prendre le contrôle de Windows Vista.
  • Gary McKinnon : accusé d'avoir pénétré dans 97 ordinateurs appartenant à l'US Army et à la NASA.
  • Kevin Poulsen : connu sous le pseudonyme Dark Dante, il fut le premier hacker à être accusé d'espionnage aux États-Unis.
  • Jon Lech Johansen : décryptage du contenu d'un DVD chiffré.
  • George Hotz : plus connu sous le pseudonyme de GeoHot, il a craqué l'iPhone (2007) et la PlayStation 3 (2010).
  • Julian Assange : ancien hacker, et principal porte-parole de WikiLeaks
  • Harald Welte : pour son travail d'ingénierie inverse sur le protocole et les équipements GSM
  • Karsten Nohl : pour son travail d'ingénierie inverse sur le chiffrement du protocole GSM et Mifare
  • Anonymous : groupe de personnes combattant pour la liberté d'internet, le partage, etc… Ils sont contre la politique actuelle pour la plupart. Pour eux, elle n'a pas le droit de censurer quoi que ce soit sur internet, car il est fondé sur le partage et l'information. Ils ont déclaré une cyberguerre contre le gouvernement américain le 19 janvier dernier. Cette guerre est aussi appelée World War Web, à cause des origines diverses des milliers de hackers qui y participent (Corée, Japon, France, Canada, États-Unis…). Le nombre des membres d'anonymous (qui n'est pas formé que de hackers, mais aussi de manifestants par exemple) est estimé à quelques millions au total, mais ne cesse de s'accroître. Ils sont connus pour avoir piraté des sites comme celui de Sony, ou celui du FBI, du Palais de l'Élysée, ou même de la NASA. Ils ont mis au point dès leurs débuts un logiciel de DDoS appelé LOIC (Low Orbit Ion Canon), développé en C[réf. nécessaire]. (Il est à noter que les Anonymous ne sont pas une organisation structurée, mais plutôt une image donnée à (et que se donnent) un certain nombre de hackers4.)

Publications francophones en sécurité informatique

Voir aussi les publications traitant de hacking et la catégorie "Publication en sécurité de l'information" des articles Wikipédia.

Productions audiovisuelles

  • Le 15avril2011, France 4 diffusait Pirat@ge, un documentaire qui retrace l’histoire d’Internet grâce aux témoignages de ceux qui l’ont construit, les hackers. Y sont présents Andy Müller-Maguhn du Chaos Computer Club, John Drapper alias Captain Crunch, et Daniel Domscheit-Berg d’OpenLeaks, pour n'en citer que quelques-uns5.

 

 

 

Portail de la sécurité informatique Portail de la sécurité informatique

 

 

.

Repost 0
13 juin 2012 3 13 /06 /juin /2012 19:51

General MIDI


 

General MIDI est une norme visant à améliorer la compatibilité des instruments de musique électroniques compatibles avec la norme MIDI. Elle établit entre autres une numérotation des timbres que peut jouer l'instrument. Il est donc possible d'échanger des fichiers General MIDI sans connaître le matériel dont dispose le destinataire.





General MIDI niveau 1


Historique

En septembre 1991, la MIDI Manufacturers Association (ou MMA) et le Japan MIDI Standards Committee (JMSC) ont adapté la norme « General MIDI niveau 1 », aussi connue sous l'acronyme GM1. Elle visait à obtenir une compatibilité minimale entre les instruments MIDI.

Contraintes

Un instrument GM1 (synthétiseur, expandeur, carte son...) doit répondre aux critères suivants:

  • 24 voies de polyphonie pour la mélodie et les percussions, ou 16 voies pour la mélodie et 8 pour les percussions. Toutes ces voies doivent être sensibles à la vélocité.
  • 16 canaux MIDI pouvant chacun jouer un instrument (timbre, échantillon...) différent. Les percussions doivent être sur le canal 10
  • 16 instruments doivent pouvoir être joués simultanément. Au moins 128 instruments et 47 percussions doivent être disponibles et leur numérotation est normalisée.
  • Les messages de contrôle continus 1, 7, 10, 11, 64, 121 et 123, les RPN 0, 1 et 2, la pression et le pitch bend doivent être gérés.
  • Certains messages système doivent être interprétés, parmi lesquels ceux d'accordage et les messages système GM1,

Numérotation des instruments

La correspondance entre numéros et instruments est strictement définie dans la norme GM1.

classement par familles d'instruments

Le tableau suivant donne le classement par familles d'instruments :

 

 

Programme Famille
1-8 Piano
9-16 Percussions chromatiques
17-24 Orgues
25-32 Guitares
33-40 Basses
41-48 Cordes
49-56 Orchestre
57-64 Cuivres
65-72 Instruments à anches
73-80 flûtes
81-88 Synthétiseur solo
89-96 Nappes de synthétiseur
97-104 Effets de synthétiseur
105-112 Instruments ethniques
113-120 Percussions
121-128 Effets sonores

Liste complète des instruments

Pianos
Percussions chromatiques
Orgues (Organ)
Guitares
Basses
Cordes & orchestre
Ensembles
Cuivres (Brass)
Instruments à anches
Autres instruments à vent
Synthé - Solo
Synthé - Ensembles
Synthé - Effets
Ethnies
Percussions
Effets sonores (bruitages)

On peut écouter ces sons sur le site http://www.buzzwood.com/midtest.htm

Liste des percussions

General MIDI niveau 2

Historique

General MIDI 2 a été normalisé en 1999. C'est un groupe d'extensions de GM1 augmentant le nombre de sons et de contrôles disponibles. Tous les appareils compatibles GM2 sont compatibles GM11.

Contraintes

Un instrument GM2 doit répondre aux contraintes suivantes:

  • disposer de 16 canaux MIDI, 16 instruments mélodiques simultanés (tous canaux), 2 kits de percussion simultanés (canaux 10 et 11)
  • répondre à de nombreux messages de contrôle, parmi lesquels: sélection de banque, modulation, temps de portamento, sostuento, temps d'attaque, réglages de vibrato, réglages de chorus, réglages de réverbération,
  • disposer des instruments et des kits de percussion GM2

General MIDI lite

Historique

General MIDI Lite est une norme publiée en 2001. Elle cible des instruments n'ayant pas les capacités techniques pour répondre à toutes les contraintes de la norme GM1.

Contraintes

Un instrument GM Lite doit répondre aux contraintes suivantes:

  • polyphonie de 16 notes
  • jusqu'à 15 instruments simultanés
  • un kit de percussions (canal 10)
  • compatibilité avec quelques types de messages, parmi lesquels: modulation, volume, balance, expression, pitch bend.
  • disposer des instruments et percussions GM1.

 

 

  • Portail de la musique Portail de la musique
  • Portail de l’informatique Portail de l’informatique

 

.

Repost 0
22 avril 2012 7 22 /04 /avril /2012 07:47

Plan multilingue complémentaire (PMC, 10000 à 1FFFF) 

 

 


Points de code Nom officiel du bloc Commentaires
Début Fin
10000 1007F Syllabaire linéaire B ou syllabaire mycénien
10080 100FF Idéogrammes du linéaire B
10100 1013F Nombres égéens
10300 1032F Alphabet italique
10330 1034F Gotique voir langue Gotique
10380 1039F Ougaritique voir langue Ougaritique
10400 1044F Déséret
10450 1047F Shavien
10480 104AF Osmanya
10800 1083F Syllabaire chypriote
1D000 1D0FF Symboles musicaux byzantins
1D100 1D1FF Symboles musicaux occidentaux
1D300 1D35F Symboles du Classique du mystère suprême
1D400 1D7FF Symboles mathématiques alphanumériques
1FFFE 1FFFF non-caractères

Plan idéographique complémentaire (PIC, 20000 à 2FFFF) 


Points de code Nom officiel du bloc Commentaires
Début Fin
20000 2A6D6 Supplément B aux idéogrammes unifiés CJC
2F800 2FA1F Supplément aux idéogrammes de compatibilité CJC
2FFFE 2FFFF non-caractères

Plans complémentaires réservés (30000 à DFFFF) 


Points de code Nom officiel du bloc Commentaires
Début Fin
3FFFE 3FFFF non-caractères
4FFFE 4FFFF non-caractères
5FFFE 5FFFF non-caractères
6FFFE 6FFFF non-caractères
7FFFE 7FFFF non-caractères
8FFFE 8FFFF non-caractères
9FFFE 9FFFF non-caractères
AFFFE AFFFF non-caractères
BFFFE BFFFF non-caractères
CFFFE CFFFF non-caractères
DFFFE DFFFF non-caractères

Plan complémentaire spécialisé (PCS, E0000 à EFFFF) 


Points de code Nom officiel du bloc Commentaires
Début Fin
E0000 E007F Étiquettes
E0100 E01EF Supplément de sélecteurs de variante
EFFFE EFFFF non-caractères

Plans complémentaires à usage privé (F0000 à 10FFFF)


Points de code Nom officiel du bloc Commentaires
Début Fin
☒F0000 FFFFD Zone supplémentaire A à usage privé
FFFFE FFFFF non-caractères
☒100000 10FFFD Zone supplémentaire B à usage privé
10FFFE 10FFFF non-caractères

 

 

 

 

Les zones à usage privé indiquées par le symbole ☒ ne contiennent pas les mêmes œils d’une police à l’autre et doivent donc être évités pour le codage de textes destinés aux échanges entre systèmes hétérogènes. Toutefois ces points de codes à usage privé sont valides et peuvent être utilisés dans tout traitement automatisé conforme aux normes Unicode et ISO 10646, y compris entre systèmes différents s’il existe un accord mutuel privé concernant leur usage.

En l’absence d’accord entre les deux parties, des systèmes utilisant ces caractères peuvent rejeter les textes les contenant, car les traitements qu’ils leur font subir pourraient ne pas fonctionner correctement ou causer des problèmes de sécurité; les autres systèmes qui n’attribuent aucune fonction spéciale à ces caractères doivent en revanche les accepter comme valides et les conserver comme partie intégrante des textes, comme s’il s’agissait de symboles graphiques, même s’ils ne savent pas les afficher correctement.

Les non-caractères listés sont des points de code valides, mais ils ne sont pas (et ne seront jamais) assignés à des caractères normalisés. Leur usage dans le codage de textes transmis entre systèmes (même si identiques) est interdit, car il est impossible de les rendre compatibles avec les formes de transformation universelles normalisées (dont UTF-8, UTF-16, UTF-32) les schémas de codage correspondants, et les autres codages normalisés compatibles avec Unicode et ISO 10646 (BOCU-1, SCSU, différentes versions de la norme chinoise GB18030, etc.). Toutefois certains systèmes les génèrent et les utilisent localement, mais pour un traitement strictement interne destiné à faciliter l’implémentation des algorithmes de traitement de textes utilisant les autres caractères normalisés.

Parmi ces derniers non-caractères figurent les points de code valides mais réservés aux demi-zones (privées ou non). Ces points de code ne peuvent pas être utilisés individuellement pour coder un caractère. Ils servent uniquement pour la forme de transformation universelle UTF-16 (et les schémas de codage correspondants) pour représenter sur deux codets (à 16 bits chacun) des points de code valides dans un des 16 plans complémentaires (certaines combinaisons de codets correspondent à des caractères valides de ces plans, standards ou privés, d’autres combinaisons peuvent ne représenter aucun caractère valide car elles correspondraient à des non-caractères de ces plans complémentaires, et sont donc interdites dans les textes conformes à la norme).

Les autres zones libres (non assignées à un bloc nommé normalisé, ou les points de code laissés libres et réservés dans les blocs nommés existants) sont réservés pour un usage ultérieur dans des versions futures d’Unicode et ISO 10646, mais sont valides. Tout système traitant des textes contenant ces points de code réservés doivent les accepter sans les filtrer. Unicode définit des propriétés par défaut pour les hypothétiques caractères correspondants, afin de préserver la compatibilité des systèmes (conformes à la norme Unicode) avec les futurs textes conformes qui les contiendraient. Aucune application conforme ne doit leur assigner un caractère ou une sémantique spéciale (les zones privées sont destinées à cet usage).

 

 

 

Repost 0
21 avril 2012 6 21 /04 /avril /2012 07:45

GB 18030 

 

 


Il s’agit d’une transformation de l’Unicode qui n’est pas définie par le Consortium Unicode, mais par l’administration de normalisation en Chine, où son support est obligatoire dans les applications. Historiquement c’était un jeu de caractères codé, qui a été étendu pour supporter l’intégralité du répertoire UCS par une transformation algorithmique complétant une large table de mappage d’un code à l’autre.

 

 

Les polices de caractères Unicode 


Affirmer qu’Unicode code des caractères revient à affirmer qu’il attribue un numéro à des symboles abstraits, selon un principe de codage logique. Unicode ne code en revanche pas les représentations graphiques des caractères, les glyphes. Il n’y a donc pas une bijection entre la représentation du caractère et son numéro, puisque toutes les variantes graphiques de style sont unifiées.

De plus, contrairement à une police ASCII ou latin-1 classique, la sélection d’un glyphe par un code n’est pas unique et est souvent contextuelle, et peut aussi afficher le même glyphe pour des codes différents. Ainsi, le caractère français « é » peut-il être décrit de deux manières : soit en utilisant directement le numéro correspondant au « é », soit en faisant suivre le numéro du « e » par celui de l’accent aigu sans chasse. Quelle que soit l’option choisie, le même glyphe sera affiché. On dira du premier caractère qu’il est précomposé, du second que c’est une composition (deux caractères forment un seul glyphe composé des deux). Ceci est autorisé et même hautement recommandé car les différentes formes de codage sont classées par Unicode comme « canoniquement équivalentes », ce qui signifie que deux formes de codage équivalentes devraient être traitées de façon identique.

De nombreux caractères composites sont dans ce cas et peuvent être codés de ces deux manières (ou plus, certains caractères composés pouvant être décomposés de plusieurs façons, notamment quand ils comportent plusieurs signes diacritiques). Le plus souvent, le caractère précomposé est préférable pour le codage du texte, si celui-ci existe (c’est le cas pour le grec polytonique, par exemple, lequel, codé en décomposition, peut ne pas être satisfaisant graphiquement : selon les polices de caractères, les différents constituants du glyphe étant parfois mal disposés et peu lisibles). Toutefois, tous les caractères composites ne disposent pas d’un point de code unique pour leur forme précomposée.

De même, certains systèmes d’écriture, comme la devânagarî ou les caractères arabes, nécessitent un traitement complexe des ligatures : les graphèmes changent en effet de forme en fonction de leur position et/ou par rapport à leurs voisines (voir Variante contextuelle et Lettre conjointe). La sélection du glyphe correct à utiliser nécessite un traitement permettant de déterminer la forme contextuelle à sélectionner dans la police, alors même que toutes les formes contextuelles sont codées de façon identique en Unicode.

Pour ces raisons, la police Unicode doit être utilisée très prudemment. Avoir une police qui représente un certain nombre ou toutes les représentations graphiques que l’on peut obtenir avec Unicode n’est pas suffisant, il faut en plus que le système d’affichage possède les mécanismes de représentation idoines (le moteur de rendu) capable de gérer les ligatures, variantes contextuelles et formes conjointes de certaines écritures. Au contraire, une police qui ne représente que certains caractères mais qui sait comment les afficher mérite mieux le terme de « police Unicode ». Enfin, il existe des contraintes techniques dans les formats de polices de caractère, qui les empêche de supporter la totalité du répertoire et, en pratique, il est en 2009 impossible de trouver une police de caractères unique supportant tout le répertoire.

Une police de caractères Unicode est donc seulement une police permettant d’afficher directement un texte codé selon toutes les formes autorisées par Unicode, et permettant de supporter un sous-ensemble cohérent adapté à une ou plusieurs langues pour supporter une ou plusieurs écritures. Aucune police de caractère Unicode ne peut « fonctionner » seule, et le support complet de l’écriture nécessite un support de celles-ci dans un moteur de rendu, capable de détecter les formes de codage équivalentes, rechercher les formes contextuelles dans le texte et sélectionner les différents glyphes d’une police codée avec Unicode, en s’aidant au besoin de tables de correspondances incluses dans la police elle-même.

 

 

Détails techniques 


Bibliothèques logicielles


La bibliothèque multi plate-forme ICU permet de manipuler des données unicodées. Un support d’Unicode spécifique à certaines plates-formes (non compatible quant au code-source) est également fourni par les systèmes modernes (Java, MFC, GNU/Linux).

Les types à utiliser pour stocker des variables Unicode, sont les suivants :

 

 

 

 

Types compatibles avec Unicode dans les langages de programmation
Langage de programmation Type pour un seul caractère Type pour tout texte
C char[4]a ou wchar_t[2]b char[] ou wchar_t[]
C++ char[4]a ou wchar_t[2]a char[] ou wchar_t[] ou std::string ou std::wstring
Java char[2] ou intc char[] ou String
Bibliothèque ICU (pour C/C++ ou Java) UChar UChar[] ou String, UnicodeString
JavaScript ou ECMAScript chard string
C# ou J# char string
Delphi char[4]a ou widechar[2] stringa ou widestring
Python unicode

Notes 


  1. a, b, c, d et e En UTF-8
  2. On notera toutefois que le type wchar_t du langage C ne permet pas toujours de coder tous les caractères Unicode, car la norme de ce langage ne prévoit pas de nombre minimum suffisante pour ce type standard. Cependant de nombreux compilateurs du langage définissent wchar_t sur 32 bits (voire 64 bits sur les environnements manipulant les entiers standards sur 64 bits), ce qui suffit pour stocker n’importe quel point de code Unicode normalisé. Mais d’autres compilateurs représentent wchar_t sur 16 bits (notamment sous Windows en environnement 16 ou 32 bits), voire sur 8 bits seulement (notamment dans les environnements embarqués ne disposant pas d’un système d’exploitation d’usage général) car wchar_t peut utiliser la même représentation que le type char qui compte un minimum de 8 bits.
  3. De manière similaire au C et au C++, le langage Java dispose de type unitaire permettant de coder 16 bits, mais ne permettant pas de coder un seul point de code d’une valeur quelconque (le type natif char est un entier positif sur 16 bits seulement). Pour manipuler les caractères normalisés hors du premier plan, il faut utiliser une paire de codets, chacun contenant une valeur égale aux deux codets définis par la forme UTF-16. Aussi les types d’objets String ou char[2] sont les plus appropriés pour représenter un caractère Unicode. Depuis Java 1.4.1, la bibliothèque standard fournit un support complet d’Unicode grâce au type natif int (qui est un entier défini sur 32 bits) et aux méthodes statiques de la classe standard Character (cependant un objet instancié de ce type Character ne permet pas, tout comme le type natif char, de stocker n’importe quel point de code).
  4. JavaScript comporte diverses implémentations non normalisées dont certaines plus anciennes ne supportent pas plus de 16 bits par caractère, et parfois seulement 8 bits. Toutefois la norme ECMAScript de ce langage définit une classe utilitaire Character sur 32 bits (en fait basée sur la classe Number) devant supporter tous les points de code des 17 plans normalisés, tandis que les chaines de caractères utilise des caractères codés obligatoirement sur 16 bits (mais sans restriction renforçant l’appariement des unités de code UTF-16, les chaînes ECMAScript de type String n’étant pas restreintes au seul codage UTF-16 mais étant des vecteurs de constantes entières codées sur 16 bits sans restriction, afin d’assurer l’interopérabilité avec Java et d’autres langages qui eux non plus ne renforcent pas les restrictions de conformité UTF-16 dans leurs types natifs de données). Ces deux langages ne supportent pas de typage explicite des variables, le type étant défini dynamiquement par les valeurs qu’on leur assigne (aussi, plusieurs représentations internes sont possibles, leurs différences étant normalement transparentes pour le programmeur).

Unicode souffre toutefois encore d’un faible support des expressions rationnelles par certains logiciels, même si des bibliothèques comme ICU et Java peuvent les supporter. Un tel support n’a pas encore été standardisé pour ECMAScript et n’est fourni qu’avec l’aide de librairies créées avec le langage ou des interfaces d’interopérabilité avec d’autres systèmes (notamment avec CORBA, COM) ou langages (notamment C++ et Java).

 

 

Partitionnement 


Le partitionnement à jour peut être trouvé sur le site officiel d’Unicode. Cependant, vu le rôle important d’Unicode, (ISO 10646) on décrira ici les principaux blocs de caractères. Les noms français sont les noms officiels de l’ISO/CEI 10646, la norme internationale bilingue qui reprend les mêmes caractères qu’Unicode. Ils sont aussi officiels que les noms anglais.

L'ancienne norme Unicode 1.0 est obsolète et incompatible avec la norme ISO 10646 et la norme Unicode 1.1 et toutes ses versions ultérieures ; la principale incompatibilité est celle des blocs de caractères Hangul utilisés pour l’écriture de la langue coréenne qui ont changé de position et dont les anciens points de code ont depuis été assignés à d’autres blocs. La table ci-dessous est compatible avec ISO 10646 (toutes versions) et Unicode 1.1 (ou ultérieur).

Note : La casse des noms de bloc n’est pas normative. « Latin de base » est donc équivalent à « LATIN DE BASE ».

 

 

Plan multilingue de base (PMB, 0000 à FFFF) 


Points de code Nom officiel du bloc Commentaires
Début Fin
0000 007F Latin de base voir norme ISO 646, code ASCII
0080 009F Non-utilisé voir plage non-utilisé norme ISO 8859 et ISO 8859-1
00A0 00FF Supplément Latin-1 voir norme ISO 8859, code ISO 8859-1
0100 017F Latin étendu A
0180 024F Latin étendu B
0250 02AF Alphabet phonétique international (API) Alphabet phonétique international
02B0 02FF Lettres modificatives avec chasse
0300 036F Diacritiques voir Diacritique
0370 03FF Grec et copte
0400 04FF Cyrillique voir Alphabet cyrillique
0500 052F Supplément cyrillique voir Alphabet cyrillique
0530 058F Arménien voir langue Arménien
0590 05FF Hébreu voir Alphabet hébreu
0600 06FF Arabe voir alphabet arabe
0700 074F Syriaque voir langue Syriaque
0780 07BF Thâna
0900 097F Dévanâgarî
0980 09FF Bengali voir langue indienne Bengalî
0A00 0A7F Gourmoukhî
0A80 0AFF Goudjerate
0B00 0B7F Oriya voir langue indienne Oriya
0B80 0BFF Tamoul voir langue indienne Tamoul
0C00 0C7F Télougou voir langue indienne Télougou
0C80 0CFF Kannara voir langue indienne Kannara
0D00 0D7F Malayalam voir langue indienne Malayalam
0D80 0DFF Singhalais voir langue indo-européenne Cingalais
0E00 0E7F Thai voir langue asiatique Thai
0E80 0EFF Lao voir langue asiatique Lao
0F00 0FFF Tibétain voir langue asiatique Tibétain
1000 109F Birman voir langue asiatique Birman
10A0 10FF Géorgien voir langue Géorgien
1100 11FF Jamos hangûl
1200 137F Éthiopien voir Alphabet éthiopien
13A0 13FF Chérokî
1400 167F Syllabaires autochtones canadiens unifiés
1680 169F Ogam voir Écriture oghamique
16A0 16FF Runes voir Alphabet runique
1700 171F Tagalog ou tagal, voir langue Tagalog
1720 173F Hanounóo
1740 175F Bouhide
1760 177F Tagbanoua
1780 17FF Khmer voir langue Khmer
1800 18AF Mongol voir langue mongol (Монгол хэл, mongγol kele)
1900 194F Limbou
1950 197F Taï-le
19E0 19FF Symboles khmers voir langue Khmer
1D00 1D7F Supplément phonétique
1E00 1EFF Latin étendu additionnel
1F00 1FFF Grec étendu
2000 206F Ponctuation générale voir aussi ponctuation
2070 209F Exposants et indices
20A0 20CF Symboles monétaires
20D0 20FF Signes combinatoires pour symboles
2100 214F Symboles de type lettre
2150 218F Formes numérales
2190 21FF Flèches
2200 22FF Opérateurs mathématiques voir Opérateurs mathématiques
2300 23FF Signes techniques divers 2336 à 237A = symboles APL
2400 243F Pictogrammes de commande
2440 245F Reconnaissance optique de caractères voir Reconnaissance optique de caractères
2460 24FF Alphanumériques cerclés
2500 257F Filets
2580 259F Pavés
25A0 25FF Formes géométriques
2600 26FF Symboles divers
2700 27BF Casseau
27C0 27EF Divers symboles mathématiques - A
27F0 27FF Supplément A de flèches
2800 28FF Combinaisons Braille voir Braille
2900 297F Supplément B de flèches
2980 29FF Divers symboles mathématiques-B
2A00 2AFF Opérateurs mathématiques supplémentaires
2B00 2BFF Divers symboles et flèches
2D30 2D6F Alphabet Tifinagh et néo-Tifinagh voir Alphabet berbère et Tifinagh (langue berbère)
2E80 2EFF Formes supplémentaires des clés CJC voir Chinois, japonais et coréen (CJC)
2F00 2FDF Clés chinoises (K'ang-hsi ou Kangxi) voir Dictionnaire de caractères de Kangxi
2FF0 2FFF Description idéophonographique
3000 303F Symboles et ponctuation CJC voir ponctuation et Chinois, japonais et coréen (CJC)
3040 309F Hiragana voir Hiragana (langue japonaise)
30A0 30FF Katakana voir Katakana (langue japonaise)
3100 312F Bopomofo voir Bopomofo (notation taïwanaise et chinoise)
3130 318F Jamos de compatibilité hangûls
3190 319F Kanboun
31A0 31BF Bopomofo étendu voir Bopomofo (notation taïwanaise et chinoise)
31F0 31FF Extension phonétique katakana voir Katakana (langue japonaise)
3200 32FF Lettres et mois CJC cerclés voir Chinois, japonais et coréen (CJC)
3300 33FF Compatibilité CJC voir Chinois, japonais et coréen (CJC) (unités de mesure)
3400 4DB5 Supplément A aux idéophonogrammes unifiés CJC voir Chinois, japonais et coréen (CJC)
4DC0 4DFF Hexagrammes du Classique des mutations ou Yi Jing voir Yi Jing, Hexagramme
4E00 9FA5 Idéophonogrammes unifiés CJC voir Chinois, japonais et coréen (CJC)
A000 A48F Syllabaire yi des Monts frais
A490 A4CF Clés yi
AC00 D7A3 Hangûl
D800 DB7F Demi-zone haute points de code invalides isolément

D800 à D83F : codets hauts utilisés en UTF-16 pour les points de code du plan multilingue complémentaire
D840 à D87F : codets hauts utilisés en UTF-16 pour les points de code du plan idéographique complémentaire
D880 à DB3F : codets hauts utilisés en UTF-16 pour les points de code des plans complémentaires réservés
D840 à D87F : codets hauts utilisés en UTF-16 pour les points de code du plan complémentaire réservé

DB80 DBFF Partie à usage privé de la demi-zone haute points de code invalides isolément

DB80 à DBBF : codets hauts utilisés en UTF-16 pour les points de code de la zone supplémentaire A à usage privé
DBC0 à DBFF : codets hauts utilisés en UTF-16 pour les points de code de la zone supplémentaire B à usage privé

DC00 DFFF Demi-zone basse points de code invalides isolément

DC80 à DFFD : codets bas utilisés en UTF-16 pour des points de code assignés aux caractères valides ou réservés des plans complémentaires (assignés, réservés ou à usage privé)
DFFE à DFFF : codets bas pouvant être utilisés en UTF-16 pour la représentation de points de code assignés aux non-caractères en fin de chaque plan, lorsque le codet haut est le dernier assigné dans la demi-zone haute pour chaque plan complémentaire (assigné, réservé ou à usage privé)

☒E000 F8FF Zone à usage privé
F900 FAFF Idéogrammes de compatibilité CJC voir Chinois, japonais et coréen (CJC)
FB00 FB4F Formes de présentation alphabétiques
FB50 FDFF Formes A de présentation arabes voir alphabet arabe
FDD0 FDEF non-caractères
FE00 FE0F Sélecteurs de variante
FE20 FE2F Demi-signes combinatoires
FE30 FE4F Formes de compatibilité CJC voir Chinois, japonais et coréen (CJC)
FE50 FE6F Petites variantes de forme
FE70 FEFF Formes B de présentation arabes
FF00 FFEF Formes de demi et pleine chasse
FFF0 FFFD Caractères spéciaux
FFFE FFFF non-caractères

 

Repost 0
20 avril 2012 5 20 /04 /avril /2012 07:43

UTF, Universal Transformation Format 

 

 


Unicode et ISO/CEI 10646 acceptent plusieurs formes de transformation universelle pour représenter un point de code valide. Citons :

Le nombre après UTF représente le nombre minimal de bits des codets avec lesquels un point de code valide est représenté.

Ces transformations ont été initialement créées pour la représentation interne et les schémas de codage des points de code de la norme ISO 10646, qui au départ pouvait définir des points de code sur 31 bits. Depuis, la norme ISO/CEI10646 a été amendée, afin que les trois formes soient totalement compatibles entre elles et permettent de coder tous les points de code (car UTF-16 ne permet de représenter que les points de code des 17 premiers plans).

Unicode a normalisé également de façon très stricte ces trois formes de transformation de tous les points de code valides (U+0000 à U+D7FF et U+E000 à U+10FFFF) et uniquement eux, que ce soit pour représenter du texte sous forme de suites de points de codes, ou des points de code assignés aux caractères valides, ou réservés, ou assignés à des non-caractères. Les points de code assignés aux demi-zones (U+D800 à U+DFFF), utilisés uniquement en UTF-16, sont invalides isolément puisqu’il servent à la représentation, par un couple de 2 codets de 16 bits, des points de code des 16 plans supplémentaires.

 

UTF-8 


Article détaillé : UTF-8.

 

 

 

 

L’UTF-8, spécifié dans le RFC 3629, est le plus commun pour les applications Unix et Internet. Son codage de taille variable lui permet d’être en moyenne moins coûteux en occupation mémoire (pour les langues à alphabet latin). Mais cela ralentit nettement les opérations où interviennent des extractions de sous-chaînes, car il faut compter les caractères depuis le début de la chaîne pour savoir où se trouve le premier caractère à extraire.

L’UTF-8 assure aussi, et c’est son principal avantage, une compatibilité avec les manipulations simples de chaînes en ASCII dans les langages de programmation. Ainsi, les programmes écrits en C peuvent souvent fonctionner sans modification.

Initialement, l’UTF-8 pouvait coder n’importe quel point de code entre U+0000 et U+7FFFFFFF (donc jusqu’à 31 bits). Cet usage est obsolète et la norme ISO/CEI 10646 a été amendée pour ne plus supporter que les points de code valides des 17 premiers plans, sauf ceux de la demi-zone correspondant aux codets utilisés en UTF-16 pour la représentation sur deux codets des points de code des 16 plans supplémentaires. Aussi les séquences les plus longues en UTF-8 nécessitent au maximum 4 octets, au lieu de 6 précédemment. De plus, UTF-8 a été amendé d’abord par Unicode puis par l’ISO/CEI10646 pour ne plus accepter que la représentation la plus courte de chaque point de code (unicité du codage).

Son avantage sur l’UTF-16 (et l'UTF-32) est que les différences d'ordonnancement des octets composant un mot (endianness) ne posent pas de problème dans un réseau de systèmes hétérogènes ; ainsi, cette transformation est utilisée aujourd'hui par la plupart des protocoles d’échange normalisés.

D’autre part, l’UTF-8 est totalement compatible pour la transmission de textes par des protocoles basés sur le jeu de caractères ASCII, ou peut être rendu compatible (au prix d’une transformation sur plusieurs octets des caractères non-ASCII) avec les protocoles d’échange supportant les jeux de caractères codés sur 8 bits (qu’ils soient basés sur ISO-8859 ou de nombreux autres jeux de caractères codés sur 8 bits définis par des normes nationales ou des systèmes propriétaires particuliers).

Son principal défaut est le codage de longueur très variable (1 octet pour les points de code assignés aux caractères ASCII/ISO646, 2 à 4 octets pour les autres points de code), même si l'auto-synchronisation propre à l'encodage UTF-8 permet de déterminer le début d'une séquence à partir d’une position aléatoire (en effectuant au plus 3 lectures supplémentaires des codets qui précèdent). Cependant, cet encodage n'est pas conçu pour faciliter le traitement des chaînes de caractères, à cet usage on lui préfère souvent l’UTF-16, parfois l’UTF-32 (gourmand en mémoire).

 

Dérivés 

  • Certains programmes (par exemple, la base de données Oracle) représentant en interne leurs données Unicode au format UTF-16 ont (ou ont connu) un défaut de conversion vers UTF-8 : un caractère compris entre U+10000 et U+10FFFF, stocké sur deux mots de 16 bits, se retrouve converti en UTF-8 comme étant une suite de deux caractères Unicode. Cela a amené la création « accidentelle » du CESU-8 et a pour avantage de faciliter l'usage d'Unicode sur des plates-formes 16 bits.
  • Le caractère Unicode nul U+0000 est codé en UTF-8 sous forme d’un unique octet nul 0x00. Selon le standard Unicode, ce caractère n'a aucune signification particulière3 ; toutefois (pour des raisons conceptuelles historiques), les bibliothèques de traitement de chaînes du langage C considèrent ce caractère de contrôle comme une fin de chaîne, ce qui complique l'implémentation de certains cas d'application. Sous la plate-forme Java, la version « (en)Modified UTF-8 » est née en reprenant l'avantage de la portabilité « 16 bits » du CESU-8 et en y ajoutant la possibilité d'encoder U+0000 sous la séquence 0xC0 0x80 (normalement interdite en UTF-84) : en échangeant de la sorte avec les bibliothèques C natives de la plateforme supportée, la plate-forme peut gérer facilement tous les textes Unicode valides ainsi que les fichiers de classes compilées (format alternatif portable, indépendant de l'endianness et de la taille des mots).

 

UTF-16 


Article détaillé : UTF-16.

 

 

 

L’UTF-16 est un bon compromis lorsque la place mémoire n’est pas trop restreinte, car la grande majorité des caractères Unicode assignés pour les écritures des langues modernes (dont les caractères les plus fréquemment utilisés) le sont dans le plan multilingue de base et peuvent donc être représentés sur 16 bits. La version française de l’ISO/CEI 10646 nomme ces mots de 16 bits des "seizets", mais la version internationale les décrit cependant bien comme de classiques mots de 16 bits composés de deux octets, et soumis aux règles usuelles de boutisme.

Codage UTF-16
hi \ lo DC00 DC01    …    DFFF
D800 10000 10001 103FF
D801 10400 10401 107FF
  ⋮
DBFF 10FC00 10FC01 10FFFF

Les points de code des 16 plans supplémentaires nécessitent une transformation sur deux mots de 16 bits:

  • on soustrait 0x10000 au point de code, ce qui laisse un nombre de 20 bits dans l'étendue 0..0xFFFFF
  • les 10 bits de poids fort (un nombre entre 0 et 0x3FF) sont additionnés à 0xD800, et donnent la première unité de code dans la demi-zone haute (0xD800..0xDBFF)
  • les 10 bits de poids faible (un nombre entre 0 et 0x3FF) sont additionnés à 0xDC00, et donnent la seconde unité de code dans la demi-zone basse (0xDC00..0xDFFF)

Comme la plupart des caractères couramment usités résident dans le plan de base, l'encodage des plans supplémentaires est souvent peu testé dans les logiciels, conduisant à des bugs ou des problèmes de sécurité même dans des logiciels largement diffusés5. Certains cadres légaux, tels le GB 18030, peuvent demander le support des plans supplémentaires, ceux-ci contenant notamment des caractères présents dans les noms propres.

Il est possible de déterminer le début de la séquence de codage à partir d’un point quelconque d’un texte représenté en UTF-16 en effectuant au maximum une lecture supplémentaire, uniquement si ce codet est dans la demi-zone basse. Cette forme est plus économique et plus facile à traiter rapidement que l’UTF-8 pour la représentation de textes contenant peu de caractères ASCII (U+0000 à U+007F).

Toutefois, cette transformation possède deux schémas de codage incompatibles qui dépendent de l’ordonnancement des octets dans la représentation d’entiers sur 16 bits. Pour résoudre cette ambiguïté et permettre la transmission entre systèmes hétérogènes, il est nécessaire d’adjoindre une information indiquant le schéma de codage utilisé (UTF-16BE ou UTF-16LE), ou bien de préfixer le texte codé avec la représentation du point de code valide U+FEFF (assigné au caractère « espace insécable de largeur nulle », un caractère aujourd’hui réservé à ce seul usage en tant que marqueur d’ordonnancement des octets), puisque le point de code “renversé” U+FFFE valide est un non-caractère, interdit dans les textes conformes à Unicode et ISO/CEI10646.

L’autre défaut d’UTF-16 est qu’un texte transformé avec lui et transmis avec l’un ou l’autre des deux schémas de codage contient un grand nombre d’octets nuls ou ayant une valeur en conflit avec les valeurs d’octets réservées par certains protocoles d’échange.

C’est notamment le codage qu’utilise la plate-forme Java en interne, ainsi que Windows pour ses APIs compatibles Unicode (avec le type "WCHAR").

 

UTF-32 


Article détaillé : UTF-32.

 

 

 

L’UTF-32 est utilisé lorsque la place mémoire n’est pas un problème et que l’on a besoin d’avoir accès à des caractères de manière directe et sans changement de taille (hiéroglyphes).

L’avantage de cette transformation normalisée est que tous les codets ont la même taille. Il n’est donc pas nécessaire de lire des codets supplémentaires pour déterminer le début de la représentation d’un point de code.

Toutefois, ce format est particulièrement peu économique (y compris en mémoire) puisqu’il « gaspille » inutilement au moins un octet (toujours nul) par caractère. La taille en mémoire d’un texte joue négativement sur les performances puisque cela nécessite plus de lectures et écritures sur disque en cas de saturation de la mémoire vive, et que cela diminue aussi les performances du cache mémoire des processeurs.

Pour les textes écrits dans les langues modernes actuelles (hormis certains caractères rares du plan idéographique supplémentaire), et n’utilisant donc que les points de code du plan multilingue de base, cette transformation double la quantité mémoire nécessaire par rapport à l’UTF-16.

Comme l’UTF-16, l’UTF-32 possède plusieurs schémas de codage dépendant de l’ordonnancement des octets composant un entier de plus de 8 bits (deux schémas de codage de l’UTF-32 sont normalisés, UTF-32BE et UTF-32LE). Il est donc aussi nécessaire de préciser ce schéma de codage, ou de le déterminer en préfixant le texte par la représentation en UTF-32 du point de code U+FEFF. Comme l’UTF-16, la présence d’octets nuls dans les schémas de codage normalisés de l’UTF-32 le rend incompatible avec de nombreux protocoles d’échange entre systèmes hétérogènes.

Aussi ce format n’est utilisé le plus souvent que très localement pour certains traitements en tant que forme intermédiaire plus facile à manipuler, et on lui préfère souvent la transformation UTF-16 souvent plus performante pour traiter et stocker des quantités importantes de textes, la conversion entre les deux étant très simple à réaliser, et très peu coûteuse en termes de complexité de traitement.

En fait, de très nombreuses bibliothèques de traitement de textes sont écrites uniquement avec l’UTF-16 et sont plus performantes qu’en UTF-32, même lorsque les textes contiennent des caractères des plans supplémentaires (car ce cas de figure reste rare dans la très grande majorité des cas).

On notera toutefois que la transformation en UTF-32 utilise des codets sur 32 bits, dont de très nombreuses valeurs peuvent ne représenter aucun point de code valide (valeurs hors des deux intervalles représentant les points de code valides U+0000 à U+D7FF et U+E000 à U+10FFFF), donc aucun caractère valide ou réservé (toute information qui y serait contenue ne peut donc pas être du texte au sens d’Unicode). La transmission de textes utilisant ces valeurs invalides de codets dans un des schémas de codage normalisés de l’UTF-32 est interdite pour tout système conforme à Unicode (il faut utiliser plutôt les points de code à usage privé), puisqu’il sera impossible de les représenter dans une autre transformation UTF avec lesquelles les trois UTF normalisées sont bijectivement compatibles.

Repost 0
19 avril 2012 4 19 /04 /avril /2012 07:33

Unicode

 

 

 

 

 

Logo Unicode

 

 

 

 

 

 

Unicode est une norme informatique, développée par le Consortium Unicode, qui vise à permettre le codage de texte écrit en donnant à tout caractère de n’importe quel système d’écriture un nom et un identifiant numérique, et ce de manière unifiée, quelle que soit la plate-forme informatique ou le logiciel. La dernière version, Unicode 6.1.0, est publiée depuis le 31 janvier 20121.

Totalement compatible avec le jeu universel de caractères (JUC) de l'ISO/CEI 10646, la norme Unicode l'étend en lui ajoutant un modèle de représentation et de traitement de textes complets, en conférant à chaque caractère un jeu de propriétés normalisées ou informatives, en décrivant avec précision les relations sémantiques qui peuvent exister entre plusieurs caractères successifs d’un texte, et en normalisant des algorithmes de traitement qui préservent au maximum la sémantique des textes transformés, tout en étendant l’interopérabilité de la représentation de ces textes sur des systèmes hétérogènes.

Le standard Unicode est constitué d'un répertoire de plus de 109 000 caractères couvrant 93 écritures, d'un ensemble de tableaux de codes pour référence visuelle, d'une méthode de codage et de plusieurs codages de caractères standard, d'une énumération des propriétés de caractère (lettres majuscules, minuscules, symboles, ponctuation, etc.) d'un ensemble de fichiers de référence des données informatiques, et d'un certain nombre d'éléments liés, tels que des règles de normalisation, de décomposition, de tri, de rendu et d'ordre d'affichage bidirectionnel (pour l'affichage correct de texte contenant contenant à la fois des caractères d'écritures droite à gauche, comme l'arabe et l'hébreu, et de gauche à droite).

En pratique, Unicode reprend intégralement la norme ISO/CEI 10646, puisque cette dernière ne normalise que les caractères individuels en leur assignant un nom et un numéro normatif (appelé point de code) et une description informative très limitée, mais aucun traitement ni aucune spécification ou recommandation pour leur emploi dans l’écriture de langues réelles, ce que seule la norme Unicode définit précisément. L'ISO/CEI 10646 fait normativement référence à certaines partie du standard Unicode (notamment l'algorithme bidirectionnel et les propriétés des caractères) ; Unicode est également une norme de facto pour le traitement du texte et sert de base à de nombreuses autres normes.





But 


Tables Unicode (plan 0)
0000 – 0FFF   8000 – 8FFF
1000 – 1FFF 9000 – 9FFF
2000 – 2FFF A000 – AFFF
3000 – 3FFF B000 – BFFF
4000 – 4FFF C000 – CFFF
5000 – 5FFF D000 – DFFF
6000 – 6FFF E000 – EFFF
7000 – 7FFF F000 – FFFF
Autres plans Unicode
0000 – FFFF : plan 0 (BMP)
10000 – 1FFFF : plan 1 (SMP)
20000 – 2FFFF : plan 2 (SIP)
30000 – DFFFF : plans 3–13 (réservés)
E0000 – EFFFF : plan 14 (SSP)
F0000 – FFFFF : plan 15 (privé - A)
100000 – 10FFFF : plan 16 (privé - B)

Unicode, dont la première publication remonte à 1991, a été développée dans le but de remplacer l’utilisation de pages de code nationales.

Ces pages de code présentaient en effet quelques problèmes. Par exemple lorsqu’était prévu un caractère « signe monétaire », le même texte autorisant aux États-Unis une dépense en dollars pouvait une fois transmis par courrier électronique au Royaume-Uni autoriser la même dépense en livres sterling, sans que quoi que ce soit ait été modifié au texte.

Dans la pratique, tous les systèmes d’écriture ne sont pas encore présents, car un travail de recherche documentaire auprès de spécialistes peut encore s’avérer nécessaire pour des caractères rares ou des systèmes d'écriture peu connus (parce que disparus, par exemple).

Cependant, les écritures les plus utilisées dans le monde sont représentées, ainsi que des règles sur la sémantique des caractères, leurs compositions et la manière de combiner ces différents systèmes. — Par exemple, comment insérer un système d’écriture de droite à gauche dans un système d’écriture de gauche à droite (Texte bi-directionnel).

 

Normes et versions


Le travail sur Unicode est parallèle et synchronisé avec celui sur la norme ISO/CEI 10646 dont les buts sont les mêmes. L’ISO/CEI 10646, une norme internationale publiée en français et en anglais, ne précise cependant ni les règles de composition de caractères, ni les propriétés sémantiques des caractères.

Unicode aborde cependant la problématique de la casse, du classement alphabétique, et de la combinaison d’accents et de caractères. Depuis la version 1.1 d’Unicode et dans toutes les versions suivantes, les caractères ont les mêmes identifiants que ceux de la norme ISO/CEI 10646 : les répertoires sont maintenus parallèlement, à l’identique lors de leur normalisation définitive, les deux normes étant mises à jour presque simultanément. Les deux normes Unicode (depuis la version 1.1) et ISO/CEI 10646 assurent une compatibilité ascendante totale : tout texte conforme à une version antérieure doit rester conforme dans les versions ultérieures.

Ainsi les caractères de la version 3.0 d’Unicode sont ceux de la norme ISO/CEI 10646:2000. La version 3.2 d’Unicode classait 95 221 caractères, symboles et directives.

La version 4.1 d’Unicode, mise à jour en novembre 2005, contient :

  • 137 468 caractères à usage privé (assignés dans toutes les versions d’Unicode et suffisants pour tous les usages) ;
  • plus de 97 755 lettres ou syllabes, chiffres ou nombres, symboles divers, signes diacritiques et signes de ponctuation, avec parmi eux :
    • plus de 70 207 caractères idéographiques, et
      • parmi eux, 11 172 syllabes hangûles précomposées ; ainsi que
  • 8 258 positions de codes réservées de façon permanente, interdites pour le codage de texte (assignées dans toutes les versions d’Unicode) ; et
  • plusieurs centaines de caractères de contrôle ou modificateurs spéciaux ;

soit un total de près de 245 000 positions de codes assignées dans un espace pouvant contenir 1 114 112 codes différents.

Quelques problèmes semblent cependant exister, pour le codage des caractères chinois, à cause de l’unification des jeux idéographiques utilisés dans différentes langues, avec une calligraphie légèrement différente et parfois signifiante, mais ils sont en cours de résolution par Unicode qui a défini des sélecteurs de variantes et ouvert un registre de séquences normalisées qui les utilise.

La version 5.0 a été publiée en juillet 2006, la version 5.2 en octobre 2009, la version 6.0 en février 2011 et la version 6.1 le 31 janvier 2012.

 

Les couches d’Unicode


Unicode est défini suivant un modèle en couches (Note technique Unicode #172). Les autres normes ne faisaient typiquement pas de distinction entre le jeu de caractères et la représentation physique. Les couches sont ici présentées en partant de la plus haute (la plus éloignée de la machine).

Répertoire des caractères abstraits (Abstract Character Repertoire)

La couche la plus élevée est la définition du jeu de caractères. Par exemple, Latin-1 a un jeu de 256 caractères et Unicode normalise actuellement près de 110 000 caractères. En outre, Unicode leur donne des noms. Dresser la liste des caractères et leur donner des noms est donc la première couche d’Unicode.

Par exemple, le caractère Ç est nommé "Lettre majuscule latine c cédille".

Cette définition est totalement identique à celle de l’ISO/CEI 10646, qui approuve toute extension du répertoire. Unicode ne reprend dans le texte de sa norme que les noms normatifs en anglais, mais la norme ISO/CEI 10646 est publiée en deux langues également normatives. Ainsi les noms en anglais et en français sont tous deux normalisés.

Dans les faits, toute extension du répertoire se fait aujourd’hui conjointement entre le Groupe de travail responsable de l'ISO/CEI 10646 (JTC1/SC2/WG2, dont les membres votants sont uniquement des autorités de normalisation nationales des pays participants, ou leur représentant officiel), et le Comité technique Unicode UTC (dont les membres votants peuvent être n’importe quelle organisation privée ou d’intérêt public, ou même un gouvernement, qui a adhéré et paye une redevance annuelle leur permettant de participer à ces décisions).

Jeu de caractères codés (Coded Character Set)

Ici, on ajoute à la table précédente un index numérique associé à chaque caractère. Notons bien qu’il ne s’agit pas d’une représentation en mémoire, juste d’un nombre entier, appelé point de code. L'espace de codage de ces nombres est divisé en 17 zones de 65 536 points de codes. Ces zones sont appelées plans.

Le point de code est noté U+xxxx où xxxx est en hexadécimal, et comporte 4 à 6 chiffres :

  • 4 chiffres pour le premier plan, appelé plan multilingue de base (donc entre U+0000 et U+FFFF);
  • 5 chiffres pour les 15 plans suivants (entre U+10000 et U+FFFFF);
  • 6 chiffres pour le dernier plan (entre U+100000 et U+10FFFF).

Ainsi, le caractère nommé "Lettre majuscule latine c cédille" a un index de U+00C7. Il appartient au premier plan.

En principe toutes les positions de code entre U+0000 et U+10FFFF sont disponibles, mais certains intervalles sont perpétuellement réservés à des usages particulier, notamment une zone d'indirection exclue pour permettre le codage UTF-16 (cf. infra), les zones à usage privé et quelques régions (par exemple U+FFFE ou U+FFFF) contenant des non-caractères dont l'usage est interdit dans un échange de données conforme. Les autres positions de code sont soit déjà assignées à des caractères, soit réservées pour normalisation future.

Zone à usage privé : Unicode a assigné de nombreuses positions de code à des caractères valides mais dont la sémantique est inconnue car d’usage privé (par exemple les deux derniers plans entre U+F0000 et U+10FFFF sont entièrement dédiés à cet usage, hormis les deux points de code à la fin de chaque plan qui sont des non-caractères interdits dans un texte conforme).

Là encore, la normalisation du codage, c’est-à-dire l’assignation des positions de codes aux caractères du répertoire commun est une décision conjointe partagée entre les normes Unicode et ISO/CEI 10646. Tous les caractères du répertoire disposent d’un point de code unique (même si pour certaines langues ou pour Unicode certains caractères sont considérés comme équivalents).

On peut noter que si le répertoire des caractères est extensible, il est limité par la borne supérieure de l'espace de codage : U+10FFFF. Une grande majorité des points de code possibles n’est pas assignée à un caractère particulier, mais peut le devenir à tout moment.

Aussi ces positions de code encore libres ne sont pas considérés comme invalides mais représentent bien des caractères abstraits (non encore spécifiés, et temporairement réservés). Ces caractères abstraits (de même que les caractères à usage privé) complètent le jeu de caractères codés du répertoire normalisé pour former un jeu unique dit « jeu de caractères codés universel » (Universal Coded Character Set, souvent abrégé en UCS) qui contient tous les jeux de caractères codés des répertoires de chacune des versions passées, présentes et futures de l’ISO/CEI 10646 et d’Unicode (depuis la version 1.1 uniquement).

Formalisme de codage des caractères (Character Encoding Form)

Cette fois, nous arrivons à une représentation physique (en mémoire, sur disque, etc.) : cette couche spécifie quelles unités de codage (code units), octets ou bien mots de 16 - seizets - ou de 32 bits, vont représenter un caractère ou plus exactement un point de code.

Il peut exister (et il existe) plusieurs de ces formalismes. Un formalisme particulier doit préciser la taille de l'unité de codage et indiquer de quelle façon le nombre entier représentant un point de code est représenté en une suite d'unités de codage (et inversement, c'est-à-dire comment retrouver le point de code étant donnée une suite d'unités de codage).

Mécanisme de sérialisation des caractères (Character Encoding Scheme)

Cette couche s’occupe de sérialiser les suites d'unités de codage définies par la couche précédente en suites d'octets. C’est ici que se traite l’opposition entre gros boutiens (octet le plus significatif d’abord) et petits boutiens (octet le moins significatif d’abord).

C’est également ici qu’on spécifie la marque de boutianité (BOM, pour Byte Order Mark) qui permet d’indiquer en début de fichier s’il est en gros boutien ou en petit boutien. Dans le monde Internet, on l’utilise rarement, en préférant un marquage explicite (“charset=UTF-16BE” en MIME, par exemple, pour indiquer un flot de données gros boutien, où BE signifie Big Endian).

Surcodage de transfert (Transfer Encoding Syntax)

Ici, interviennent optionnellement les mécanismes de compression ou de chiffrement.

Il peut aussi y avoir un surcodage comme pour le LDAP qui spécifie que les chaînes Unicode doivent être codées en UTF-8 et surcodées en Base64.

La limite de l’octet

Contrairement aux normes précédentes, Unicode sépare la définition du jeu de caractères (la liste des caractères, leur nom et leur index, le point de code) de celle du codage. Ainsi, on ne peut donc pas parler de la taille d’un caractère Unicode, car elle dépend du codage choisi.

Là où l’ASCII utilisait jadis 7 bits et ISO 8859-1 8 bits (comme la plupart des pages de codes nationales), Unicode, qui rassemble les caractères de chaque page de code, avait besoin d’utiliser plus que les 8 bits d’un octet. La limite fut dans un premier temps fixée à 16 bits pour les premières versions d’Unicode, et à 32 bits pour les premières versions de la norme ISO/CEI 10646.

La limite actuelle est désormais placée entre 20 et 21 bits par point de code assigné aux caractères normalisés dans les deux normes, désormais mutuellement compatibles :

  • Le groupe de travail international de l’ISO normalise l’assignation des points de code aux caractères, leur nom officiel et réserve les blocs de points de code utilisés par chaque écriture ou groupe d’écritures. Il documente aussi une représentation graphique possible (indicative) pour chaque caractère (cette représentation graphique étant si possible non ambiguë grâce au placement des caractères normalisés dans les blocs de code appropriés pour un nombre limité d’écritures).
  • Le groupe de travail du Consortium Unicode normalise plus précisément (dans la norme Unicode) leur sémantique pour les traitements automatisés grâce aux tables de propriétés des caractères, et la mise au point d’algorithmes standards utilisant ces propriétés.
  • Les deux organismes de normalisation collaborent pour synchroniser en permanence leur répertoire normalisé dans des versions officielles référencées mutuellement, et travaillent ensemble pour les amendements (les versions ne devenant officielles qu’une fois que les deux organismes ont chacun approuvé et complètement défini les additions de nouveaux caractères).
  • En pratique, pour la plupart des développeurs d’applications, la norme ISO 10646 apparaît comme un sous-ensemble de la norme Unicode plus complète, mais elle dispose des mêmes points de code pour exactement le même jeu de caractères que ceux de la norme Unicode (c’est pourquoi la norme Unicode est plus connue car plus appropriée pour les traitements informatisés, mais aussi la norme Unicode est plus accessible car consultable gratuitement sur Internet).
Repost 0
10 avril 2012 2 10 /04 /avril /2012 18:04

Address Resolution Protocol

 

 

 

 

 

L’Address resolution protocol (ARP, protocole de résolution d’adresse) est un protocole effectuant la traduction d’une adresse de protocole de couche réseau (typiquement une adresse IPv4) en une adresse MAC (typiquement une adresse ethernet), ou même de tout matériel de couche de liaison. Il se situe à l’interface entre la couche réseau (couche 3 du modèle OSI) et la couche de liaison (couche 2 du modèle OSI).

Il a été défini dans la RFC 826 : An Ethernet Address Resolution Protocol.

Le protocole ARP est nécessaire au fonctionnement d’IPv4 utilisé au-dessus d’un réseau de type ethernet. En IPv6, les fonctions de ARP sont reprises par le Neighbor Discovery Protocol (NDP).

Dans la suite de l’article, le terme adresse IP est utilisé pour parler d’adresse IPv4.





Fonctionnement 

 

 


Un ordinateur connecté à un réseau informatique souhaite émettre une trame ethernet à destination d’un autre ordinateur dont il connaît l’adresse IP et placé dans le même sous-réseau. Dans ce cas, cet ordinateur va placer son émission en attente et effectuer une requête ARP en broadcast. Cette requête est de type « quelle est l’adresse MAC correspondant à l’adresse IP adresseIP ? Répondez à adresseMAC ».

Puisqu’il s’agit d’un broadcast, tous les ordinateurs du segment vont recevoir la requête. En observant son contenu, ils pourront déterminer quelle est l’adresse IP sur laquelle porte la recherche. La machine qui possède cette adresse IP sera la seule à répondre en envoyant à la machine émettrice une réponse ARP du type « je suis adresseIP, mon adresse MAC est adresseMAC ». Pour émettre cette réponse au bon ordinateur, il crée une entrée dans son cache ARP à partir des données contenues dans la requête ARP qu’il vient de recevoir.

La machine à l’origine de la requête ARP reçoit la réponse, met à jour son cache ARP et peut donc envoyer le message qu’elle avait mis en attente jusqu’à l’ordinateur concerné.

Il suffit donc d’un broadcast et d’un unicast pour créer une entrée dans le cache ARP de deux ordinateurs.

 

 

Commande arp 

 


La commande arp permet la consultation et parfois la modification de la table ARP dans certains systèmes d’exploitation.

  • arp -a  : affiche toutes les entrées dans le cache ARP.
  • arp -a @ip  : dans le cas où il y a plusieurs cartes réseau, on peut faire l’affichage du cache associé à une seule @ip.
  • arp -s @ip @MAC : ajout manuel d’une entrée statique permanente dans le cache (ce besoin se manifeste si on appelle régulièrement des hôtes, pour réduire le trafic réseau).

 

Sécurité du protocole ARP 


Le protocole ARP a été conçu sans souci particulier de sécurité. Il est vulnérable à des attaques locales sur le segment reposant principalement sur l’envoi de messages ARP erronés à un ou plusieurs ordinateurs. Elles sont regroupées sous l’appellation ARP poisoning (pollution de cache ARP). La vulnérabilité d’un ordinateur à la pollution de cache ARP dépend de la mise en œuvre du protocole ARP par son système d’exploitation.

Soit une machine Charlie qui souhaite intercepter les messages d’Alice vers Bob, toutes appartenant au même sous-réseau. L’attaque consiste pour Charlie à envoyer un paquet « arp who-has » à la machine d’Alice. Ce paquet spécialement construit contiendra comme IP source, l’adresse IP de la machine de Bob dont nous voulons usurper l’identité (ARP spoofing) et l’adresse MAC de la carte réseau de Charlie. La machine d’Alice va ainsi créer une entrée associant notre adresse MAC à l’adresse IP de la machine de Bob. Alice, destinataire de l’« arp who-has », utilise le paquet pour créer une entrée dans sa table MAC. Si Alice veut communiquer avec Bob au niveau IP, c’est Charlie qui recevra les trames d’Alice puisque notre adresse MAC est enregistré dans le cache empoisonné de Alice comme équivalence pour l’IP du poste Bob. Ceci est une faiblesse connue de la mise en œuvre d’ARP et permet de corrompre facilement un cache ARP distant.

Ces attaques peuvent permettre une écoute des communications entre deux machines (attaque de l’homme du milieu), le vol de connexion, une surcharge des commutateurs servant de structure au réseau informatique ou un déni de service (il suffit de faire une attaque de type MITM puis de refuser les paquets).

Pour lutter contre ce type d’attaque, il est possible :

  • de mettre en place des entrées statiques dans le cache ARP de chaque machine du réseau (commande arp -s). Ceci n’est applicable qu’à un faible nombre de machines (on privilégie les plus critiques, comme les serveurs et les passerelles). Sur les systèmes d’exploitation Microsoft Windows antérieurs à la version XP, une entrée statique peut être mise à jour, la seule différence est qu’elle n’expire pas ;
  • de limiter les adresses MAC sur chaque port (renseignement statique) des commutateurs s’ils le permettent (fonction Port Security). Les commutateurs de niveau 3 par exemple offrent la possibilité de paramétrer des associations port/MAC/IP statiques. Mais cela rend évidemment plus difficile la maintenance du parc ;
  • de surveiller les messages ARP circulant sur réseau informatique, à l’aide d’outils de surveillance tels qu’ARPwatch1), d’arpalert2 ou de Systèmes de Détection d’Intrusion (IDS).

Chaque entrée dans la table ARP a une durée de vie, ce qui oblige l’attaquant à corrompre régulièrement le cache de la victime. Certains systèmes d’exploitation comme Solaris permettent de modifier la valeur de ce temps d’expiration (commande ndd). Une valeur courte rendra la corruption plus facilement visible.

 

 

 

En-tête ARP

 


 


Cas général
+ Bits 0 - 7 8 - 15 16 - 31
0 Hardware type Protocol type
32 Hardware Address Length Protocol Address Length Operation
64 Sender Hardware Address
 ? Sender Protocol Address
 ? Target Hardware Address
 ? Target Protocol Address

avec :

Hardware type (type de matériel)3
  • 01 - Ethernet (10Mb) [JBP]
  • 02 - Experimental Ethernet (3Mb) [JBP]
Protocol type (Type de protocole)
  • 0x0800 - IP

Ce champ indique quel est le type de protocole couche 3 (OSI) qui utilise ARP.

Hardware Address Length (longueur de l’adresse physique)
  • 01 - Token Ring
  • 06 - Ethernet

Ce champ correspond à la longueur de l’adresse physique. La longueur doit être prise en octets.

Protocol Address Length (longueur de l’adresse logique)
  • 04 - IP v4
  • 16 - IP v6

Ce champ correspond à la longueur de l’adresse réseau. La longueur doit être prise en octets.

Operation
  • 01 - Request requête
  • 02 - Reply réponse

Ce champ permet de connaître la fonction du message et donc son objectif.

Sender Hardware Address (adresse physique de l’émetteur)

Adresse MAC source dans le cadre d’Ethernet.

Sender Internet Address (adresse réseau de l’émetteur)

Adresse IP de source dans le cadre de TCP/IP.

Target Hardware Address (adresse physique du destinataire)

Adresse MAC destination dans le cadre d’Ethernet. Si c’est une demande ARP, alors, ne connaissant justement pas cette adresse, le champ sera mis à 0.

Target Internet Address (adresse réseau du destinataire)

Adresse IP de destination dans le cadre de TCP/IP

 

 

 

Exemple d’en-tête ARP : protocole IPv4 sur Ethernet (28 octets)

 

 

 

Octet 1 Octet 2 Octet 3 Octet 4
0x0001 0x0800
0x06 0x04 Operation
Adresse MAC source (octets 1-4)
Adresse MAC source (octets 5-6) Adresse IP source (octets 1-2)
Adresse IP source (octets 3-4) Adresse MAC destination (octets 1-2)
Adresse MAC destination (octets 3-6)
Adresse IP destination (octets 1-4)

 

 

 

  • Portail de l’informatique Portail de l’informatique
  • Portail des télécommunications Portail des télécommunications

 

Repost 0
6 avril 2011 3 06 /04 /avril /2011 11:25

.

Mark Zuckerberg

Un article de Wikipédia, l'encyclopédie libre.
Mark Zuckerberg
Mark Zuckerberg à Paris, 2008.
Mark Zuckerberg à Paris, 2008.

Nom de naissance Mark Elliot Zuckerberg
Surnom(s) Zuck
Naissance 14 mai 1984 (1984-05-14) (26 ans)
Drapeau des États-Unis White Plains, État de New York (États-Unis)
Nationalité Américaine
Pays de résidence Drapeau : États-Unis États-Unis
Profession(s) Informaticien, entrepreneur
Activité(s) principale(s) Co-fondateur et CEO de Facebook
Formation Phillips Exeter Academy
Harvard College (2004)
Famille Soeurs : Randi,Donna et Arielle ; Frères : Ethan et Yoël

 

 

 

.

Mark Elliot Zuckerberg est un informaticien, chef d'entreprise américain, co-fondateur et président-directeur général du site internet de réseautage social Facebook.



Biographie 


Jeunesse et études à Harvard 


Mark Zuckerberg est né le 14 mai 1984 à White Plains au sein d'une famille juive américaine[1] dont le père (Edward Zuckerberg) est dentiste et la mère psychiatre et dont les frères, Ethan Zuckerberg et Yoël Zuckerberg, sont tous les deux toujours étudiants à l'université Harvard. Il a aussi trois sœurs.

Pendant ses années d'études à l'université, il développe des programmes informatiques, spécialement des outils de communication et des jeux.

Création de Facebook 

.

Mark et Robert Scoble en 2008.
.

La première version de Facebook est lancée le 4 février 2004 avec l'aide de Dustin Moskovitz, Eduardo Saverin et Chris Hughes[2]. Le succès est immédiat auprès des autres élèves de l'université. L’accès est graduellement autorisé à d'autres universités (principalement de l'Ivy League), puis aux écoles du secondaire, et enfin au grand public. Le succès est partout au rendez-vous.

Cependant, des étudiants de Harvard (Cameron et Tyler Winklevoss, ainsi que Divya Narendra) attaquent Facebook un mois après son lancement. En effet, ils avaient commencé depuis plusieurs mois à développer un site de réseau social intitulé « Harvardconnection ». En octobre 2003, ils avaient associé Zuckerberg à leur projet, avec pour mission de finir le code du site et de le rendre fonctionnel. Zuckerberg, lié par un "accord verbal" et dès lors considéré comme un associé du site, en profita pour développer de son côté en quelques semaines le site The Facebook, sans travailler sur le projet commun comme prévu. Un procès lui fut intenté dès mars 2004, annulé pour raisons techniques en mars 2007. Une nouvelle plainte fut déposée et la procédure fit l'objet d'un accord à l'amiable entre les différentes parties : le 25 juin 2008, Facebook accepta d'octroyer 1,2 million d'actions et de payer 20 millions de dollars en argent[3]. Selon Alexa Internet, Facebook est le deuxième site le plus visité au monde derrière Google[4]. Mark Zuckerberg possède 24 % des parts de sa société.

CEO de Facebook 


Selon le Wall Street Journal, en mai 2009, un investisseur russe aurait proposé 200 millions de dollars afin de porter le capital de l'entreprise à 10 milliards de dollars à condition de disposer d'un siège au conseil d'administration. Mark Zuckerberg aurait refusé car il déclare n'être ouvert qu'à des propositions qui offriront davantage de latitude à son réseau social.

D'après le classement Forbes 2010 des plus grosses fortunes de la planète, la fortune de Mark Zuckerberg est estimée à 6,9 milliards de dollars. Il détenait à 23 ans le titre du plus jeune milliardaire de la planète[5].

Il figure au 52e rang du classement 2008 des personnalités les plus influentes du monde dressé par le magazine Time.

En avril 2010, il s'est montré très critique vis-à-vis du réseau social Twitter en disant : « Le flux est éphémère. On poste quelque chose dans le flux, il y restera quelques heures, un certain nombre de gens pourront le lire, puis pour ainsi dire il disparaît. Quant aux services qui consomment ce flux, ils n’établissent pas réellement de connexion entre vous et, ils ne comprennent pas réellement la relation sémantique qui existe entre vous et la connexion que vous avez établie. »[6]

En décembre 2010, il est élu personnalité de l'année par le magazine Time[7]. Récemment, une fausse rumeur lancée sur internet annonçait la fermeture du site le 15 mars 2011 à minuit, sous prétexte que Mark Zuckerberg était trop stressé pour gérer son réseau social[8].

The Social Network 


En octobre 2010, Mark Zuckerberg est incarné à l'écran par l'acteur Jesse Eisenberg, sous la direction du réalisateur David Fincher dans le film The Social Network, narrant l'histoire de la naissance de Facebook. Eisenberg évolue à l'écran notamment aux côtés de l'acteur Justin Timberlake, qui incarne pour sa part le co-fondateur du site Napster, Sean Parker. Le film est produit entre autres par Kevin Spacey.

Zuckerberg a émis dans les médias américains un avis sur cette œuvre cinématographique. Il a notamment indiqué « que ça serait fun de se rappeler que cette époque de sa vie ait pu aboutir sur un film »[9]. Selon Mark Zuckerberg, les faits rapportés sont vrais mais les caractères des personnages ne collent pas à la réalité.

Il est à noter que le film est le prolongement d'une biographie écrite, La Revanche d'un solitaire, la véritable histoire de Facebook (aux Éditions Max Milo, écrite par Ben Mezrich). Cette biographie a été publiée en janvier 2010[10].

Mark Zuckerberg dans les Simpson 


En 2010, il prête sa voix à son propre personnage dans l'épisode Loan-a Lisa, appartenant à la 22e saison de la série télévisée d'animation américaine Les Simpson[11].

Annexes 


Sur les autres projets Wikimédia :

Articles connexes 


Liens externes 


 

.

 

.

Repost 0

☼ Zorbax ☼

  • : CHOMOLANGMA
  • CHOMOLANGMA
  • : Réflexions sur le sens de la vie. Diversités culturelles et médiatiques.
  • Contact

ON EST QUAND???

Bonjour, nous sommes le

☼ Qui Cherche Trouve ☼

♫♪♪♫♪♫♪♫♪

Poussieres De Savoir ☼

POUSSEZ PAS !!!

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcSH1bqV_MZbKff7r4KH0YXDgokYKnPMVcS17_NVF7KeFFQmHvTYYQ

 

 

Depuis le 2 octobre 2008 ma paroisse a compté de fidèles :

 


Compteur Global


 

 

 

 

 

☼ Merci à vous tous ☼

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcRspNEZw03K2txVYJaQojtGiQPv2Ef2hRp76vnThpM_Xhg74AeH

 

 

   Et aussi, bien sûr, à notre superbe équipe  !!!!!!!...

 


☼ En Alcove ☼

☼♥☼♥☼


 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcTJQdwhuv8K2KE2fv7sAcLYqokJ6fOwOos7DPEsrBY_tOyjkmt9

 

 

 

 

  http://t2.gstatic.com/images?q=tbn:ANd9GcTwbpFmC0lwUUqRVtxAgfCeDB97ON6I9jGDIVmmGwpa1bg_oeiS8w



 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcQJFhyxpCtvTfrKTTq2Dnraqndo0k6KOOvR5B49c424W-RXGsXk

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcQ4lkR76RVvxlM2Pg0xGQLGN-vJ1IC1AeiO9YFoy0C2maJDnAlsEA

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcS3s1MTNys4JJ2XciWuydUFkX2s3uxVNEo4XLmDXWkNuzNwaF-I

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcRpmq_X4KGoOioCJ7IGFovNaZR1dl5V9wdd73SKUZoyRXImy8hQsA

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcT6vugj46xpPFClJ40ZcN_g83W39aPcCsnryaBlwulPqhMuSmHABA

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcS0rnZSUpbcqus_ag8-saWRw8BVp-nHBjwhG0FGGsPrBMTVGsKfUA

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcRiQjNvzjX7IEkfQYGG-KxW9pOVJoLjsP43P-wRgoCo6bmRIFfQ

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcSTia4A3P4_qwGWtAAvhY4S2BKgtk6tR_QCD3_DTBLqQwkYTLP7

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcRPAWH7AgJ7gN7ej2rrAa90b9jK2nWJtRcdmCSJLXifbDqpzt-GAQ

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcSnH3SFCsuDblli6D1AJMGBIO3SduYE7QocfhaOPh2CbcgSaTJm3g

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcS_x5rZOKIoXBMbTrRfiBoXYGA8_aG1puNXFnPK-vFSJb8S0TB-

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcT5xPsHZoCoc3Y10UzSIfZBJ1VM5yTf0rOp0z02qzAq29ZylEqp

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcSJYo3dfiA7rWKtAhGDKlIvNQBBfXfxpskBzCjE2VA_WnhL03zQ

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcRrs5cw6eknmiTVBcESn97krqvfndk10XJq35s-mUIxnoXepsHU2w

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcTtPoMny2WLrgyLYUkv0xzCHZ3BSe7txlE-Xe2XSz1rA4IRBQ-8

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcTzDbIU4QatTLNRgPQwPUcMDO8BtCGQMAkP46aQAp05yXC1m0y84g

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcS_sSIdV_qG7YiVCrY6Fze69BhzpdENouF0zUUp4OV8__EbU9Ad

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcQ9uJqfoOS-LjhgtT3qLp4AH34AojcYXzS6ifUoduwpXl2xR4cu

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcSBBpAVI8uqqXKRXeWLnFO9do5ObFZm7YxgxrJ7-EbHR2oDqLo0vQ

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcRDpZXNSZZorQeUMLz3DTA9hEU2rI_bxr_LT9c4T9nvHvAWTZjCGQ

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcQJxvHFLqQeIleqlsCzYw3aqr-0Y6eKQMVnyaA5me5hdAxIljVU

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcSC9dHlJXHSlla_xZ5T9EZytHwAWT-qbU_d19dTtxAXrGNihAXKlQ

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcR9uI2iDGC9O3GMDlf8NsxtxQx-Qp8sqHmOc5rb-zkptdYl27ct

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcRbZ3vVwEjZT_vYCN_egFTIwdBz6fqNL0Pg-y_Q61vxrmzGOpx_

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcQJ2rE3MpU2-7BbpUlr6UqYo4BmnNs_dvTC88BMslWtXGy7xpm4

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcQEpgxQwBFunGDiUIemTa46VNveEHAu-uA8FY-TsPaLWXJFd2s0

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcQTdXbqeHRkSO7KlYa4OkUya7gTOtG1LddYFWDuhmMG8TTBud38

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcTNv54UJcOf0QWIB4OraEz3h5BSPwvVpIDgtJO-zq0-MNAH1T-r

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcQQ4msZqs5YGyEvDc4xIBtl0glm2rQZ7LsilbzRNUFi1QmhSgwd

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcRadP8tzRToSi6YgV25tgPSiZuZH-m01ykcCd-vsvFtJOoai2ucTw

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcQWsJatoxZ24v32bG85ut1XPEPG4Fa5l6ApTX9VfC1X3_fQlO6t

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcSATYwKzSKWCjMx6cjBGrTkiC8C_lyJBimQ86hhDpKGyeWCgRFU5Q

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcRkni6wj2PqLxVIQnGL2w-Hh0Qdu5Q2vEiKSUXAJ7TKh9ePWQBm

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcQzo44WmwLEIvLwTyzq_jnCtqqHX6X_CIYel1kbk7vcUHUp-ieN

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcQJijg5RyUyd3NObMK9uNkIduA32k3nPJwfiuvaWrAi2Td5vyXO

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcSLXSS07G9gseceN7SeCwGRL0C6ij_75lYGEnDN1qwb_bEl9bGs

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcSgjOBb-AqrP0ZXPZSVl55yswE6dnD4uny-n0Xh-9mAuwm1GUq3

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcSZAb3DktAXiGznQlZB9az_nvD6AoLygDkDTstPDm_WBfLnJ3ltQg

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcRXwcTaTVudGTxMwVFFrGw1Z-j9x9D9inLKamTPCwUThDbPuEYpeA

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcTU6wtRoYw9X2-MMykBLzlVjXeRgi5rqzD5ck22QxWwI8h7QeNUQA

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcRpMUOK13Ots0UnbeCQLds3ixSZxNY9gFOfm65Bvc-pf6ZKAlWbzg

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcQhH-RzSe9GF29vGoZwod2tN7O-9mFfpWJX4bLt78JtJYMqI8w1rA

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcQxu-I9t3HJlWQ3e6bM41HAOc8j3Smoe-ahJN9OTRyzd6vOUOVF

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcQYkezUKlW0ttRviIW9f6NJHBcjJ-sUE4XMIic0ka6qkCguqsqWEQ

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcSLwoIa5Xuj4eEFEX5vzJFqlL0GIrwjAUDCWbZgf6ni2O6MUMuwHg

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcSmu_lhCfJa5L3JKT73eNWm5-DVlMMhgQ2zjDd5kmbF9S0PDwt0

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcTl9CWad5AcZHOfC-RgTWPbODkKY_C0DW3MZXkDUucqfvfZLDvJvQ

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcSSorC-n_GApivF90u5JfsOvUI44_E6pQ_gYw3Zv_SawrJlQ7U_OA

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcSHehPIU8WfymVyIehhOVdWyZ9Iby-7WygiZdxRqYoB6-t4uxfc

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcTHknIkIppczoDGtgqaDVGpF5vzTnPgO0XzesL14bXWKIidntgi

 

 

 

http://t0.gstatic.com/images?q=tbn:ANd9GcQ2gFiEiRrnRVPCVmgC8fP4RV_b4Cyut6pHRWot2zotTH_isSgx

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcRMnyl4ZznB4yj9tFflGmUrm8zxq1VAfdzbHlagdVlYHHs5AqI2Xw

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcSABiNYE2Ig0ORn0Dp6LWBs8FU1-eDuUfhJpaBhY3dBILcGkw7Y

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcQX6x3fLQO-eGD7Sdc__AFLjGRztfSRzdOgtJe_w_XI_qKOl_cQ

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcQWAfv06yKnlGGke983sE24US_BbpZ0xgnAp3yIh3eXvCRrRfxtgg

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcSguscboVOMXCDflSARG5UefcNGLsGZylvXKHJGK4ldNdG1xYiR

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcTVsXwe7MG_AOX5rUiFD0hVw9aHeILEWPB_3WS5456jt040weKpxQ

 

 

 

http://t2.gstatic.com/images?q=tbn:ANd9GcS14rgGXof16mpTbvNq37y9tGIxf38V3B4j5iFLZChBi8qMo0cC

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcRk338QqS34hcxTHah2whOwSbnEtO-yxxKutL5KPMcrWPKtCTUf

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcTQg04AvSsLnhDeWWl4-qLzPD5EX7xzuOAVEiswXHB9n5gRBOxj

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcQC715gVGqLwXFM7U94WtdKlMrAiHbkqIvJl2WJ6h_JMsUMfL622g

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcR4ku7jfXybpiE3fm21gXSpihSd_rjwxvIac8kqkj5TkIg3rLODrg

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcThGLPUz7SfnoPUPrFttXiSBuS3NYmV99axgZzgYDofBuo_RpfcUg

 

 

 

http://t3.gstatic.com/images?q=tbn:ANd9GcSqsjlV84iSMlkqfRlTaGiWfn6_nyGg91BQcNLZbGrRnn0-j3S4

 

 

 

http://t1.gstatic.com/images?q=tbn:ANd9GcSwkrLsv_IQh2wUOQ1DkYx-HwxeUOLNEtv8yCh59CnX_HbW5H3q

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

☼ Quoi & Où ☼