GB 18030

Ce jeu de caractères a été publié en sous l’appellation officielle « Chinese National Standard GB 18030-2000: Information Technology — Chinese ideograms coded character set for information interchange — Extension for the basic set ». GB est l'abréviation de Guójiā Biāozhǔn (国家标准), qui signifie standard national en chinois.

Le standard a été publié par China Standard Press de Pékin (capitale de la République populaire de Chine) le 17 mars 2000 et mis à jour le 20 novembre 2000. Au 1^er septembre 2001, le support pour ce jeu de caractères est officiellement (en RPC) obligatoire pour tous les logiciels vendus à un client final de RPC.

La dernière révision, « Chinese National Standard GB 18030-2005: Information technology  —  Chinese coded character set » a été publiée par China Standard Press le 18 novembre 2005. Seule la version de 2000 est obligatoire pour la certification de conformité GB 18030 auprès de la Chinese Electronics Standardization Institute (CESI)[1] - [2].

GB18030 peut être considéré comme un format de transport d’Unicode (UTF) (c’est-à-dire un codage de tous les points de code Unicode) qui maintient la compatibilité avec les jeux de caractères anciens (patrimoniaux). En d'autres termes, il s’agit d'un équivalent chinois de l’UTF-8 (qui maintient la compatibilité avec l’ASCII). Comme l’UTF-8, le GB18030 est un surensemble de l’ASCII et peut représenter la plage de valeur entière des points de code Unicode. En raison de son équivalence avec Unicode, le GB18030 supporte les caractères tant du chinois simplifié que du chinois traditionnel.

Le GB18030 conserve également la compatibilité avec GBK (à l’exception du symbole euro qui est codé sur un seul octet de 0x80 dans la dernière version GBK de Microsoft et un code de deux octets, A2 E3, en GB18030), qui était le standard de caractères préexistant en République populaire de Chine, dans le but de simplifier la mise à jour des données et des logiciels pour utiliser GB18030. Des parties des données mappées viennent d’une table de recherche (comme dans GBK). Le reste est calculé algorithmiquement. Il hérite également des mauvais aspects des standards legacy (anciens) sur lesquels il est basé (en particulier, un algorithme spécial est nécessaire pour rechercher des caractères ASCII dans des séquences GB18030).

Beaucoup de sociétés de développement logiciel ont déjà standardisé sur la base d'une version donnée d’Unicode le format de représentation interne de leurs données et appels systèmes. Cependant, la plupart ne supportent que les points de code du PMB originellement définis dans la version Unicode 1.0, qui ne supportait que 65536 positions de code et était souvent codée sur 16 bits comme UCS-2.

Dans un changement d’importance historique pour les logiciels conformes à Unicode, la République populaire de Chine a décidé d'exiger le support de certains points de code en dehors du PMB. Cela signifie que le logiciel ne peut plus continuer à supposer que tous les caractères sont des entités d’une taille fixe de 16 bits (UCS-2). En conséquence, ils doivent soit traiter les données avec des caractères de taille variable (comme UTF-8 ou UTF-16), qui sont les choix les plus communs, soit choisir une largeur fixe plus grande (telle que UCS-4 ou UTF-32). Microsoft a réalisé la migration depuis UCS-2 vers UTF-16 avec Windows 2000.

La police de caractères SimSun 18030 permet l’affichage des caractères GB 18030, qui reprend tous les caractères d’Unicode 2.1 plus de nouveaux caractères qui se trouvent dans le bloc Unicode Supplément A aux idéogrammes unifiés CJC[3].

Le schéma de 4 octets peut être pensé comme composé de deux unités, chacune de deux octets. Chaque unité a un format similaire à un caractère GBK de deux octets mais avec une plage de valeur pour le deuxième octet de 0x30-0x39 (codes ASCII des chiffres décimaux). Le premier octet est dans la plage 0x81 à 0xFE, comme auparavant. Cela signifie qu’une routine de recherche de caractère sûre pour GBK devrait également être sûre pour GB18030 (de la même manière qu’une recherche orientée octet est raisonnablement sûre pour le EUC).

Cela donne un total de 1 587 600 (126 × 10 × 126 × 10) séquences de 4 octets possibles, qui est pour le moment suffisant pour couvrir les 1 114 112 (17 × 65 536) code points d’Unicode.

Le sujet se complique du fait qu’il n’existe pas de règle simple pour convertir les séquences de 4 octets dans leur point de code correspondant. En fait, ces numéros sont alloués de façon séquentielle et gros-boutiste (big-endian) seulement vers les code points Unicode qui ne sont pas mappés d'une quelconque autre manière. Par exemple :

• (en) International Consulting LLC, GB18030 White Paper, 27 aout 2009 (lire en ligne)