O que é CODEPAGE e ENCODING – Parte 03

Introdução

No post anterior (O que é CODEPAGE e ENCODING – Parte 02) vimos como o AdvPL trata strings e conversões entre diferentes encodings. Agora, vamos ver … MAIS ENCODINGS 😀

BASE64, o que é e como funciona ?

Imagine que você precisa transportar ou armazenar, por exemplo, uma imagem — pode ser um arquivo no formato BMP, JPG, PNG, GIF, etc — e o arquivo que contém a imagem contém sequencias de bytes de 0 a 255 … mas o meio de transporte que você vai usar — por exemplo um XML — não suporta você colocar isso “direto” dentro do XML como um conteúdo de um node.

Então, existe uma forma de você codificar um buffer binário, com bytes de 0 a 255, usando um alfabeto restrito de 64 bytes da tabela ASCII, chamado de “Base 64”. Na prática, a conversão de uma sequencia de bytes para Base64 consiste em converter cada byte da string para uma sequência binária (aquela sequencia de 0s e 1s), e converter esta sequencia para o alfabeto do Base64 de 6 em 6 bits.

JULIO em base64 é representado por "SlVMSU8="

Em Advpl, existem as funções Encode64() e Decode64(), criadas para converter qualquer string — mesmo em formato binário — para Base64, e vice-versa. Quem utiliza WebServices e precisa trafegar o conteúdo binário de uma imagem normalmente utiliza esta codificação para os dados deste node. Existe um tipo de dado descrito na especificação do SOAP XML para isso.

Este tipo de codificação também pode ser usado em cabeçalhos de requisições HTTP, quando o servidor exige um tipo de autenticação simples, conhecido por “basic access authentication”. O cliente que faz a requisição precisa inserir no HEADER da requisição HTTP uma tag no formato “Authorization: Basic <credentials>”, onde <credentials> é a string contendo o nome do usuário e senha, separados por  “:”, e representado em Base64.

Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l

Hexadecimal e Octal

Finalmente, chegamos nele! A representação hexadecimal consiste em usar um alfabeto restrito de 16 símbolos (daí o seu nome , hexadecimal, ou base 16), para representar 16 valores diferentes — ou 4 bits. Já o octal usa apenas 8 símbolos ( os números de 0 a 7, ou 3 bits) para representar um valor.

Usando a calculadora do Windows (8 ou superior), no modo “Programmer”, podemos entrar com um número nos formatos decimal, hexadecimal, octal ou binário, e ela automaticamente mostra todas as representações deste número. Por exemplo, o número decimal 255 pode ser representado como:

Calculadora - Prog

Em Advpl existem as funções __HEXTODEC() e __DECTOHEX() para fazer as conversões de hexadecimal para decimal e vice-versa.

UTF-16

Devido a diferenças de arquitetura entre equipamentos e plataformas, uma dupla de bytes na memória pode ser representada internamente dentro da máquina com o byte mais significativo do lado direito ou do lado esquerdo. Essa característica chama-se “endianess“, onde algumas plataformas armazenam números inteiros na memória em ordem crescente de peso numérico (little-endian) ou decrescente (big-endian). Por exemplo, as plataformas Intel x86 e x86_64 são little-endian, PowerPC e SPARC são big-endian. Como o UTF-16 trabalha com duplas de bytes ( 16 bits ), é necessário informar qual a ordenação interna a ser usada. Para isso, as funções EncodeUtf16 e DecodeUTF16 do AdvPL possuem um parâmetro adicional para informar se a conversão deve ser de/para Big-endian (default) ou Little-endian.

AdvPL e as funções CHR() e ASC()

Estas funções servem para, respectivamente, retornar um byte em formato de string AdvPL (tipo ‘C’ Caractere), passando o valor do byte, e recuperar o valor do primeiro byte de uma string AdvPL, respectivamente. Por exemplo:

conout(chr(65)+chr(66)+chr(67)) // resultado "ABC"
conout(asc("A")) // resultado 65

CP-1252 e caracteres não suportados

Quando você verifica em detalhes uma tabela de CodePage, como por exemplo a CP-850, existe uma representação gráfica para todos os bytes da faixa superior ( 128 a 255 ). POREM, o CP-1252 possui 5 códigos VAZIOS. Isso mesmo, não usados, sem representação gráfica, e naturalmente inválidos nesta tabela. São eles : 129, 141, 143, 144 e 157

Logo, se você montar uma string em AdvPL com estes caracteres, e enviar para uma classe de interface, no lugar destes caracteres, ou será mostrado um espaço em branco, ou um caractere diferenciado para indicar que não existe representação deste byte. Se você tentar converter um destes caracteres para UTF-8 usando  por exemplo a função EncodeUTF8() do AdvPL, ela vai retornar uma string em branco, indicando uma situação de erro, pois o parâmetro informado contém um byte que não pertence ao CP-1252.

Da mesma forma, como a função DecodeUTF8() pode receber qualquer um dos 107 mil caracteres da tabela Unicode, ela somente vai conseguir converter de UTF-8 para CP-1252 os caracteres que possuam representação no CP-1252.

Eu tenho como descobrir como uma string está codificada ?!

Bem, se você não tiver esta informação… você pode “chutar”, mas isso está muito sujeito a erro. Ao olhar para uma string, se nenhum byte dela é maior que 127, ela contém apenas caracteres da tabela ASCII, mas ela pode ser UTF-8 — afinal se não foi usado nenhum caractere acentuado na string, sua representação será igual. Se a string tiver algum caractere a partir do 128, ela pode ser de algum CodePage, ou mesmo UTF-8. A diferença é que, em UTF-8, a sequência de bytes após o primeiro byte acima de 128 precisa formar uma combinação válida, e quando for usado um codepage — single byte ecoding — cada um desses bytes possui uma representação de um símbolo de acordo com o Codepage esperado que seja usado.

Conclusão

Tudo é bem simples quando usamos apenas letras e números,  mas mesmo assim eles podem ter diferentes significados dependendo do contexto. É a diferença básica entre DADOS e INFORMAÇÕES. Todos os arquivos em um sistema informatizado contém dados, eles apenas são considerados como informações quando você entende o que os dados representam.

Espero que estas informações sejam úteis e esclarecedoras, e desejo a todos TERABYTES DE SUCESSO !!! 

Referências

 

 

 

2 comentários sobre “O que é CODEPAGE e ENCODING – Parte 03

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s