Code Unix étendu - Extended Unix Code

Le code Unix étendu ( EUC ) est un système de codage de caractères multi-octets utilisé principalement pour le japonais , le coréen et le chinois simplifié .

Les codes EUC les plus couramment utilisés sont des codages à largeur variable avec un caractère appartenant à un jeu de caractères codés conforme à la norme ISO/IEC 646 (tel que ASCII ) prenant un octet, et un caractère appartenant à un jeu de caractères codés 94x94 (tel que GB 2312 ) représenté en deux octets. La forme EUC-CN de GB 2312 et EUC-KR sont des exemples de tels codes EUC à deux octets. EUC-JP comprend des caractères représentés par jusqu'à trois octets, y compris un code de décalage initial , alors qu'un seul caractère dans EUC-TW peut prendre jusqu'à quatre octets.

Les applications modernes sont plus susceptibles d'utiliser UTF-8 , qui prend en charge tous les glyphes des codes EUC, et plus, et est généralement plus portable avec moins d'écarts et d'erreurs des fournisseurs. EUC est cependant toujours très populaire, en particulier EUC-KR pour la Corée du Sud.

Structure de codage

Relation entre l'EUC compacté et d'autres profils ISO 2022 8 bits

La structure de l'EUC est basée sur la norme ISO/IEC 2022 , qui spécifie un système de jeux de caractères graphiques pouvant être représentés avec une séquence de 94 octets de 7 bits 0x 21–7E, ou alternativement 0xA1–FE si un huitième bit est disponible. Cela permet des ensembles de 94 caractères graphiques, ou 8836 (94 2 ) caractères, ou 830584 (94 3 ) caractères. Bien qu'initialement 0x20 et 0x7F aient toujours été l' espace et le caractère de suppression et que 0xA0 et 0xFF n'aient pas été utilisés, les éditions ultérieures d' ISO/IEC 2022 ont permis l'utilisation des octets 0xA0 et 0xFF (ou 0x20 et 0x7F) dans les ensembles dans certaines circonstances, permettant l'inclusion de jeux de 96 caractères. Les plages 0x00–1F et 0x80–9F sont utilisées pour les codes de contrôle C0 et C1 .

EUC est une famille de profils 8 bits de la norme ISO/IEC 2022 , par opposition aux profils 7 bits tels que ISO-2022-JP . En tant que tels, seuls les jeux de caractères conformes à la norme ISO 2022 peuvent avoir des formes EUC. Jusqu'à quatre jeux de caractères codés (appelés G0, G1, G2 et G3 ou jeux de codes 0, 1, 2 et 3) peuvent être représentés avec le schéma EUC. Le jeu G0 est défini sur un jeu de caractères codés conforme à la norme ISO/IEC 646 tel que US-ASCII , ISO 646:KR ( KS X 1003 ) ou ISO 646:JP (la moitié inférieure de JIS X 0201 ) et invoqué sur GL (c'est-à-dire 0x21–0x7E, avec le bit le plus significatif effacé). Si US-ASCII est utilisé, cela fait du code un codage ASCII étendu ; l'écart le plus courant par rapport à US-ASCII est que 0x5C ( barre oblique inverse en US-ASCII) est souvent utilisé pour représenter un signe Yen dans EUC-JP (voir ci-dessous) et un signe gagné dans EUC-KR.

Les autres jeux de codes sont invoqués sur GR (c'est-à-dire avec le jeu de bits de poids fort). Par conséquent, pour obtenir la forme EUC d'un caractère, le bit le plus significatif de chaque octet de codage est défini (équivalent à ajouter 128 à chaque octet de codage de 7 bits, ou à ajouter 160 à chaque nombre dans le code kuten ) ; cela permet au logiciel de distinguer facilement si un octet particulier dans une chaîne de caractères appartient au code ISO 646 ou au code étendu. Les caractères des jeux de codes 2 et 3 sont préfixés par les codes de contrôle SS2 (0x8E) et SS3 (0x8F) respectivement, et invoqués sur GR. Outre le code de décalage initial, tout octet en dehors de la plage 0xA0-0xFF apparaissant dans un caractère des jeux de codes 1 à 3 n'est pas un code EUC valide.

Le code EUC lui - même n'utilise pas les séquences d' annonce et de désignation de l' ISO 2022 . Cependant, la spécification du code est équivalente à la séquence suivante de quatre séquences d'annonces ISO 2022 , dont les significations se décomposent comme suit.

Séquence individuelle Hexadécimal Caractéristique de l'EUC notée
ESC SP C 1B 20 43 ISO-8 (8 bits, G0 en GL, G1 en GR)
ESC SP Z 1B 20 5A G2 accédé à l'aide de SS2
ESC SP [ 1B 20 5B G3 accessible via SS3
ESC SP \ 1B 20 5C Les équipes uniques appellent sur GR

Format à largeur fixe

Le codage à largeur variable basé sur ISO-2022 décrit ci-dessus est parfois appelé format compact EUC , qui est le format de codage généralement appelé EUC. Cependant, le traitement interne des données EUC peut utiliser un format de transformation à largeur fixe appelé format EUC complet à deux octets . Cela représente:

  • Le code défini 0 comme deux octets dans la plage 0x21–0x7E (sauf que le premier peut être 0x00).
  • Jeu de codes 1 sur deux octets dans la plage 0xA0–0xFF (sauf que le premier peut être 0x80).
  • Jeu de codes 2 sous forme d'octet dans la plage 0x20–0x7E (ou 0x00) suivi d'un octet dans la plage 0xA0–0xFF.
  • Jeu de codes 3 sous la forme d'un octet dans la plage 0xA0–0xFF (ou 0x80) suivi d'un octet dans la plage 0x21–0x7E.

Les octets initiaux de 0x00 et 0x80 sont utilisés dans les cas où le jeu de codes utilise un seul octet. Il existe également un format de longueur fixe à quatre octets. Ces formats de codage de longueur fixe sont adaptés au traitement interne et ne sont généralement pas rencontrés dans les échanges.

EUC-JP est enregistré auprès de l'IANA dans les deux formats, le format compressé comme "EUC-JP" ou "csEUCPkdFmtJapanese" et le format à largeur fixe comme "csEUCFixWidJapanese". Seul le format compressé est inclus dans la norme de codage WHATWG utilisée par HTML5 .

EUC-CN

EUC-CN
encodage EUCCN.svg
MIME / IANA GB2312
Pseudo(s) csGB2312
Langue(s) Chinois simplifié , anglais , russe
Standard GB 2312 (1980)
Classification ASCII étendu , codage à largeur variable , codage CJK , EUC
S'étend US-ASCII
Rallonges 748, GBK , GB 18030 , x-mac-chinesesimp
Transforme / Encode GB 2312
succédé par GBK , GB 18030

EUC-CN est la forme codée habituelle de la norme GB 2312 pour les caractères chinois simplifiés . Contrairement au cas du japonais JIS X 0208 et ISO-2022-JP , GB 2312 n'est normalement pas utilisé dans une version de code ISO 2022 à 7 bits , bien qu'une variante de forme appelée HZ (qui délimite le texte GB 2312 avec des séquences ASCII) ait parfois été utilisée sur USENET .

Un caractère ASCII est représenté dans son encodage habituel. Un caractère de GB 2312 est représenté par deux octets, tous deux de la plage 0xA1–0xFE.

Systèmes d'encodage de la Chine continentale associés

748 code

Un codage lié à EUC-CN est le code « 748 » utilisé dans le système de composition WITS développé par Beijing's Founder Technology (maintenant obsolète par son nouveau système de composition FITS). Le code 748 contient tout le GB 2312 , mais n'est pas conforme à la norme ISO 2022 et n'est donc pas un véritable code EUC. (Il utilise un octet d'avance de 8 bits mais fait la distinction entre un deuxième octet avec son bit le plus significatif défini et un avec son bit le plus significatif effacé, et sa structure est donc plus similaire à Big5 et à d'autres systèmes de codage DBCS non conformes à la norme ISO 2022 .) La partie non GB2312 du code 748 contient des caractères traditionnels et de Hong Kong et d'autres glyphes utilisés dans la composition de journaux.

GBK et GB 18030

Articles principaux: GBK (codage de caractères) et GB 18030

GBK est une extension de GB 2312 . Il définit une forme étendue du codage EUC-CN capable de représenter un plus grand nombre de caractères CJK provenant en grande partie d' Unicode 1.1 , y compris les caractères chinois traditionnels et les caractères utilisés uniquement en japonais . Il ne s'agit cependant pas d'un véritable code EUC, car les octets ASCII peuvent apparaître comme des octets de suivi (et les octets C1 , non limités aux décalages simples, peuvent apparaître comme des octets de début ou de suivi), en raison d'un espace de codage plus important.

Des variantes de GBK sont implémentées par la page de codes Windows 936 (la page de codes Microsoft Windows pour le chinois simplifié) et par la page de codes 1386 d'IBM.

L' encodage de caractères GB 18030 basé sur Unicode définit une extension de GBK capable d'encoder l'intégralité d' Unicode . Cependant, le codage Unicode en tant que GB 18030 est un codage à largeur variable qui peut utiliser jusqu'à quatre octets par caractère, en raison d'un espace de codage encore plus important. Étant une extension de GBK, il s'agit d'un sur-ensemble d'EUC-CN mais n'est pas en soi un véritable code EUC. Étant un encodage Unicode, son répertoire est identique à celui des autres formats de transformation Unicode tels que UTF-8 .

Mac OS chinois simplifié

D'autres variantes EUC-CN s'écartant du mécanisme EUC incluent le script chinois simplifié Mac OS (connu sous le nom de page de code 10008 ou x-mac-chinesesimp). Il utilise les octets 0x80, 0x81, 0x82, 0xA0, 0xFD, 0xFE et 0xFF pour le U avec tréma (ü), deux caractères métriques de police spéciaux, l' espace insécable , le signe de copyright (©), le signe de marque (™ ) et les points de suspension (…) respectivement. Cela diffère de ce qui est considéré comme un caractère à un octet par rapport au premier octet d'un caractère à deux octets de EUC (où, parmi ceux-ci, 0xFD et 0xFE sont définis comme des octets de tête) et GBK (où, parmi ceux-ci, 0x81, 0x82, 0xFD et 0xFE sont définis comme des octets de tête).

Cette utilisation de 0xA0, 0xFD, 0xFE et 0xFF correspond à la variante Shift_JIS d'Apple .

Outre ces modifications apportées à la plage d'octets de tête, l'autre caractéristique distinctive de la partie à double octet de Mac OS chinois simplifié est l'inclusion de deux extensions au GB 2312-80 de base définies dans les rangées 6 et 8. Celles-ci sont considérées comme des "extensions standard". à GB 2312", dont aucune n'est la propriété d'Apple : l'extension de la rangée 8 a été prise à partir de GB 6345.1 , les deux extensions sont incluses par GB/T 12345 (la variante chinoise traditionnelle de GB 2312), et les deux extensions sont incluses par GB 18030 (le successeur de GB 2312).

EUC-JP

EUC-JP
EUC-JP.svg
MIME / IANA EUC-JP
Pseudo(s) JIS unixisé (UJIS), csEUCPkdFmtJaponais
Langue(s) japonais , anglais , russe
Classification ISO 646 étendu , codage à largeur variable , codage CJK , EUC
S'étend US-ASCII ou ISO 646:JP
Transforme / Encode JIS X 0208 , JIS X 0212 , JIS X 0201
succédé par EUC-JISx0213
EUC-JIS-2004
Pseudo(s) EUC-JISx0213
Langue(s) japonais , aïnou , anglais , russe
Standard JIS X 0213
Classification ASCII étendu , codage à largeur variable , codage CJK , EUC
S'étend US-ASCII
Transforme / Encode JIS X 0213 , JIS X 0201 (Kana)
Précédé par EUC-JP

EUC-JP est un codage à largeur variable utilisé pour représenter les éléments de trois normes de jeu de caractères japonais , à savoir JIS X 0208 , JIS X 0212 et JIS X 0201 . Les autres noms de cet encodage incluent Unixized JIS (ou UJIS ) et AT&T JIS . 0,1% de toutes les pages Web utilisent EUC-JP depuis août 2018, tandis que 2,5% des sites Web en japonais utilisent cet encodage (moins utilisé que Shift JIS ou UTF-8 ). Il s'agit de la page de code 954 d'IBM. Microsoft a deux numéros de page de code pour ce codage (51932 et 20932).

Ce schéma de codage permet de mélanger facilement l'ASCII 7 bits et le japonais 8 bits sans avoir besoin des caractères d'échappement utilisés par ISO-2022-JP , qui est basé sur les mêmes normes de jeu de caractères, et sans que les octets ASCII n'apparaissent comme des octets de suivi. (contrairement à Shift JIS ).

Un codage connexe et partiellement compatible, appelé EUC-JISx0213 ou EUC-JIS-2004 , code JIS X 0201 et JIS X 0213 (de la même manière que Shift_JISx0213 , son homologue basé sur Shift_JIS).

Comparé à EUC-CN ou EUC-KR, EUC-JP n'est pas devenu aussi largement adopté sur les systèmes PC et Macintosh au Japon, qui utilisaient Shift JIS ou ses extensions ( page de code Windows 932 sur Microsoft Windows et MacJapanese sur Mac OS classique ) , bien qu'il soit devenu largement utilisé par Unix ou Unix les systèmes d' exploitation (sauf pour HP-UX ). Par conséquent, si les sites Web japonais utilisent EUC-JP ou Shift_JIS, cela dépend souvent du système d'exploitation utilisé par l'auteur.

Les caractères sont codés comme suit :

  • En tant qu'encodage conforme EUC/ ISO 2022 , les caractères de contrôle C0 , l'espace et DEL sont représentés comme en ASCII.
  • Un caractère graphique de l' ASCII (jeu de codes 0) est représenté comme sa représentation habituelle sur un octet, dans la plage 0x21 – 0x7E. Alors que certaines variantes d'EUC-JP codent ici la moitié inférieure de JIS X 0201 , la plupart codent en ASCII, y compris la norme de codage W3C/WHATWG utilisée par HTML5 , tout comme EUC-JIS-2004. Bien que cela signifie que 0x5C est généralement mappé à Unicode en tant que U+005C REVERSE SOLIDUS (la barre oblique inverse ASCII ), U+005C peut être affiché comme un signe Yen par certaines polices locales japonaises, par exemple sur Microsoft Windows, pour la compatibilité avec la moitié inférieure de JIS X 0201 .
  • Un caractère de JIS X 0208 (jeu de codes 1) est représenté par deux octets, tous deux compris entre 0xA1 et 0xFE. Cela diffère de la représentation ISO-2022-JP par le fait que le bit haut est défini. Ce jeu de codes peut également contenir des extensions de fournisseur dans certaines variantes EUC-JP. Dans EUC-JIS-2004, le premier plan de JIS X 0213 est codé ici, qui est en fait un sur-ensemble de la norme JIS X 0208 .
  • Un caractère de la moitié supérieure de JIS X 0201 ( demi-largeur kana , jeu de codes 2) est représenté par deux octets, le premier étant 0x8E, le second étant la représentation habituelle de JIS X 0201 dans la plage 0xA1 - 0xDF. Cet ensemble peut contenir des extensions de fournisseur IBM dans certaines variantes.
  • Un caractère de JIS X 0212 (jeu de codes 3) est représenté dans EUC-JP par trois octets, le premier étant 0x8F, les deux suivants étant compris entre 0xA1 et 0xFE, c'est-à-dire avec le bit de poids fort défini. En plus de la norme JIS X 0212 , le jeu de codes 3 de certaines variantes EUC-JP peut également contenir des extensions dans les lignes 83 et 84 pour représenter les caractères des extensions Shift JIS d'IBM qui manquent de mappages JIS X 0212 standard, qui peuvent être codés dans l'un des deux mises en page, l'une définie par IBM elle-même et l'autre définie par l' OSF . Dans EUC-JIS-2004, le deuxième plan de JIS X 0213 est codé ici, ce qui n'entre pas en collision avec les lignes allouées dans la norme JIS X 0212 . Certaines implémentations d'EUC-JIS-2004, telles que celle utilisée par Python , autorisent à la fois les caractères JIS X 0212 et JIS X 0213 plane 2 dans cet ensemble.

Méthodes d'encodage japonais associées

Les extensions de fournisseur à EUC-JP (de, par exemple, Open Software Foundation , IBM ou NEC ) étaient souvent allouées dans les jeux de codes individuels, par opposition à l'utilisation de séquences EUC invalides (comme dans les extensions populaires de EUC-CN et EUC-KR ).

Cependant, certains encodages spécifiques au fournisseur sont partiellement compatibles avec EUC-JP, en raison de l'encodage JIS X 0208 sur GR, mais ne suivent pas la structure EUC compressée. Souvent, ceux-ci n'incluent pas l'utilisation des équipes uniques d'EUC-JP et ne sont donc pas des extensions directes d'EUC-JP, à l'exception de Super DEC Kanji.

DEC Kanji

Digital Equipment Corporation définit deux variantes d'EUC-JP ne se conformant qu'en partie au format compact EUC, mais présentant également une certaine ressemblance avec le format complet à deux octets. Le format global de l'encodage « DEC Kanji » correspond principalement à l'EUC à largeur fixe (deux octets complets) ; cependant, le jeu de codes 0 n'a pas besoin d'être rempli à gauche avec des octets nuls (de la même manière que le format compressé). JIS X 0208 est, comme d'habitude, utilisé pour le jeu de codes 1 ; le jeu de codes 2 (katakana demi-largeur) est absent ; le jeu de codes 3 est codé comme le format à largeur fixe à deux octets (c'est-à-dire sans octet de décalage et avec uniquement le premier jeu de bits de poids fort), mais utilisé pour les caractères définis par l'utilisateur à deux octets plutôt que d'être spécifié pour JIS X 0212. Dans la base Encodage "DEC Kanji", seules les 31 premières lignes du jeu de codes 3 sont utilisées pour les caractères définis par l'utilisateur : les lignes 32 à 94 sont réservées, de la même manière que les lignes inutilisées du jeu de codes 1.

Le codage "Super DEC Kanji" accepte les codes à la fois du codage "DEC Kanji" et du format compact EUC, pour un total de cinq jeux de codes. Il permet également d'utiliser l'ensemble du jeu de codes défini par l'utilisateur et les lignes inutilisées aux extrémités des jeux de codes JIS X 0208 et JIS X 0212 (lignes 85-94 et 78-94 respectivement) pour les caractères définis par l'utilisateur.

HP-16

Hewlett-Packard définit un codage appelé "HP-16". Cela accompagne leur encodage "HP-15", qui est une variante de Shift JIS . HP-16 encode JIS X 0208 en utilisant les mêmes octets que dans EUC-JP, mais n'utilise pas les codes de décalage unique (en omettant ainsi les jeux de codes 2 et 3), et ajoute trois régions définies par l'utilisateur qui ne suivent pas le format compressé Structure de l'EUC :

  • Octets de tête 0xA1–C2, octets de queue 0x21–7E
  • Octets de tête 0xC3–E3, octets de queue 0x21–3F
  • Octets de tête 0xC3–E1, octets de queue 0x40–64

IKIS

L'encodage IKIS (Interactive Kanji Information System) utilisé par Data General ressemble à EUC-JP sans décalage unique, c'est-à-dire avec uniquement les jeux de codes 0 et 1. Les katakana demi-largeur sont plutôt inclus dans la ligne 8 de JIS X 0208 (en collision avec la boîte- caractères de dessin ajoutés à la norme en 1983). JIS X 0208, les lignes 9 à 12 sont utilisées pour les caractères définis par l'utilisateur.

Adaptations de EUC-JP pour EBCDIC

Article principal: langue japonaise dans EBCDIC

KEIS (Kanji-processing Extended Information System) est un codage EBCDIC utilisé par Hitachi , avec des caractères à double octet (un codage DBCS-Host) inclus à l'aide de séquences de décalage, ce qui en fait un codage avec état . Plus précisément, la séquence 0x0A 0x41passe en mode simple octet et la séquence 0x0A 0x42passe en mode double octet. Cependant, les caractères JIS X 0208 sont codés en utilisant les mêmes séquences d'octets que celles utilisées pour les coder dans EUC-JP. Cela se traduit par des encodages en double pour l' espace idéographique - 0x4040 selon la structure de code DBCS-Host, et 0xA1A1 comme dans EUC-JP. Cela diffère de l'encodage DBCS-Host d'IBM pour le japonais, dont la mise en page s'appuie sur des versions antérieures à JIS X 0208. La plage d'octets de plomb est étendue à 0x59, dont les octets de plomb 0x81-A0 sont désignés pour les caractères définis par l'utilisateur, et le reste est utilisé pour les caractères définis par l'entreprise, y compris les kanji et les non-kanji.

JEF (Japanese-processing Extended Feature) est un encodage EBCDIC utilisé sur les mainframes Fujitsu FACOM, contrairement à FMR (une variante de Shift JIS) utilisé sur les PC Fujitsu. Comme KEIS, JEF est un codage avec état, passant à un mode DBCS-Host à deux octets à l'aide de séquences de décalage (où 0x29passe en mode à un octet et 0x28passe en mode à deux octets). De la même manière que KEIS, les codes JIS X 0208 sont représentés de la même manière que dans EUC-JP. La plage d'octets de tête est étendue à 0x41, avec 0x80–A0 désigné pour la définition de l'utilisateur ; les octets de tête 0x41–7F se voient attribuer les numéros de ligne 101 à 163 à des fins de kuten , bien que la ligne 162 (octet de tête 0x7E) ne soit pas utilisée. Les lignes 101 à 148 sont utilisées pour les kanji étendus, tandis que les lignes 149 à 163 sont utilisées pour les non-kanji étendus.

EUC-KR

« EUC-KR » redirige ici. Pour la variante ainsi nommée dans les normes HTML, voir Unified Hangul Code .
EUC-KR
EUC-KR sans extensions.svg
Structure du code EUC-KR
MIME / IANA EUC-KR
Pseudo(s) Wansung, IBM-970
Langue(s) coréen , anglais , russe
Standard KS X 2901 (KS C 5861)
Classification ISO 646 étendu , codage à largeur variable , codage CJK , EUC
S'étend US-ASCII ou ISO 646:KR
Rallonges Mac OS Coréen , IBM-949 , Code Hangul unifié (Windows-949)
Transforme / Encode KS X 1001
succédé par Code Hangul unifié (normes Web)

EUC-KR est un codage à largeur variable pour représenter le texte coréen à l'aide de deux jeux de caractères codés, KS X 1001 (anciennement KS C 5601) et ISO 646 :KR ( KS X 1003 , anciennement KS C 5636 ) ou US-ASCII , selon sur variante. KS X 2901 (anciennement KS C 5861 ) stipule le codage et RFC  1557 l'a surnommé EUC-KR.

Un caractère tiré de KS X 1001 (G1, jeu de codes 1) est codé sur deux octets dans GR (0xA1–0xFE) et un caractère de KS X 1003 ou US-ASCII (G0, jeu de codes 0) prend un octet dans GL ( 0x21–0x7E).

Il est généralement appelé Wansung ( coréen : 완성 , romanisé :  Wanseong , lit.  « précomposé ») en République de Corée . IBM fait référence au composant codé sur deux octets en tant que page de code 971 et à EUC-KR avec ASCII en tant que page de code 970 . Il est implémenté en tant que page de code 20949 ("Korean Wansung") et page de code 51949 ("EUC Korean") par Microsoft.

En octobre 2021, 0,1% de toutes les pages Web dans le monde utilisent EUC-KR, ce qui est trompeur car 7,8% des pages Web sud-coréennes utilisent (seul pays pour lequel l'encodage est destiné), ce qui en fait le non -UTF-8 / Encodage Unicode pour une langue/domaine Web, alors que seulement 3,9% des pages Web utilisent la langue coréenne (ce qui rend l'utilisation de l'UTF-8, à 92,2%, moins populaire en Corée du Sud que dans (apparemment) tous les pays du monde). Y compris les extensions, il s'agit de l'encodage de caractères hérité le plus largement utilisé en Corée sur les trois principales plates-formes ( macOS , autres systèmes d'exploitation de type Unix et Windows), mais son utilisation s'est très lentement déplacée vers UTF-8 à mesure qu'il gagne en popularité, en particulier sur Linux et macOS.

Comme pour la plupart des autres encodages, UTF-8 est désormais préféré pour les nouvelles utilisations, résolvant les problèmes de cohérence entre les plates-formes et les fournisseurs.

Systèmes d'encodage coréens associés

Code Hangul unifié

Article principal : Code Hangul unifié

Une extension courante d'EUC-KR est le code Hangul unifié ( 통합형 한글 코드 , Tonghabhyeong Hangeul Kodeu ou 통합 완성형 , Tonghab Wansunghyung ), qui est la page de code coréenne par défaut sur Microsoft Windows. Il reçoit le numéro de page de code 949 par Microsoft et 1261 ou 1363 par IBM. La page de codes d'IBM 949 est une extension EUC-KR différente et sans rapport.

Unified Hangul Code étend EUC-KR en utilisant des codes qui ne sont pas conformes à la structure EUC pour incorporer des blocs de syllabes supplémentaires, complétant ainsi la couverture des blocs de syllabes composés disponibles dans Johab et Unicode. La norme d' encodage W3C / WHATWG utilisée par HTML5 intègre les extensions de code Hangul unifié dans sa définition d'EUC-KR.

Mac OS coréen (HangulTalk)

D'autres encodages incorporant EUC-KR en tant que sous-ensemble incluent le script coréen Mac OS (connu sous le nom de page de code 10003 ou x-mac-korean), qui a été utilisé par HangulTalk (MacOS-KH), la localisation coréenne du Mac OS classique . Il a été développé par Elex Computer ( 일렉스 ), qui était à l'époque le distributeur autorisé des ordinateurs Apple Macintosh en Corée du Sud.

HangulTalk ajoute des caractères d'extension avec des octets de tête compris entre 0xA1 et 0xAD, à la fois dans l'espace inutilisé dans le plan EUC-KR GR (octets de suivi 0xA1-0xFE) et en utilisant des codes non-EUC en dehors de celui-ci (octets de suivi 0x41-0xA0). Certains de ces caractères sont des dingbats stylisés indépendants du style de police . Beaucoup de ces caractères n'ont pas de mappages Unicode exacts, et le logiciel Apple mappe ces cas de différentes manières à des séquences de combinaison , à des mappages approximatifs avec un caractère à usage privé ajouté comme modificateur à des fins d'aller-retour ou à des caractères à usage privé.

Apple utilise également certains codes à un octet en dehors du plan EUC-KR pour des caractères supplémentaires : 0x80 pour un espace requis , 0x81 pour un signe gagné (₩), 0x82 pour un tiret (–), 0x83 pour un signe de copyright (© ), 0x84 pour un trait de soulignement large (＿) et 0xFF pour une ellipse (…). Bien qu'aucun de ces codes à un octet supplémentaires ne se trouve dans la plage d'octets de tête du code EUC-KR (contrairement aux extensions d'Apple à EUC-CN, voir ci-dessus ), certains se trouvent dans la plage d'octets de tête du code Hangul unifié (en particulier, 0x81, 0x82 , 0x83 et 0x84).

EUC-KP

Article principal : KPS 9566

De la même manière que KS X 1001, la norme nord-coréenne KPS 9566 est généralement utilisée sous la forme EUC ; dans ces contextes, il est parfois appelé EUC-KP. Des éditions plus récentes de la norme étendent la représentation EUC avec des caractères utilisant des codes à deux octets non EUC, de la même manière que le code Hangul unifié.

EUC-TW

EUC-TW est un codage à largeur variable qui prend en charge US-ASCII et 16 plans de CNS 11643 , chacun étant 94x94. Il s'agit d'un codage rarement utilisé pour les caractères chinois traditionnels tels qu'ils sont utilisés à Taïwan . Les variantes de Big5 sont beaucoup plus courantes que EUC-TW, bien que Big5 ne code que les deux premiers plans de CNS 11643 hanzi , tandis que UTF-8 devient de plus en plus courant.

  • En tant que codage EUC/ ISO 2022 , les caractères de contrôle C0 , l'espace ASCII et DEL sont codés comme en ASCII.
  • Un caractère graphique de l'US-ASCII (G0, jeu de codes 0) est codé en GL comme sa représentation habituelle sur un seul octet (0x21-0x7E).
  • Un caractère du plan CNS 11643 1 (jeu de codes 1) est codé sur deux octets en GR (0xA1–0xFE).
  • Un caractère dans les plans 1 à 16 de CNS 11643 (code set 2) est codé sur quatre octets :
    • Le premier octet est toujours 0x8E (Single Shift 2).
    • Le deuxième octet (0xA1–0xB0) indique le plan, dont le numéro est obtenu en soustrayant 0xA0 à cet octet.
    • Les troisième et quatrième octets sont en GR (0xA1–0xFE).

Notez que le plan 1 du CNS 11643 est codé deux fois en tant que jeu de codes 1 et une partie du jeu de codes 2.

Voir également

Remarques

Les références

  1. ^ A b c d IBM . "Architecture de représentation des données de caractère (CDRA)" . p. 157-162.
  2. ^ A b c Lunde, Ken (2008). Traitement de l'information CJKV : informatique chinoise, japonaise, coréenne et vietnamienne . O'Reilly. p. 242-244. ISBN 9780596800925.
  3. ^ "Ensembles de caractères" . IANA.
  4. ^ "4.2. Noms et étiquettes" . Norme d'encodage . WHATWG.
  5. ^ A b c d "Carte (version externe) de Mac OS chinois simplifié du codage en Unicode 3.0 et versions ultérieures" . Apple, Inc .
  6. ^ un b "Propriété Encoding.WindowsCodePage - .NET Framework (version actuelle)" . MSDN . Microsoft.
  7. ^ Lunde, Ken (1998). Annexe F : GB/T 12345 (PDF) . Traitement des informations CJKV . O'Reilly Media . ISBN 9781565922242.
  8. ^ Administration de normalisation de la Chine (SAC) (2005-11-18). GB 18030-2005 : Technologie de l'information—Jeu de caractères codés chinois .
  9. ^ un b "Les tendances historiques dans l'utilisation des codages de caractères pour les sites Web" . W3Techs.
  10. ^ "Document d'information CCSID 954" . Archivé de l'original le 2016-03-27.
  11. ^ Composants internationaux pour Unicode (ICU), ibm-954_P101-2007.ucm , 2002-12-03
  12. ^ A b c d "JIS X 0213 Code Tableaux de cartographie" . x0213.org.
  13. ^ "Ambigüités dans la conversion de l'EUC japonais en Unicode (non normatif)" . Profil japonais XML . W3C.
  14. ^ "décodeur EUC-JP" . Norme d'encodage . WHATWG. "Si octet est un octet ASCII, renvoie un point de code dont la valeur est octet."
  15. ^ "3.1.1 Détails des problèmes" . Problèmes et solutions pour les caractères Unicode et définis par l'utilisateur/fournisseur . Le Groupe Ouvert Japon. Archivé de l'original le 1999-02-03 . Récupéré le 2019-08-14 .
  16. ^ Kaplan, Michael S. (2005-09-17). « Quand est-ce qu'une barre oblique inverse n'est pas une barre oblique inverse ? » .
  17. ^ un b "4.2 Processus d'examen des règles pour la conversion d'ensemble de codes entre eucJP-open et UCS" . Problèmes et solutions pour les caractères Unicode et définis par l'utilisateur/fournisseur . Le Groupe Ouvert Japon. Archivé de l'original le 1999-02-03 . Récupéré le 2019-08-14 .
  18. ^ un b Lunde, Ken (13 janvier 2009). "Annexe J: Jeux de caractères japonais" (PDF) . Traitement de l'information CJKV (2e éd.). ISBN 978-0-596-51447-1.
  19. ^ un b Chang, Hyeshik. "Lisez-moi pour CJKCodecs" . cPython . Fondation du logiciel Python.
  20. ^ A b c d e f g h i Lunde, Ken (13 Janvier 2009). « Annexe F : Méthodes de codage des fournisseurs » (PDF) . Traitement de l'information CJKV (2e éd.). ISBN 978-0-596-51447-1.
  21. ^ A b c d e f g h i j Lunde, Ken (2009). « Annexe E : Normes de jeu de caractères du fournisseur » (PDF) . Traitement de l'information CJKV : informatique chinoise, japonaise, coréenne et vietnamienne (2e éd.). Sébastopol, Californie : O'Reilly . ISBN 978-0-596-51447-1.
  22. ^ un b "2 : Jeux de codes et Conversion de jeux de codes" . Référence technique DIGITAL UNIX pour l'utilisation des fonctionnalités japonaises . Société d'équipement numérique , Compaq .
  23. ^ "KS X 1001:1992" (PDF) .
  24. ^ "KS C 5601:1987" (PDF) . 1988-10-01.
  25. ^ Lunde, Ken (2009). "Chapitre 3 : Normes de jeu de caractères" . Traitement des informations CJKV . p. 146. ISBN 978-0596514471.
  26. ^ " Mondialisation d'IBM - Identificateurs de jeu de caractères codés - CCSID 971 " . Récupéré le 03/09/2021 .
  27. ^ "CCSID 970" . Mondialisation d'IBM . IBM. Archivé de l'original le 2014-12-01.
  28. ^ "ibm-970_P110_P110-2006_U2 (alias euc-kr)" . Explorateur de convertisseurs - Démonstration ICU . Composants internationaux pour Unicode.
  29. ^ Composants internationaux pour Unicode (ICU), ibm-970_P110_P110-2006_U2.ucm , 2002-12-03
  30. ^ un b "Identifiants de page de code" . Centre de développement Windows . Microsoft.
  31. ^ Julliard, Alexandre. "dump_krwansung_codepage: construire une table coréenne Wansung à partir du fichier KSX1001" . make_unicode : génère des fichiers .c de page de code à partir des descriptions ftp.unicode.org . Projet Vin .
  32. ^ "Répartition des codages de caractères parmi les sites Web qui utilisent .kr" . w3techs.com . Récupéré le 2021-10-17 .
  33. ^ "Répartition des codages de caractères parmi les sites Web qui utilisent le coréen" . w3techs.com . Récupéré 2020-07-03 .
  34. ^ "한글 코드에 대하여" (en coréen). W3C. Archivé de l'original le 2013-05-24 . Récupéré le 07/01/2019 .
  35. ^ Dans ucnv_lmb.cpp , un fichier provenant d' IBM et inclus dans l'arborescence des sources International Components for Unicode , l'octet de tête 0x11 est commenté comme faisant référence à « Coréen : ibm-1261 » après la définition deULMBCS_GRP_KO, et est mappé au"windows-949"codec ICU dans leOptGroupByteToCPNametableau plus loin dans le fichier.
  36. ^ "Identifiants de jeux de caractères codés - CCSID 1363" , IBM Globalization , IBM, archivé à partir de l'original le 2014-11-29
  37. ^ "5. Index (§ index EUC-KR)" , Norme de codage , WHATWG
  38. ^ Gil, Hojin. "HangulTalk : environnement Hangul standard de facto pour Mac" . Guide d'utilisation de Hangul sur Macintosh .
  39. ^ une pomme b (2005-04-05). "Carte (version externe) de l'encodage coréen Mac OS vers Unicode 3.2 et versions ultérieures" . Consortium Unicode .
  40. ^ Kim, Kyongsok (2002-11-30). "Tableaux de références croisées à 3 voies - KS X 1001, KPS 9566 et UCS" (PDF) . ISO/CEI JTC 1/SC 2 /WG 2 N2564.[Remarque : liens mis à jour pour les tableaux du document d'accompagnement : [1] [2] ]
  41. ^ Chung, Jaemin (2018-01-05). « Informations sur la version la plus récente du KPS 9566 (KPS 9566-2011 ?) » (PDF) . UTC L2/18-011.

Liens externes