Aujourd'hui, nous allons parler de l'origine des krakozyabrs sur un site Web et dans les programmes, des encodages de texte existants et de ceux qui doivent être utilisés. Examinons de plus près l'historique de leur développement, en commençant par l'ASCII de base, ainsi que ses versions étendues CP866, KOI8-R, Windows 1251 et en terminant par les encodages modernes du consortium Unicode UTF 16 et 8. Table des matières :
Pour certains, cette information peut sembler inutile, mais sauriez-vous combien de questions je reçois spécifiquement concernant les krakozyabrs rampants (ensemble de caractères illisibles). J'aurai maintenant l'occasion de renvoyer tout le monde au texte de cet article et de trouver mes propres erreurs. Eh bien, préparez-vous à absorber les informations et essayez de suivre le déroulement de l’histoire.
ASCII - codage de texte de base pour l'alphabet latin
Le développement des codages de texte s'est produit simultanément avec la formation de l'industrie informatique et, pendant cette période, ils ont subi de nombreux changements. Historiquement, tout a commencé avec EBCDIC, plutôt dissonant dans la prononciation russe, qui permettait d'encoder des lettres de l'alphabet latin, des chiffres arabes et des signes de ponctuation avec des caractères de contrôle. Néanmoins, le point de départ du développement des codages de texte modernes doit être considéré comme le fameux ASCII (American Standard Code for Information Interchange, qui en russe est généralement prononcé comme « demander »). Il décrit les 128 premiers caractères les plus couramment utilisés par les utilisateurs anglophones : lettres latines, chiffres arabes et signes de ponctuation. Ces 128 caractères décrits en ASCII comprenaient également certains caractères de service tels que des crochets, des dièses, des astérisques, etc. En fait, vous pouvez les voir vous-même : ce sont ces 128 caractères de la version originale de l'ASCII qui sont devenus la norme, et dans tout autre encodage vous les retrouverez certainement et ils apparaîtront dans cet ordre. Mais le fait est qu'à l'aide d'un octet d'information, vous pouvez coder non pas 128, mais jusqu'à 256 valeurs différentes (deux puissance huit égale 256), donc, après la version de base d'Asuka, un tout une série d' encodages ASCII étendus est apparue , dans laquelle il était possible, en plus des 128 caractères de base, d'être également codés à l'aide de caractères d'encodage nationaux (par exemple, le russe). Ici, il vaut probablement la peine d’en dire un peu plus sur les systèmes numériques utilisés dans la description. Premièrement, comme vous le savez tous, un ordinateur ne fonctionne qu'avec les nombres du système binaire, c'est-à-dire avec les zéros et les uns (« algèbre booléenne », si quelqu'un l'a suivi dans un institut ou une école). Un octet est constitué de huit bits, dont chacun représente un deux à la puissance deux, en commençant par zéro et jusqu'à deux puissance sept : Il n'est pas difficile de comprendre que toutes les combinaisons possibles de zéros et de uns dans une telle construction peuvent seulement 256. Convertir un nombre du système binaire en décimal est assez simple. Il vous suffit d’additionner toutes les puissances de deux avec celles au-dessus. Dans notre exemple, cela s'avère être 1 (2 à la puissance zéro) plus 8 (deux à la puissance 3), plus 32 (deux à la puissance cinq), plus 64 (à la puissance six), plus 128. (à la septième puissance). Le total est de 233 en notation décimale. Comme vous pouvez le constater, tout est très simple. Mais si vous regardez attentivement le tableau avec les caractères ASCII, vous verrez qu'ils sont représentés en codage hexadécimal. Par exemple, « astérisque » correspond au nombre hexadécimal 2A en Aski. Vous savez probablement que dans le système numérique hexadécimal, en plus des chiffres arabes, les lettres latines de A (signifie dix) à F (signifie quinze) sont également utilisées. Eh bien, pour convertir un nombre binaire en hexadécimalrecourir à la méthode simple suivante. Chaque octet d'information est divisé en deux parties de quatre bits. Ceux. Dans chaque demi-octet, seules seize valeurs (deux à la puissance quatre) peuvent être codées en binaire, qui peut facilement être représentée sous forme de nombre hexadécimal. De plus, dans la moitié gauche de l'octet, les degrés devront être recomptés à partir de zéro, et non comme indiqué sur la capture d'écran. En conséquence, nous obtenons que le nombre E9 est codé dans la capture d'écran. J'espère que le déroulement de mon raisonnement et la solution à cette énigme vous ont été clairs. Eh bien, continuons maintenant en parlant des encodages de texte.
Versions étendues d'Asuka - Encodages CP866 et KOI8-R avec pseudographies
Nous avons donc commencé à parler d'ASCII, qui était en quelque sorte le point de départ du développement de tous les encodages modernes (Windows 1251, Unicode, UTF 8). Initialement, il ne contenait que 128 caractères de l'alphabet latin, des chiffres arabes et autre chose, mais dans la version étendue, il est devenu possible d'utiliser les 256 valeurs pouvant être codées dans un octet d'information. Ceux. Il est devenu possible d'ajouter des symboles de lettres de votre langue à Aski. Ici, nous devrons faire une nouvelle digression pour expliquer pourquoi les encodages de texte sont nécessaires et pourquoi ils sont si importants. Les caractères sur l'écran de votre ordinateur sont formés sur la base de deux éléments : des ensembles de formes vectorielles (représentations) de divers caractères (ils se trouvent dans des fichiers avec des polices installées sur votre ordinateur) et un code qui vous permet d'extraire exactement celui-là. à partir de cet ensemble de formes vectorielles (fichier de police), un symbole qu'il faudra insérer au bon endroit. Il est clair que les polices elles-mêmes sont responsables des formes vectorielles, mais le système d'exploitation et les programmes qui y sont utilisés sont responsables de l'encodage. Ceux. tout texte sur votre ordinateur sera un ensemble d'octets, dont chacun code un seul caractère de ce même texte. Le programme qui affiche ce texte à l'écran (éditeur de texte, navigateur, etc.), lors de l'analyse du code, lit l'encodage du caractère suivant et recherche la forme vectorielle correspondante dans le fichier de police requis, qui est connecté pour afficher ce texte. document texte. Tout est simple et banal. Cela signifie que pour coder n'importe quel caractère dont nous avons besoin (par exemple, de l'alphabet national), deux conditions doivent être remplies : la forme vectorielle de ce caractère doit être dans la police utilisée, et ce caractère peut être codé en codages ASCII étendus. en un octet. Par conséquent, il existe de nombreuses options de ce type. Juste pour coder les caractères de la langue russe, il existe plusieurs variétés d'Aska étendu. Par exemple, le CP866 est apparu à l'origine , qui avait la capacité d'utiliser des caractères de l'alphabet russe, et il s'agissait d'une version étendue de l'ASCII. C'est-à-dire que sa partie supérieure coïncidait complètement avec la version de base d'Aska (128 caractères latins, chiffres et autres conneries), qui est présentée dans la capture d'écran juste au-dessus, mais la partie inférieure du tableau avec encodage CP866 avait l'apparence indiquée dans le capture d'écran juste en dessous et autorisé à encoder 128 caractères supplémentaires (lettres russes et toutes sortes de pseudo-graphiques) : Vous voyez, dans la colonne de droite, les chiffres commencent par 8, car les nombres de 0 à 7 font référence à la partie de base de l'ASCII (voir première capture d'écran). Ainsi, la lettre cyrillique « M » dans CP866 aura le code 9C (elle est située à l'intersection de la ligne correspondante avec 9 et de la colonne avec le chiffre C dans le système numérique hexadécimal), qui peut être écrite dans un octet d'information. , et s'il existe une police appropriée avec des caractères russes, cette lettre apparaîtra dans le texte sans aucun problème. D'où vient cette somme ?pseudographiques dans CP866 ? Le fait est que cet encodage du texte russe a été développé au cours de ces années difficiles, où les systèmes d'exploitation graphiques n'étaient pas aussi répandus qu'aujourd'hui. Et dans Dosa et les systèmes d'exploitation de texte similaires, les pseudographies ont permis au moins d'une manière ou d'une autre de diversifier la conception des textes, et donc CP866 et tous ses autres pairs de la catégorie des versions étendues d'Asuka en abondent. CP866 a été distribué par IBM, mais en plus de cela, un certain nombre d'encodages ont été développés pour les caractères de la langue russe, par exemple, KOI8-R peut être attribué au même type (ASCII étendu) : Le principe de son fonctionnement reste le même que celui celui du CP866 décrit un peu plus haut - Chaque caractère de texte est codé sur un seul octet. La capture d'écran montre la seconde moitié du tableau KOI8-R, car la première moitié est tout à fait cohérente avec l'Asuka de base, qui est présentée dans la première capture d'écran de cet article. Parmi les caractéristiques de l'encodage KOI8-R, on peut noter que les lettres cyrilliques de son tableau ne sont pas classées par ordre alphabétique, comme cela se faisait dans le CP866. Si vous regardez la toute première capture d'écran (de la partie de base, qui est incluse dans tous les encodages étendus), vous remarquerez que dans KOI8-R les lettres russes sont situées dans les mêmes cellules du tableau que les lettres correspondantes de l'alphabet latin. de la première partie du tableau. Cela a été fait pour faciliter le passage des caractères russes aux caractères latins en supprimant un seul bit (deux à la puissance septième ou 128).
Windows 1251 - la version moderne d'ASCII et pourquoi les fissures apparaissent
Le développement ultérieur des codages de texte était dû au fait que les systèmes d'exploitation graphiques gagnaient en popularité et que la nécessité d'y utiliser des pseudographies disparaissait au fil du temps. En conséquence, tout un groupe est apparu qui, en substance, étaient encore des versions étendues d'Asuka (un caractère de texte est codé avec un seul octet d'information), mais sans l'utilisation de symboles pseudographiques. Ils appartenaient aux codages dits ANSI, développés par l'American Standards Institute. Dans le langage courant, le nom cyrillique était également utilisé pour la version prenant en charge la langue russe. Un exemple de ceci serait Windows 1251 . Il différait favorablement des CP866 et KOI8-R précédemment utilisés en ce sens que la place des symboles pseudographiques était prise par les symboles manquants de la typographie russe (à l'exception de la marque d'accent), ainsi que par les symboles utilisés dans les langues slaves proches de Russe (ukrainien, biélorusse, etc.) : En raison d'une telle abondance d'encodages de la langue russe, les fabricants de polices et les fabricants de logiciels avaient constamment des maux de tête, et vous et moi, chers lecteurs, avons souvent eu des ennuis avec ces mêmes bugs notoires lorsqu'il y a eu confusion avec la version utilisée dans le texte. Très souvent, ils apparaissaient lors de l'envoi et de la réception de messages par courrier électronique, ce qui impliquait la création de tables de conversion très complexes, qui, en fait, ne pouvaient pas résoudre fondamentalement ce problème, et souvent les utilisateurs utilisaient la translittération des lettres latines pour la correspondance afin de évitez le fameux charabia lors de l'utilisation d'encodages russes comme CP866, KOI8-R ou Windows 1251. En fait, les fissures apparaissant à la place du texte russe étaient le résultat d'une mauvaise utilisation de l'encodage d'une langue donnée, qui ne correspondait pas à celui de lequel le message texte a été initialement codé. Disons que si vous essayez d'afficher des caractères codés à l'aide de CP866 à l'aide de la table de codes Windows 1251, alors ce même charabia (un ensemble de caractères dénué de sens) apparaîtra, remplaçant complètement le texte du message. Une situation similaire se produit très souvent lors de la création et de la configuration de sites Web, de forums ou de blogs, lorsque du texte contenant des caractères russes est enregistré par erreur dans le mauvais encodage utilisé par défaut sur le site, ou dans le mauvais éditeur de texte, ce qui ajoute un gag invisible. au code à l'œil nu. En fin de compte, beaucoup de gens en ont eu assez de cette situation avec beaucoup d'encodages et des conneries constamment rampantes, et les conditions préalables sont apparues pour la création d'une nouvelle variante universelle qui remplacerait toutes celles existantes et résoudrait le problème de l'apparition de textes illisibles. . De plus, il y avait le problème de langues comme le chinois, où il y avait beaucoup plus de caractères que 256.
Unicode - encodages universels UTF 8, 16 et 32
Ces milliers de caractères du groupe linguistique d'Asie du Sud-Est ne pouvaient pas être décrits dans un seul octet d'informations alloué au codage des caractères dans les versions étendues de l'ASCII. En conséquence, un consortium appelé Unicode (Unicode Consortium) a été créé avec la coopération de nombreux leaders de l'industrie informatique (ceux qui produisent des logiciels, qui codent du matériel, qui créent des polices) intéressés par l'émergence d'un codage de texte universel. La première variante publiée sous les auspices du Consortium Unicode était UTF 32 . Le nombre dans le nom de codage signifie le nombre de bits utilisés pour coder un caractère. 32 bits équivalent à 4 octets d'informations qui seront nécessaires pour coder un seul caractère dans le nouveau codage UTF universel. En conséquence, le même fichier avec du texte codé en version étendue ASCII et en UTF-32, dans ce dernier cas, aura une taille (poids) quatre fois plus grande. C'est mauvais, mais nous avons maintenant la possibilité d'encoder en UTF un nombre de caractères égal à deux puissance trente secondes ( des milliards de caractères qui couvriront toute valeur vraiment nécessaire avec une marge colossale). Mais de nombreux pays avec des langues du groupe européen n'avaient pas du tout besoin d'utiliser un si grand nombre de caractères dans le codage. Cependant, lors de l'utilisation de UTF-32, ils ont reçu sans raison un quadruplement du poids des documents texte, et par conséquent, une augmentation du volume du trafic Internet et du volume des données stockées. C’est beaucoup et personne ne peut se permettre un tel gaspillage. À la suite du développement d'Unicode, UTF-16 est apparu , qui s'est avéré si réussi qu'il a été adopté par défaut comme espace de base pour tous les caractères que nous utilisons. Il utilise deux octets pour coder un caractère. Voyons à quoi ressemble cette chose. Dans le système d'exploitation Windows, vous pouvez suivre le chemin « Démarrer » - « Programmes » - « Accessoires » - « Outils système » - « Table des caractères ». En conséquence, un tableau s'ouvrira avec les formes vectorielles de toutes les polices installées sur votre système. Si vous sélectionnez le jeu de caractères Unicode dans les « Options avancées », vous pourrez voir pour chaque police séparément toute la gamme de caractères qu'elle contient. D'ailleurs, en cliquant sur l'un d'entre eux, vous pouvez voir son code à deux octets au format UTF-16 , composé de quatre chiffres hexadécimaux : Combien de caractères peuvent être codés en UTF-16 en utilisant 16 bits ? 65 536 (deux puissance seize), et c'est le nombre qui a été adopté comme espace de base dans Unicode. De plus, il existe des moyens de coder environ deux millions de caractères en l'utilisant, mais ils étaient limités à un espace étendu d'un million de caractères de texte. Mais même cette version réussie du codage Unicode n'a pas apporté beaucoup de satisfaction à ceux qui écrivaient, par exemple, des programmes uniquement en anglais, car après le passage de la version étendue de l'ASCII à l'UTF-16, le poids des documents a doublé (un octet par caractère en Aski et deux octets pour le même caractère en YUTF-16). C'est précisément pour satisfaire tout le monde au sein du consortium Unicode qu'il a été décidé de proposer un codage à longueur variable . Il s'appelait UTF-8. Malgré le huit dans le nom, il a en réalité une longueur variable, c'est-à-dire Chaque caractère de texte peut être codé dans une séquence de un à six octets. En pratique, UTF-8 n'utilise que la plage de un à quatre octets, car au-delà de quatre octets de code, il n'est même plus théoriquement possible d'imaginer quoi que ce soit. Tous les caractères latins qu'il contient sont codés sur un octet, tout comme dans le bon vieux ASCII. Ce qui est remarquable, c'est que dans le cas de l'encodage uniquement de l'alphabet latin, même les programmes qui ne comprennent pas Unicode liront quand même ce qui est encodé en YTF-8. Autrement dit, la partie de base d'Asuka a simplement été transférée à cette idée originale du consortium Unicode. Les caractères cyrilliques en UTF-8 sont codés sur deux octets et, par exemple, les caractères géorgiens sont codés sur trois octets. Le Consortium Unicode, après avoir créé UTF 16 et 8, a résolu le problème principal : nous avons désormais un seul espace de code dans nos polices . Et maintenant, leurs fabricants ne peuvent le remplir qu'avec des formes vectorielles de caractères de texte en fonction de leurs points forts et de leurs capacités. Dans le « Tableau des caractères » ci-dessus, vous pouvez voir que différentes polices prennent en charge différents nombres de caractères. Certaines polices riches en Unicode peuvent être assez lourdes. Mais maintenant, ils ne diffèrent pas par le fait qu'ils ont été créés pour des encodages différents, mais par le fait que le fabricant de polices a rempli ou pas complètement l'espace de code unique avec certaines formes vectorielles.
Des mots fous au lieu de lettres russes - comment y remédier
Voyons maintenant comment les krakozyabrs apparaissent à la place du texte ou, en d'autres termes, comment le codage correct du texte russe est sélectionné. En fait, il est défini dans le programme dans lequel vous créez ou modifiez ce même texte, ou codez à l'aide de fragments de texte. Pour éditer et créer des fichiers texte, j'utilise personnellement un très bon éditeur HTML et PHP, à mon avis, Notepad++ . Cependant, il peut mettre en évidence la syntaxe de centaines d’autres langages de programmation et de balisage, et a également la possibilité d’être étendu à l’aide de plugins. Lisez une revue détaillée de ce merveilleux programme sur le lien fourni. Dans le menu supérieur de Notepad++, il y a un élément « Encodages », où vous aurez la possibilité de convertir une option existante en celle utilisée par défaut sur votre site : Dans le cas d'un site sur Joomla 1.5 et supérieur, comme ainsi que dans le cas d'un blog sur WordPress, vous devez éviter l'apparition de Krakozyabrov en choisissant l' option UTF 8 sans BOM . Quel est le préfixe de la nomenclature ? Le fait est que lorsqu'ils développaient le codage YUTF-16, pour une raison quelconque, ils ont décidé d'y attacher une chose telle que la possibilité d'écrire le code de caractère à la fois en séquence directe (par exemple, 0A15) et en sens inverse (150A). . Et pour que les programmes comprennent dans quel ordre lire les codes, le BOM (Byte Order Mark ou, en d'autres termes, signature) a été inventé, qui se traduisait par l'ajout de trois octets supplémentaires au tout début des documents. Dans l'encodage UTF-8, aucune nomenclature n'était prévue dans le consortium Unicode, et donc l'ajout d'une signature (ces fameux trois octets supplémentaires au début du document) empêche simplement certains programmes de lire le code. Par conséquent, lors de l’enregistrement de fichiers au format UTF, nous devons toujours sélectionner l’option sans nomenclature (sans signature). Ainsi, vous vous protégerez à l'avance des évasions des krakozyabrs . Ce qui est remarquable, c'est que certains programmes sous Windows ne peuvent pas faire cela (ils ne peuvent pas enregistrer de texte au format UTF-8 sans nomenclature), par exemple le même bloc-notes Windows notoire. Il enregistre le document au format UTF-8, mais ajoute toujours la signature (trois octets supplémentaires) au début de celui-ci. De plus, ces octets seront toujours les mêmes - lisez le code en séquence directe. Mais sur les serveurs, à cause de cette petite chose, un problème peut survenir : des escrocs vont apparaître. Par conséquent, n’utilisez en aucun cas le bloc-notes Windows standard.pour éditer des documents sur votre site si vous ne souhaitez pas que des fissures apparaissent. Je considère l'éditeur Notepad++ déjà mentionné comme l'option la meilleure et la plus simple, qui ne présente pratiquement aucun inconvénient et ne présente que des avantages. Dans Notepad++, lorsque vous sélectionnez un encodage, vous aurez la possibilité de convertir le texte en encodage UCS-2, qui est de nature très proche de la norme Unicode. Également dans le Bloc-notes, il sera possible d'encoder du texte en ANSI, c'est-à-dire par rapport à la langue russe, il s'agira de Windows 1251, que nous avons déjà décrit juste au-dessus. D'où viennent ces informations ? Il est enregistré dans le registre de votre système d'exploitation Windows - quel encodage choisir dans le cas d'ANSI, lequel choisir dans le cas d'OEM (pour la langue russe, ce sera CP866). Si vous définissez une autre langue par défaut sur votre ordinateur, ces encodages seront remplacés par des encodages similaires de la catégorie ANSI ou OEM pour cette même langue. Après avoir enregistré le document dans Notepad++ dans l'encodage dont vous avez besoin ou ouvert le document depuis le site pour le modifier, vous pourrez voir son nom dans le coin inférieur droit de l'éditeur : Pour éviter toute confusion , en plus des étapes décrites ci-dessus , il sera utile d'écrire le code source dans son en-tête sur toutes les pages du site avec des informations sur ce même encodage, afin qu'il n'y ait pas de confusion sur le serveur ou l'hébergeur local. En général, tous les langages de balisage hypertexte, à l'exception du HTML, utilisent une déclaration XML spéciale, qui spécifie l'encodage du texte.
<?xml version="1.0" encoding="windows-1251"?>
Avant d'analyser le code, le navigateur sait quelle version est utilisée et comment exactement il doit interpréter les codes de caractères de cette langue. Mais ce qui est remarquable, c'est que si vous enregistrez le document dans l'Unicode par défaut, cette déclaration XML peut être omise (l'encodage sera considéré comme UTF-8 s'il n'y a pas de nomenclature ou UTF-16 s'il y a une nomenclature). Dans le cas d'un document HTML, l'élément Meta permet d'indiquer l'encodage , qui est placé entre les balises Head d'ouverture et de fermeture :
<head>...<meta charset="utf-8">...</head>
Cette entrée est assez différente du standard HTML 4.01, mais est entièrement conforme au standard HTML 5 et sera comprise correctement par tous les navigateurs actuellement utilisés. En théorie, l'élément Meta indiquant l'encodage du document HTML serait mieux placé le plus haut possible dans l'en-tête du document , de sorte qu'au moment où le texte rencontre le premier caractère ne provenant pas de l'ANSI de base (qui est toujours lu correctement et en toute variation), le navigateur devrait déjà avoir des informations sur la manière d'interpréter les codes de ces caractères. Lien vers la source originale : encodage de texte ASCII (Windows 1251, CP866, KOI8-R) et Unicode (UTF 8, 16, 32) - comment résoudre le problème des crackers
ce sont ces 128 caractères de la version originale de l'ASCII qui sont devenus la norme, et dans tout autre encodage vous les retrouverez certainement et ils apparaîtront dans cet ordre. Mais le fait est qu'à l'aide d'un octet d'information, vous pouvez coder non pas 128, mais jusqu'à 256 valeurs différentes (deux puissance huit égale 256), donc, après la version de base d'Asuka, un tout une série d' encodages ASCII étendus est apparue , dans laquelle il était possible, en plus des 128 caractères de base, d'être également codés à l'aide de caractères d'encodage nationaux (par exemple, le russe). Ici, il vaut probablement la peine d’en dire un peu plus sur les systèmes numériques utilisés dans la description. Premièrement, comme vous le savez tous, un ordinateur ne fonctionne qu'avec les nombres du système binaire, c'est-à-dire avec les zéros et les uns (« algèbre booléenne », si quelqu'un l'a suivi dans un institut ou une école). Un octet est constitué de huit bits, dont chacun représente un deux à la puissance deux, en commençant par zéro et jusqu'à deux puissance sept : 
Il n'est pas difficile de comprendre que toutes les combinaisons possibles de zéros et de uns dans une telle construction peuvent seulement 256. Convertir un nombre du système binaire en décimal est assez simple. Il vous suffit d’additionner toutes les puissances de deux avec celles au-dessus. Dans notre exemple, cela s'avère être 1 (2 à la puissance zéro) plus 8 (deux à la puissance 3), plus 32 (deux à la puissance cinq), plus 64 (à la puissance six), plus 128. (à la septième puissance). Le total est de 233 en notation décimale. Comme vous pouvez le constater, tout est très simple. Mais si vous regardez attentivement le tableau avec les caractères ASCII, vous verrez qu'ils sont représentés en codage hexadécimal. Par exemple, « astérisque » correspond au nombre hexadécimal 2A en Aski. Vous savez probablement que dans le système numérique hexadécimal, en plus des chiffres arabes, les lettres latines de A (signifie dix) à F (signifie quinze) sont également utilisées. Eh bien, pour convertir un nombre binaire en hexadécimalrecourir à la méthode simple suivante. Chaque octet d'information est divisé en deux parties de quatre bits. Ceux. Dans chaque demi-octet, seules seize valeurs (deux à la puissance quatre) peuvent être codées en binaire, qui peut facilement être représentée sous forme de nombre hexadécimal. De plus, dans la moitié gauche de l'octet, les degrés devront être recomptés à partir de zéro, et non comme indiqué sur la capture d'écran. En conséquence, nous obtenons que le nombre E9 est codé dans la capture d'écran. J'espère que le déroulement de mon raisonnement et la solution à cette énigme vous ont été clairs. Eh bien, continuons maintenant en parlant des encodages de texte.
Vous voyez, dans la colonne de droite, les chiffres commencent par 8, car les nombres de 0 à 7 font référence à la partie de base de l'ASCII (voir première capture d'écran). Ainsi, la lettre cyrillique « M » dans CP866 aura le code 9C (elle est située à l'intersection de la ligne correspondante avec 9 et de la colonne avec le chiffre C dans le système numérique hexadécimal), qui peut être écrite dans un octet d'information. , et s'il existe une police appropriée avec des caractères russes, cette lettre apparaîtra dans le texte sans aucun problème. D'où vient cette somme ?pseudographiques dans CP866 ? Le fait est que cet encodage du texte russe a été développé au cours de ces années difficiles, où les systèmes d'exploitation graphiques n'étaient pas aussi répandus qu'aujourd'hui. Et dans Dosa et les systèmes d'exploitation de texte similaires, les pseudographies ont permis au moins d'une manière ou d'une autre de diversifier la conception des textes, et donc CP866 et tous ses autres pairs de la catégorie des versions étendues d'Asuka en abondent. CP866 a été distribué par IBM, mais en plus de cela, un certain nombre d'encodages ont été développés pour les caractères de la langue russe, par exemple, KOI8-R peut être attribué au même type (ASCII étendu) : 
Le principe de son fonctionnement reste le même que celui celui du CP866 décrit un peu plus haut - Chaque caractère de texte est codé sur un seul octet. La capture d'écran montre la seconde moitié du tableau KOI8-R, car la première moitié est tout à fait cohérente avec l'Asuka de base, qui est présentée dans la première capture d'écran de cet article. Parmi les caractéristiques de l'encodage KOI8-R, on peut noter que les lettres cyrilliques de son tableau ne sont pas classées par ordre alphabétique, comme cela se faisait dans le CP866. Si vous regardez la toute première capture d'écran (de la partie de base, qui est incluse dans tous les encodages étendus), vous remarquerez que dans KOI8-R les lettres russes sont situées dans les mêmes cellules du tableau que les lettres correspondantes de l'alphabet latin. de la première partie du tableau. Cela a été fait pour faciliter le passage des caractères russes aux caractères latins en supprimant un seul bit (deux à la puissance septième ou 128).
En raison d'une telle abondance d'encodages de la langue russe, les fabricants de polices et les fabricants de logiciels avaient constamment des maux de tête, et vous et moi, chers lecteurs, avons souvent eu des ennuis avec ces mêmes bugs notoires lorsqu'il y a eu confusion avec la version utilisée dans le texte. Très souvent, ils apparaissaient lors de l'envoi et de la réception de messages par courrier électronique, ce qui impliquait la création de tables de conversion très complexes, qui, en fait, ne pouvaient pas résoudre fondamentalement ce problème, et souvent les utilisateurs utilisaient la translittération des lettres latines pour la correspondance afin de évitez le fameux charabia lors de l'utilisation d'encodages russes comme CP866, KOI8-R ou Windows 1251. En fait, les fissures apparaissant à la place du texte russe étaient le résultat d'une mauvaise utilisation de l'encodage d'une langue donnée, qui ne correspondait pas à celui de lequel le message texte a été initialement codé. Disons que si vous essayez d'afficher des caractères codés à l'aide de CP866 à l'aide de la table de codes Windows 1251, alors ce même charabia (un ensemble de caractères dénué de sens) apparaîtra, remplaçant complètement le texte du message. 
Une situation similaire se produit très souvent lors de la création et de la configuration de sites Web, de forums ou de blogs, lorsque du texte contenant des caractères russes est enregistré par erreur dans le mauvais encodage utilisé par défaut sur le site, ou dans le mauvais éditeur de texte, ce qui ajoute un gag invisible. au code à l'œil nu. En fin de compte, beaucoup de gens en ont eu assez de cette situation avec beaucoup d'encodages et des conneries constamment rampantes, et les conditions préalables sont apparues pour la création d'une nouvelle variante universelle qui remplacerait toutes celles existantes et résoudrait le problème de l'apparition de textes illisibles. . De plus, il y avait le problème de langues comme le chinois, où il y avait beaucoup plus de caractères que 256.
Combien de caractères peuvent être codés en UTF-16 en utilisant 16 bits ? 65 536 (deux puissance seize), et c'est le nombre qui a été adopté comme espace de base dans Unicode. De plus, il existe des moyens de coder environ deux millions de caractères en l'utilisant, mais ils étaient limités à un espace étendu d'un million de caractères de texte. Mais même cette version réussie du codage Unicode n'a pas apporté beaucoup de satisfaction à ceux qui écrivaient, par exemple, des programmes uniquement en anglais, car après le passage de la version étendue de l'ASCII à l'UTF-16, le poids des documents a doublé (un octet par caractère en Aski et deux octets pour le même caractère en YUTF-16). C'est précisément pour satisfaire tout le monde au sein du consortium Unicode qu'il a été décidé de proposer un codage à longueur variable . Il s'appelait UTF-8. Malgré le huit dans le nom, il a en réalité une longueur variable, c'est-à-dire Chaque caractère de texte peut être codé dans une séquence de un à six octets. En pratique, UTF-8 n'utilise que la plage de un à quatre octets, car au-delà de quatre octets de code, il n'est même plus théoriquement possible d'imaginer quoi que ce soit. Tous les caractères latins qu'il contient sont codés sur un octet, tout comme dans le bon vieux ASCII. Ce qui est remarquable, c'est que dans le cas de l'encodage uniquement de l'alphabet latin, même les programmes qui ne comprennent pas Unicode liront quand même ce qui est encodé en YTF-8. Autrement dit, la partie de base d'Asuka a simplement été transférée à cette idée originale du consortium Unicode. Les caractères cyrilliques en UTF-8 sont codés sur deux octets et, par exemple, les caractères géorgiens sont codés sur trois octets. Le Consortium Unicode, après avoir créé UTF 16 et 8, a résolu le problème principal : nous avons désormais un seul espace de code dans nos polices . Et maintenant, leurs fabricants ne peuvent le remplir qu'avec des formes vectorielles de caractères de texte en fonction de leurs points forts et de leurs capacités. Dans le « Tableau des caractères » ci-dessus, vous pouvez voir que différentes polices prennent en charge différents nombres de caractères. Certaines polices riches en Unicode peuvent être assez lourdes. Mais maintenant, ils ne diffèrent pas par le fait qu'ils ont été créés pour des encodages différents, mais par le fait que le fabricant de polices a rempli ou pas complètement l'espace de code unique avec certaines formes vectorielles.
Dans le cas d'un site sur Joomla 1.5 et supérieur, comme ainsi que dans le cas d'un blog sur WordPress, vous devez éviter l'apparition de Krakozyabrov en choisissant l' option UTF 8 sans BOM . Quel est le préfixe de la nomenclature ? Le fait est que lorsqu'ils développaient le codage YUTF-16, pour une raison quelconque, ils ont décidé d'y attacher une chose telle que la possibilité d'écrire le code de caractère à la fois en séquence directe (par exemple, 0A15) et en sens inverse (150A). . Et pour que les programmes comprennent dans quel ordre lire les codes, le BOM (Byte Order Mark ou, en d'autres termes, signature) a été inventé, qui se traduisait par l'ajout de trois octets supplémentaires au tout début des documents. Dans l'encodage UTF-8, aucune nomenclature n'était prévue dans le consortium Unicode, et donc l'ajout d'une signature (ces fameux trois octets supplémentaires au début du document) empêche simplement certains programmes de lire le code. Par conséquent, lors de l’enregistrement de fichiers au format UTF, nous devons toujours sélectionner l’option sans nomenclature (sans signature). Ainsi, vous vous protégerez à l'avance des évasions des krakozyabrs . Ce qui est remarquable, c'est que certains programmes sous Windows ne peuvent pas faire cela (ils ne peuvent pas enregistrer de texte au format UTF-8 sans nomenclature), par exemple le même bloc-notes Windows notoire. Il enregistre le document au format UTF-8, mais ajoute toujours la signature (trois octets supplémentaires) au début de celui-ci. De plus, ces octets seront toujours les mêmes - lisez le code en séquence directe. Mais sur les serveurs, à cause de cette petite chose, un problème peut survenir : des escrocs vont apparaître. Par conséquent, n’utilisez en aucun cas le bloc-notes Windows standard.pour éditer des documents sur votre site si vous ne souhaitez pas que des fissures apparaissent. Je considère l'éditeur Notepad++ déjà mentionné comme l'option la meilleure et la plus simple, qui ne présente pratiquement aucun inconvénient et ne présente que des avantages. Dans Notepad++, lorsque vous sélectionnez un encodage, vous aurez la possibilité de convertir le texte en encodage UCS-2, qui est de nature très proche de la norme Unicode. Également dans le Bloc-notes, il sera possible d'encoder du texte en ANSI, c'est-à-dire par rapport à la langue russe, il s'agira de Windows 1251, que nous avons déjà décrit juste au-dessus. D'où viennent ces informations ? Il est enregistré dans le registre de votre système d'exploitation Windows - quel encodage choisir dans le cas d'ANSI, lequel choisir dans le cas d'OEM (pour la langue russe, ce sera CP866). Si vous définissez une autre langue par défaut sur votre ordinateur, ces encodages seront remplacés par des encodages similaires de la catégorie ANSI ou OEM pour cette même langue. Après avoir enregistré le document dans Notepad++ dans l'encodage dont vous avez besoin ou ouvert le document depuis le site pour le modifier, vous pourrez voir son nom dans le coin inférieur droit de l'éditeur : 
Pour éviter toute confusion , en plus des étapes décrites ci-dessus , il sera utile d'écrire le code source dans son en-tête sur toutes les pages du site avec des informations sur ce même encodage, afin qu'il n'y ait pas de confusion sur le serveur ou l'hébergeur local. En général, tous les langages de balisage hypertexte, à l'exception du HTML, utilisent une déclaration XML spéciale, qui spécifie l'encodage du texte.
GO TO FULL VERSION