Sobre o tutorial

[eibon 2]

De jeito algum...de uma olhadinha meu caro:

Often a hash digest is stored as the ASCII representation of hex digits, for example MD5 of the word 'hash' is:

 

0800fc577294c34e0b28ad2839435945

 

This is a 32-character ASCII string.

 

But MD5 really produces a 128-bit binary hash value. This should require only 16 bytes to be stored as binary values instead of hex digits. So you can gain some space efficiency by using binary strings.

 

CREATE TABLE test.foobar (

id BINARY(16) NOT NULL PRIMARY KEY

);

 

INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));

Meu deus...>.<

O próprio comentário que o cara posta pra ir contra mim...vai contra ele.

[Tarantula 0]

Nenhum post é contra você, é contra a tua teimosia, que você ainda não se deu conta.

 

Você teimou que MD5 tem SEMPRE 32 caracteres e tanto é que disse para usar CHAR de 32 bytes no MySQL, o post que mandei fala sobre o que acontece na verdade, que o MD5 tem 16 caracteres e ocupa 128 bits.

 

Na próxima é melhor não mandar posts chamando os usuários de "animal" e apagar depois ok ?

 

Sem mais.

[eibon 2]

O cara nem le o que ele manda...

http://stackoverflow.com/questions/504268/...ry-for-hash-ids

 

ocp h = 4bits
2*(ocp h) = 8bits = 1byte
ocp c = 8bits = 1byte

#h: Valor Hexadecimal
#c: Caracter
#ocp: Espaço ocupado na memória
#8bits = 1byte
#exemplos:
#dec->0|hex->00;dec->255;hex->FF; 0-9 - A-F [0 a 16(hexa)]
#-Valor Hexadecimal: F[4bits] + F[4bits] = FF[1byte]
#-Representação em String: 'F'[1byte] + 'F'[1byte] = 'FF'[2bytes]

 

Um caracter representando um valor hexadecimal vai ocupar o dobro de memória que o mesmo.A len no caso seria a quantidade de bytes que aquela string ocupa...chegamos a conclusão então...

E diga-me um tipo do seu banco de dados que grave um valor em HEX e não sua representação em outro tipo.

---

Você teimou que MD5 tem SEMPRE 32 caracteres e tanto é que disse para usar CHAR de 32 bytes no MySQL, o post que mandei fala sobre o que acontece na verdade, que o MD5 tem 16 caracteres e ocupa 128 bits.

Repito: desde quando dois valores hexadecimais são um caracter?

[Wilker 3]

dexa eu me meter um poko...

 

MD5 = Hash de 128 bits

 

128 bits = 16 bytes (128 / 8)

 

de fato, eh possivel ter essa representacao em 16 caracteres, mas... isso tem um problema grave, porque existe um enorme risco (que vai ocorrer praticamente sempre) que eh de voce ter valores fora dos caracteres padrao ascii (utilizando caracteres de controle, e nao os caracteres apresentaveis), os caracteres de controle nunca devem ser guardados em campos de texto limpo (como campos char/varchar) pois podem causar mtos problemas dependendo da foram de leitura de strings utilizadas por uma linguagem/biblioteca em especifico. dado esse motivo meio que criou-se a regra de guardar os caracteres hexadecimais no lugar dos dados "raw", por isso temos como regra o uso de 32 caracteres, garantindo assim que teremos apenas caracteres legiveis, que nao irao causar problemas dependendo da linguagem/biblioteca. por isso como regra geral, deve-se utilizar 32 caracteres para guardar hashs desse tipo.

 

e tenho dito =p

[Tarantula 0]

Por isso se usa BINARY ao invés de CHAR ou VARCHAR, por acaso os usuários vão ler o MD5 haha ? Enfim, mais um concordando que MD5 nem SEMPRE tem 32 caracteres.

 

dexa eu me meter um poko...

 

MD5 = Hash de 128 bits

 

128 bits = 16 bytes (128 / 8)

 

de fato, eh possivel ter essa representacao em 16 caracteres, mas... isso tem um problema grave, porque existe um enorme risco (que vai ocorrer praticamente sempre) que eh de voce ter valores fora dos caracteres padrao ascii (utilizando caracteres de controle, e nao os caracteres apresentaveis), os caracteres de controle nunca devem ser guardados em campos de texto limpo (como campos char/varchar) pois podem causar mtos problemas dependendo da foram de leitura de strings utilizadas por uma linguagem/biblioteca em especifico. dado esse motivo meio que criou-se a regra de guardar os caracteres hexadecimais no lugar dos dados "raw", por isso temos como regra o uso de 32 caracteres, garantindo assim que teremos apenas caracteres legiveis, que nao irao causar problemas dependendo da linguagem/biblioteca. por isso como regra geral, deve-se utilizar 32 caracteres para guardar hashs desse tipo.

 

e tenho dito =p

[eibon 2]

 

Interpreta direito rapaz.

 

O valor hexadecimal gerado por esse algoritmo pode ser gravado em 16bytes (não...não são caracteres).

Já a representação como string desse valor não.

[Wilker 3]

Por isso se usa BINARY ao invés de CHAR ou VARCHAR, por acaso os usuários vão ler o MD5 haha ? Enfim, mais um concordando que MD5 nem SEMPRE tem 32 caracteres.

 

dexa eu me meter um poko...

 

MD5 = Hash de 128 bits

 

128 bits = 16 bytes (128 / 8)

 

de fato, eh possivel ter essa representacao em 16 caracteres, mas... isso tem um problema grave, porque existe um enorme risco (que vai ocorrer praticamente sempre) que eh de voce ter valores fora dos caracteres padrao ascii (utilizando caracteres de controle, e nao os caracteres apresentaveis), os caracteres de controle nunca devem ser guardados em campos de texto limpo (como campos char/varchar) pois podem causar mtos problemas dependendo da foram de leitura de strings utilizadas por uma linguagem/biblioteca em especifico. dado esse motivo meio que criou-se a regra de guardar os caracteres hexadecimais no lugar dos dados "raw", por isso temos como regra o uso de 32 caracteres, garantindo assim que teremos apenas caracteres legiveis, que nao irao causar problemas dependendo da linguagem/biblioteca. por isso como regra geral, deve-se utilizar 32 caracteres para guardar hashs desse tipo.

 

e tenho dito =p

agora kra, outro detalhe a favor de usar 32 bytes, um exemplo eh o phpMyAdmin, dado a preferencia dos 32 bytes, qdo você usa o phpMyAdmin (maior gerenciador de bancos online pra PHP) e manda ele gerar um valor pra md5, ele gera o hexa e nao o raw, assim como a lib do PHP e varias outras libs (como a do Python), eles tem uma razao para retornar o hexa, e eh como eu expliquei, pois o tratamento se da + facilmente.