Hoje falaremos sobre a origem dos krakozyabrs em um site e em programas, quais codificações de texto existem e quais devem ser usadas. Vamos dar uma olhada mais de perto na história de seu desenvolvimento, começando com ASCII básico, bem como suas versões estendidas CP866, KOI8-R, Windows 1251 e terminando com as modernas codificações do consórcio Unicode UTF 16 e 8. Índice :
Para alguns, esta informação pode parecer desnecessária, mas você sabe quantas perguntas recebo especificamente sobre os krakozyabrs rastejantes (conjunto de caracteres ilegíveis). Agora terei a oportunidade de encaminhar a todos o texto deste artigo e encontrar meus próprios erros. Pois bem, prepare-se para absorver as informações e tente acompanhar o fluxo da história.
ASCII - codificação básica de texto para o alfabeto latino
O desenvolvimento das codificações de texto ocorreu simultaneamente à formação da indústria de TI e, durante esse período, elas conseguiram passar por muitas mudanças. Historicamente, tudo começou com o EBCDIC, bastante dissonante na pronúncia russa, que possibilitou codificar letras do alfabeto latino, algarismos arábicos e sinais de pontuação com caracteres de controle. Mas ainda assim, o famoso ASCII (American Standard Code for Information Interchange, que em russo é geralmente pronunciado como “ask”) deve ser considerado o ponto de partida para o desenvolvimento de codificações de texto modernas . Ele descreve os primeiros 128 caracteres mais comumente usados por usuários que falam inglês - letras latinas, algarismos arábicos e sinais de pontuação. Esses 128 caracteres descritos em ASCII também incluíam alguns caracteres de serviço, como colchetes, hash, asteriscos, etc. Na verdade, você mesmo pode vê-los: são esses 128 caracteres da versão original do ASCII que se tornaram o padrão, e em qualquer outra codificação você definitivamente os encontrará e eles aparecerão nesta ordem. Mas o fato é que com a ajuda de um byte de informação você pode codificar não 128, mas até 256 valores diferentes (dois elevado a oito é igual a 256), portanto, após a versão básica do Asuka, um todo Apareceu uma série de codificações ASCII estendidas , nas quais era possível, além dos 128 caracteres básicos, também poderem ser codificados usando caracteres de codificação nacionais (por exemplo, russo). Aqui, provavelmente vale a pena falar um pouco mais sobre os sistemas numéricos usados na descrição. Em primeiro lugar, como todos sabem, um computador só funciona com números do sistema binário, nomeadamente com zeros e uns (“álgebra booleana”, se alguém o fez num instituto ou escola). Um byte consiste em oito bits, cada um dos quais representa dois elevado a dois, começando de zero e até dois elevado ao sétimo: Não é difícil entender que todas as combinações possíveis de zeros e uns em tal construção podem ser apenas 256. Converter um número do sistema binário para decimal é bastante simples. Você só precisa somar todas as potências de dois com as unidades acima delas. No nosso exemplo, isso resulta em 1 (2 elevado a zero) mais 8 (dois elevado a 3), mais 32 (dois elevado a quinta potência), mais 64 (elevado a sexta potência), mais 128 (elevado à sétima potência). O total é 233 em notação decimal. Como você pode ver, tudo é muito simples. Mas se você observar atentamente a tabela com caracteres ASCII, verá que eles são representados em codificação hexadecimal. Por exemplo, "asterisco" corresponde ao número hexadecimal 2A em Aski. Você provavelmente sabe que no sistema numérico hexadecimal, além dos algarismos arábicos, também são usadas letras latinas de A (significa dez) a F (significa quinze). Bem, para converter um número binário em hexadecimalrecorra ao seguinte método simples. Cada byte de informação é dividido em duas partes de quatro bits. Aqueles. Em cada meio byte, apenas dezesseis valores (dois elevado a quarta potência) podem ser codificados em binário, que pode ser facilmente representado como um número hexadecimal. Além disso, na metade esquerda do byte, os graus deverão ser contados novamente começando do zero, e não conforme mostrado na imagem. Como resultado, obtemos que o número E9 está codificado na captura de tela. Espero que o curso do meu raciocínio e a solução desse quebra-cabeça tenham ficado claros para você. Bem, agora vamos continuar, de fato, falando sobre codificações de texto.
Versões estendidas de Asuka - codificações CP866 e KOI8-R com pseudográficos
Então, começamos a falar sobre ASCII, que foi, por assim dizer, o ponto de partida para o desenvolvimento de todas as codificações modernas (Windows 1251, Unicode, UTF 8). Inicialmente continha apenas 128 caracteres do alfabeto latino, algarismos arábicos e algo mais, mas na versão estendida tornou-se possível utilizar todos os 256 valores que podem ser codificados em um byte de informação. Aqueles. Tornou-se possível adicionar símbolos de letras do seu idioma ao Aski. Aqui precisaremos divagar mais uma vez para explicar por que as codificações de texto são necessárias e por que elas são tão importantes. Os caracteres na tela do seu computador são formados com base em duas coisas - conjuntos de formas vetoriais (representações) de vários caracteres (eles estão em arquivos com fontes instaladas no seu computador) e um código que permite extrair exatamente aquele deste conjunto de formas vetoriais (arquivo de fonte) símbolo que precisará ser inserido no lugar certo. É claro que as próprias fontes são responsáveis pelas formas vetoriais, mas o sistema operacional e os programas nela utilizados são responsáveis pela codificação. Aqueles. qualquer texto no seu computador será um conjunto de bytes, cada um dos quais codifica um único caractere desse mesmo texto. O programa que exibe este texto na tela (editor de texto, navegador, etc.), ao analisar o código, lê a codificação do próximo caractere e procura a forma vetorial correspondente no arquivo de fonte necessário, que está conectado para exibir este documento de texto. Tudo é simples e banal. Isso significa que para codificar qualquer caractere que necessitamos (por exemplo, do alfabeto nacional), duas condições devem ser atendidas: a forma vetorial deste caractere deve estar na fonte usada, e este caractere pode ser codificado em codificações ASCII estendidas. em um byte. Portanto, existem muitas dessas opções. Apenas para codificar caracteres do idioma russo, existem diversas variedades de Aska estendido. Por exemplo, apareceu originalmente o CP866 , que tinha a capacidade de usar caracteres do alfabeto russo e era uma versão estendida do ASCII. Ou seja, sua parte superior coincidia totalmente com a versão básica do Aska (128 caracteres latinos, números e outras porcarias), que é apresentada na imagem logo acima, mas a parte inferior da tabela com codificação CP866 tinha a aparência indicada no captura de tela logo abaixo e permitiu codificar outros 128 caracteres (letras russas e todos os tipos de pseudo-gráficos): Veja, na coluna da direita os números começam com 8, porque os números de 0 a 7 referem-se à parte básica do ASCII (veja a primeira imagem). Assim, a letra cirílica “M” no CP866 terá o código 9C (está localizado na intersecção da linha correspondente com 9 e coluna com o número C no sistema de numeração hexadecimal), que pode ser escrito em um byte de informação , e se houver uma fonte adequada com caracteres russos, esta letra aparecerá no texto sem problemas. De onde veio esse valor?pseudográficos em CP866 ? A questão toda é que essa codificação para texto russo foi desenvolvida naqueles anos difíceis, quando os sistemas operacionais gráficos não eram tão difundidos como agora. E no Dosa e em sistemas operacionais de texto semelhantes, os pseudográficos tornaram possível diversificar de alguma forma o design dos textos e, portanto, o CP866 e todos os seus outros pares da categoria de versões estendidas do Asuka são abundantes nele. CP866 foi distribuído pela IBM, mas além disso, uma série de codificações foram desenvolvidas para caracteres do idioma russo, por exemplo, KOI8-R pode ser atribuído ao mesmo tipo (ASCII estendido) : O princípio de sua operação permanece o mesmo que o do CP866 descrito um pouco antes - Cada caractere de texto é codificado como um único byte. A captura de tela mostra a segunda metade da tabela KOI8-R, porque a primeira metade é totalmente consistente com o Asuka básico, mostrado na primeira imagem deste artigo. Dentre as características da codificação KOI8-R, pode-se notar que as letras cirílicas de sua tabela não estão em ordem alfabética, como foi feito no CP866. Se você olhar a primeira captura de tela (da parte básica, que está incluída em todas as codificações estendidas), notará que em KOI8-R as letras russas estão localizadas nas mesmas células da tabela que as letras correspondentes do alfabeto latino da primeira parte da tabela. Isso foi feito para a conveniência de mudar de caracteres russos para latinos, descartando apenas um bit (dois elevado à sétima potência ou 128).
Windows 1251 - a versão moderna do ASCII e por que surgem as rachaduras
O desenvolvimento adicional de codificações de texto deveu-se ao fato de que os sistemas operacionais gráficos estavam ganhando popularidade e a necessidade de usar pseudográficos neles desapareceu com o tempo. Como resultado, surgiu todo um grupo que, em essência, ainda eram versões estendidas de Asuka (um caractere de texto é codificado com apenas um byte de informação), mas sem o uso de símbolos pseudográficos. Eles pertenciam às chamadas codificações ANSI, desenvolvidas pelo American Standards Institute. Na linguagem comum, o nome cirílico também foi usado para a versão com suporte ao idioma russo. Um exemplo disso seria o Windows 1251 . Ele diferia favoravelmente do CP866 e KOI8-R usados anteriormente, pois o lugar dos símbolos pseudográficos nele era ocupado pelos símbolos ausentes da tipografia russa (exceto o acento), bem como pelos símbolos usados em línguas eslavas próximas a Russo (ucraniano, bielorrusso, etc.): Devido à abundância de codificações do idioma russo, os fabricantes de fontes e de software constantemente tinham dores de cabeça, e você e eu, queridos leitores, muitas vezes tivemos problemas com esses mesmos bugs notórios quando houve confusão com a versão utilizada no texto. Muitas vezes surgiam no envio e recebimento de mensagens por e-mail, o que implicava a criação de tabelas de conversão muito complexas, o que, de fato, não conseguia resolver fundamentalmente este problema, e muitas vezes os usuários utilizavam a transliteração de letras latinas para correspondência, a fim de evite o notório jargão ao usar codificações russas como CP866, KOI8-R ou Windows 1251. Na verdade, as rachaduras que apareciam no lugar do texto russo eram resultado do uso incorreto da codificação de um determinado idioma, que não correspondia àquela em qual a mensagem de texto foi originalmente codificada. Digamos que se você tentar exibir caracteres codificados usando CP866 usando a tabela de códigos do Windows 1251, então esses mesmos jargões (um conjunto de caracteres sem sentido) aparecerão, substituindo completamente o texto da mensagem. Uma situação semelhante surge muitas vezes ao criar e configurar sites, fóruns ou blogs, quando o texto com caracteres russos é salvo por engano na codificação errada usada no site por padrão, ou no editor de texto errado, que adiciona uma mordaça invisível ao código a olho nu. No final, muita gente se cansou dessa situação com muitas codificações e porcarias constantemente assustadoras, e surgiram os pré-requisitos para a criação de uma nova variação universal que substituiria todas as existentes e resolveria o problema com o aparecimento de textos ilegíveis . Além disso, havia o problema de idiomas como o chinês, onde havia muito mais caracteres do idioma do que 256.
Unicode - codificações universais UTF 8, 16 e 32
Esses milhares de caracteres do grupo de idiomas do Sudeste Asiático não poderiam ser descritos em um byte de informação alocado para codificação de caracteres em versões estendidas de ASCII. Como resultado, um consórcio chamado Unicode (Consórcio Unicode) foi criado com a cooperação de muitos líderes da indústria de TI (aqueles que produzem software, que codificam hardware, que criam fontes) que estavam interessados no surgimento de uma codificação de texto universal. A primeira variação lançada sob os auspícios do Unicode Consortium foi UTF 32 . O número no nome da codificação significa o número de bits usados para codificar um caractere. 32 bits equivalem a 4 bytes de informação que serão necessários para codificar um único caractere na nova codificação UTF universal. Com isso, o mesmo arquivo com texto codificado na versão estendida de ASCII e em UTF-32, neste último caso, terá tamanho (peso) quatro vezes maior. Isso é ruim, mas agora temos a oportunidade de codificar usando UTF um número de caracteres igual a dois elevado a trinta segundos ( bilhões de caracteres que cobrirão qualquer valor realmente necessário com uma margem colossal). Mas muitos países com idiomas do grupo europeu não precisavam usar um número tão grande de caracteres na codificação, porém, ao usar UTF-32, sem motivo receberam um aumento de quatro vezes no peso dos documentos de texto, e como resultado, um aumento no volume de tráfego da Internet e no volume de dados armazenados. Isso é muito e ninguém poderia arcar com esse desperdício. Como resultado do desenvolvimento do Unicode, surgiu o UTF-16 , que fez tanto sucesso que foi adotado por padrão como espaço base para todos os caracteres que utilizamos. Ele usa dois bytes para codificar um caractere. Vamos ver como fica essa coisa. No sistema operacional Windows, você pode seguir o caminho “Iniciar” - “Programas” - “Acessórios” - “Ferramentas do Sistema” - “Tabela de Caracteres”. Como resultado, será aberta uma tabela com as formas vetoriais de todas as fontes instaladas em seu sistema. Se você selecionar o conjunto de caracteres Unicode nas “Opções avançadas”, poderá ver para cada fonte separadamente toda a gama de caracteres nela incluídos. Aliás, clicando em qualquer um deles, você pode ver seu código de dois bytes no formato UTF-16 , composto por quatro dígitos hexadecimais: Quantos caracteres podem ser codificados em UTF-16 usando 16 bits? 65.536 (dois elevado a dezesseis), e este é o número que foi adotado como espaço base no Unicode. Além disso, existem maneiras de codificar cerca de dois milhões de caracteres usando-o, mas elas estavam limitadas a um espaço expandido de um milhão de caracteres de texto. Mas mesmo esta versão bem-sucedida da codificação Unicode não trouxe muita satisfação para quem escreveu, digamos, programas apenas em inglês, porque após a transição da versão estendida do ASCII para o UTF-16, o peso dos documentos dobrou (um byte por caractere em Aski e dois bytes para o mesmo caractere em YUTF-16). Foi precisamente para satisfazer tudo e todos no consórcio Unicode que se decidiu criar uma codificação de comprimento variável . Foi chamado de UTF-8. Apesar do oito no nome, na verdade ele tem um comprimento variável, ou seja, Cada caractere de texto pode ser codificado em uma sequência de um a seis bytes de comprimento. Na prática, o UTF-8 utiliza apenas o intervalo de um a quatro bytes, pois além de quatro bytes de código não é mais possível nem teoricamente imaginar nada. Todos os caracteres latinos nele são codificados em um byte, assim como no bom e velho ASCII. O que chama a atenção é que no caso de codificação apenas do alfabeto latino, mesmo aqueles programas que não entendem Unicode ainda lerão o que está codificado em YTF-8. Ou seja, a parte básica do Asuka foi simplesmente transferida para esta ideia do consórcio Unicode. Os caracteres cirílicos em UTF-8 são codificados em dois bytes e, por exemplo, os caracteres georgianos são codificados em três bytes. O Consórcio Unicode, após criar UTF 16 e 8, resolveu o problema principal - agora temos um único espaço de código em nossas fontes . E agora seus fabricantes só podem preenchê-lo com formas vetoriais de caracteres de texto com base em seus pontos fortes e capacidades. Na “Tabela de Caracteres” acima você pode ver que diferentes fontes suportam diferentes números de caracteres. Algumas fontes ricas em Unicode podem ser bastante pesadas. Mas agora eles diferem não porque foram criados para codificações diferentes, mas porque o fabricante da fonte preencheu ou não completamente o espaço de código único com certas formas vetoriais.
Palavras malucas em vez de letras russas - como consertar
Vamos agora ver como os krakozyabrs aparecem em vez do texto ou, em outras palavras, como a codificação correta para o texto russo é selecionada. Na verdade, ele é definido no programa no qual você cria ou edita esse mesmo texto, ou codifica usando fragmentos de texto. Para editar e criar arquivos de texto, eu pessoalmente uso um editor HTML e PHP muito bom, na minha opinião, Notepad++ . No entanto, ele pode destacar a sintaxe de centenas de outras linguagens de programação e marcação e também pode ser estendido por meio de plug-ins. Leia uma análise detalhada deste maravilhoso programa no link fornecido. No menu superior do Notepad++ existe um item “Codificações”, onde você terá a oportunidade de converter uma opção existente naquela que é usada por padrão em seu site: No caso de um site em Joomla 1.5 e superior, como assim como no caso de um blog no WordPress, você deve evitar a aparência de Krakozyabrov escolher a opção UTF 8 sem BOM . Qual é o prefixo da lista técnica? O fato é que quando eles estavam desenvolvendo a codificação YUTF-16, por algum motivo decidiram anexar a ela a capacidade de escrever o código do caractere tanto em sequência direta (por exemplo, 0A15) quanto em sentido inverso (150A) . E para que os programas entendessem em que sequência ler os códigos, foi inventado o BOM (Byte Order Mark ou, em outras palavras, assinatura), que se expressava na adição de três bytes adicionais logo no início dos documentos. Na codificação UTF-8, nenhuma lista técnica foi fornecida no consórcio Unicode e, portanto, adicionar uma assinatura (aqueles notórios três bytes extras no início do documento) simplesmente impede que alguns programas leiam o código. Portanto, ao salvar arquivos em UTF, devemos sempre selecionar a opção sem BOM (sem assinatura). Assim, você se protegerá antecipadamente contra o rastejamento dos krakozyabrs . O que chama a atenção é que alguns programas do Windows não podem fazer isso (não podem salvar texto em UTF-8 sem BOM), por exemplo, o mesmo notório Bloco de Notas do Windows. Ele salva o documento em UTF-8, mas ainda adiciona a assinatura (três bytes extras) ao início dele. Além disso, esses bytes serão sempre os mesmos - leia o código em sequência direta. Mas nos servidores, por causa dessa coisinha, pode surgir um problema - bandidos aparecerão. Portanto, não use o Bloco de Notas normal do Windows em nenhuma circunstância.para editar documentos em seu site se não quiser que nenhuma rachadura apareça. Considero o já citado editor Notepad++ a melhor e mais simples opção, que praticamente não tem inconvenientes e consiste apenas em vantagens. No Notepad++, ao selecionar uma codificação, você terá a opção de converter texto para a codificação UCS-2, que é de natureza muito próxima do padrão Unicode. Também no Bloco de Notas será possível codificar texto em ANSI, ou seja, em relação ao idioma russo, será o Windows 1251, que já descrevemos acima, de onde vem essa informação? Está registrado no registro do seu sistema operacional Windows - qual codificação escolher no caso de ANSI, qual escolher no caso de OEM (para o idioma russo será CP866). Se você definir outro idioma padrão em seu computador, essas codificações serão substituídas por outras semelhantes da categoria ANSI ou OEM para esse mesmo idioma. Após salvar o documento no Notepad++ na codificação necessária ou abrir o documento do site para edição, você poderá ver seu nome no canto inferior direito do editor: Para evitar confusão , além dos passos descritos acima , será útil escrever no código-fonte em seu cabeçalho todas as páginas do site informações sobre essa mesma codificação, para que não haja confusão no servidor ou host local. Em geral, todas as linguagens de marcação de hipertexto, exceto HTML, usam uma declaração xml especial, que especifica a codificação do texto.
<?xml version="1.0" encoding="windows-1251"?>
Antes de analisar o código, o navegador sabe qual versão está sendo usada e como exatamente ele precisa interpretar os códigos de caracteres daquela linguagem. Mas o que chama a atenção é que se você salvar o documento no Unicode padrão, essa declaração xml poderá ser omitida (a codificação será considerada UTF-8 se não houver BOM ou UTF-16 se houver BOM). No caso de um documento HTML, o elemento Meta é utilizado para indicar a codificação , que é colocada entre as tags Head de abertura e fechamento:
<head>...<meta charset="utf-8">...</head>
Esta entrada é bastante diferente do padrão HTML 4.01, mas está em total conformidade com o padrão HTML 5 e será entendida corretamente por qualquer navegador usado atualmente. Em teoria, o elemento Meta que indica a codificação do documento HTML seria melhor colocado o mais alto possível no cabeçalho do documento , para que no momento em que o texto encontrasse o primeiro caractere que não fosse do ANSI básico (que é sempre lido corretamente e em qualquer variação), o navegador já deverá ter informações sobre como interpretar os códigos desses caracteres. Link para a fonte original: codificação de texto ASCII (Windows 1251, CP866, KOI8-R) e Unicode (UTF 8, 16, 32) - como resolver o problema com crackers
são esses 128 caracteres da versão original do ASCII que se tornaram o padrão, e em qualquer outra codificação você definitivamente os encontrará e eles aparecerão nesta ordem. Mas o fato é que com a ajuda de um byte de informação você pode codificar não 128, mas até 256 valores diferentes (dois elevado a oito é igual a 256), portanto, após a versão básica do Asuka, um todo Apareceu uma série de codificações ASCII estendidas , nas quais era possível, além dos 128 caracteres básicos, também poderem ser codificados usando caracteres de codificação nacionais (por exemplo, russo). Aqui, provavelmente vale a pena falar um pouco mais sobre os sistemas numéricos usados na descrição. Em primeiro lugar, como todos sabem, um computador só funciona com números do sistema binário, nomeadamente com zeros e uns (“álgebra booleana”, se alguém o fez num instituto ou escola). Um byte consiste em oito bits, cada um dos quais representa dois elevado a dois, começando de zero e até dois elevado ao sétimo: 
Não é difícil entender que todas as combinações possíveis de zeros e uns em tal construção podem ser apenas 256. Converter um número do sistema binário para decimal é bastante simples. Você só precisa somar todas as potências de dois com as unidades acima delas. No nosso exemplo, isso resulta em 1 (2 elevado a zero) mais 8 (dois elevado a 3), mais 32 (dois elevado a quinta potência), mais 64 (elevado a sexta potência), mais 128 (elevado à sétima potência). O total é 233 em notação decimal. Como você pode ver, tudo é muito simples. Mas se você observar atentamente a tabela com caracteres ASCII, verá que eles são representados em codificação hexadecimal. Por exemplo, "asterisco" corresponde ao número hexadecimal 2A em Aski. Você provavelmente sabe que no sistema numérico hexadecimal, além dos algarismos arábicos, também são usadas letras latinas de A (significa dez) a F (significa quinze). Bem, para converter um número binário em hexadecimalrecorra ao seguinte método simples. Cada byte de informação é dividido em duas partes de quatro bits. Aqueles. Em cada meio byte, apenas dezesseis valores (dois elevado a quarta potência) podem ser codificados em binário, que pode ser facilmente representado como um número hexadecimal. Além disso, na metade esquerda do byte, os graus deverão ser contados novamente começando do zero, e não conforme mostrado na imagem. Como resultado, obtemos que o número E9 está codificado na captura de tela. Espero que o curso do meu raciocínio e a solução desse quebra-cabeça tenham ficado claros para você. Bem, agora vamos continuar, de fato, falando sobre codificações de texto.
Veja, na coluna da direita os números começam com 8, porque os números de 0 a 7 referem-se à parte básica do ASCII (veja a primeira imagem). Assim, a letra cirílica “M” no CP866 terá o código 9C (está localizado na intersecção da linha correspondente com 9 e coluna com o número C no sistema de numeração hexadecimal), que pode ser escrito em um byte de informação , e se houver uma fonte adequada com caracteres russos, esta letra aparecerá no texto sem problemas. De onde veio esse valor?pseudográficos em CP866 ? A questão toda é que essa codificação para texto russo foi desenvolvida naqueles anos difíceis, quando os sistemas operacionais gráficos não eram tão difundidos como agora. E no Dosa e em sistemas operacionais de texto semelhantes, os pseudográficos tornaram possível diversificar de alguma forma o design dos textos e, portanto, o CP866 e todos os seus outros pares da categoria de versões estendidas do Asuka são abundantes nele. CP866 foi distribuído pela IBM, mas além disso, uma série de codificações foram desenvolvidas para caracteres do idioma russo, por exemplo, KOI8-R pode ser atribuído ao mesmo tipo (ASCII estendido) : 
O princípio de sua operação permanece o mesmo que o do CP866 descrito um pouco antes - Cada caractere de texto é codificado como um único byte. A captura de tela mostra a segunda metade da tabela KOI8-R, porque a primeira metade é totalmente consistente com o Asuka básico, mostrado na primeira imagem deste artigo. Dentre as características da codificação KOI8-R, pode-se notar que as letras cirílicas de sua tabela não estão em ordem alfabética, como foi feito no CP866. Se você olhar a primeira captura de tela (da parte básica, que está incluída em todas as codificações estendidas), notará que em KOI8-R as letras russas estão localizadas nas mesmas células da tabela que as letras correspondentes do alfabeto latino da primeira parte da tabela. Isso foi feito para a conveniência de mudar de caracteres russos para latinos, descartando apenas um bit (dois elevado à sétima potência ou 128).
Devido à abundância de codificações do idioma russo, os fabricantes de fontes e de software constantemente tinham dores de cabeça, e você e eu, queridos leitores, muitas vezes tivemos problemas com esses mesmos bugs notórios quando houve confusão com a versão utilizada no texto. Muitas vezes surgiam no envio e recebimento de mensagens por e-mail, o que implicava a criação de tabelas de conversão muito complexas, o que, de fato, não conseguia resolver fundamentalmente este problema, e muitas vezes os usuários utilizavam a transliteração de letras latinas para correspondência, a fim de evite o notório jargão ao usar codificações russas como CP866, KOI8-R ou Windows 1251. Na verdade, as rachaduras que apareciam no lugar do texto russo eram resultado do uso incorreto da codificação de um determinado idioma, que não correspondia àquela em qual a mensagem de texto foi originalmente codificada. Digamos que se você tentar exibir caracteres codificados usando CP866 usando a tabela de códigos do Windows 1251, então esses mesmos jargões (um conjunto de caracteres sem sentido) aparecerão, substituindo completamente o texto da mensagem. 
Uma situação semelhante surge muitas vezes ao criar e configurar sites, fóruns ou blogs, quando o texto com caracteres russos é salvo por engano na codificação errada usada no site por padrão, ou no editor de texto errado, que adiciona uma mordaça invisível ao código a olho nu. No final, muita gente se cansou dessa situação com muitas codificações e porcarias constantemente assustadoras, e surgiram os pré-requisitos para a criação de uma nova variação universal que substituiria todas as existentes e resolveria o problema com o aparecimento de textos ilegíveis . Além disso, havia o problema de idiomas como o chinês, onde havia muito mais caracteres do idioma do que 256.
Quantos caracteres podem ser codificados em UTF-16 usando 16 bits? 65.536 (dois elevado a dezesseis), e este é o número que foi adotado como espaço base no Unicode. Além disso, existem maneiras de codificar cerca de dois milhões de caracteres usando-o, mas elas estavam limitadas a um espaço expandido de um milhão de caracteres de texto. Mas mesmo esta versão bem-sucedida da codificação Unicode não trouxe muita satisfação para quem escreveu, digamos, programas apenas em inglês, porque após a transição da versão estendida do ASCII para o UTF-16, o peso dos documentos dobrou (um byte por caractere em Aski e dois bytes para o mesmo caractere em YUTF-16). Foi precisamente para satisfazer tudo e todos no consórcio Unicode que se decidiu criar uma codificação de comprimento variável . Foi chamado de UTF-8. Apesar do oito no nome, na verdade ele tem um comprimento variável, ou seja, Cada caractere de texto pode ser codificado em uma sequência de um a seis bytes de comprimento. Na prática, o UTF-8 utiliza apenas o intervalo de um a quatro bytes, pois além de quatro bytes de código não é mais possível nem teoricamente imaginar nada. Todos os caracteres latinos nele são codificados em um byte, assim como no bom e velho ASCII. O que chama a atenção é que no caso de codificação apenas do alfabeto latino, mesmo aqueles programas que não entendem Unicode ainda lerão o que está codificado em YTF-8. Ou seja, a parte básica do Asuka foi simplesmente transferida para esta ideia do consórcio Unicode. Os caracteres cirílicos em UTF-8 são codificados em dois bytes e, por exemplo, os caracteres georgianos são codificados em três bytes. O Consórcio Unicode, após criar UTF 16 e 8, resolveu o problema principal - agora temos um único espaço de código em nossas fontes . E agora seus fabricantes só podem preenchê-lo com formas vetoriais de caracteres de texto com base em seus pontos fortes e capacidades. Na “Tabela de Caracteres” acima você pode ver que diferentes fontes suportam diferentes números de caracteres. Algumas fontes ricas em Unicode podem ser bastante pesadas. Mas agora eles diferem não porque foram criados para codificações diferentes, mas porque o fabricante da fonte preencheu ou não completamente o espaço de código único com certas formas vetoriais.
No caso de um site em Joomla 1.5 e superior, como assim como no caso de um blog no WordPress, você deve evitar a aparência de Krakozyabrov escolher a opção UTF 8 sem BOM . Qual é o prefixo da lista técnica? O fato é que quando eles estavam desenvolvendo a codificação YUTF-16, por algum motivo decidiram anexar a ela a capacidade de escrever o código do caractere tanto em sequência direta (por exemplo, 0A15) quanto em sentido inverso (150A) . E para que os programas entendessem em que sequência ler os códigos, foi inventado o BOM (Byte Order Mark ou, em outras palavras, assinatura), que se expressava na adição de três bytes adicionais logo no início dos documentos. Na codificação UTF-8, nenhuma lista técnica foi fornecida no consórcio Unicode e, portanto, adicionar uma assinatura (aqueles notórios três bytes extras no início do documento) simplesmente impede que alguns programas leiam o código. Portanto, ao salvar arquivos em UTF, devemos sempre selecionar a opção sem BOM (sem assinatura). Assim, você se protegerá antecipadamente contra o rastejamento dos krakozyabrs . O que chama a atenção é que alguns programas do Windows não podem fazer isso (não podem salvar texto em UTF-8 sem BOM), por exemplo, o mesmo notório Bloco de Notas do Windows. Ele salva o documento em UTF-8, mas ainda adiciona a assinatura (três bytes extras) ao início dele. Além disso, esses bytes serão sempre os mesmos - leia o código em sequência direta. Mas nos servidores, por causa dessa coisinha, pode surgir um problema - bandidos aparecerão. Portanto, não use o Bloco de Notas normal do Windows em nenhuma circunstância.para editar documentos em seu site se não quiser que nenhuma rachadura apareça. Considero o já citado editor Notepad++ a melhor e mais simples opção, que praticamente não tem inconvenientes e consiste apenas em vantagens. No Notepad++, ao selecionar uma codificação, você terá a opção de converter texto para a codificação UCS-2, que é de natureza muito próxima do padrão Unicode. Também no Bloco de Notas será possível codificar texto em ANSI, ou seja, em relação ao idioma russo, será o Windows 1251, que já descrevemos acima, de onde vem essa informação? Está registrado no registro do seu sistema operacional Windows - qual codificação escolher no caso de ANSI, qual escolher no caso de OEM (para o idioma russo será CP866). Se você definir outro idioma padrão em seu computador, essas codificações serão substituídas por outras semelhantes da categoria ANSI ou OEM para esse mesmo idioma. Após salvar o documento no Notepad++ na codificação necessária ou abrir o documento do site para edição, você poderá ver seu nome no canto inferior direito do editor: 
Para evitar confusão , além dos passos descritos acima , será útil escrever no código-fonte em seu cabeçalho todas as páginas do site informações sobre essa mesma codificação, para que não haja confusão no servidor ou host local. Em geral, todas as linguagens de marcação de hipertexto, exceto HTML, usam uma declaração xml especial, que especifica a codificação do texto.
GO TO FULL VERSION