2011-12-07 9 views
12

¿Por qué llego aquí con Devel :: Peek :: Dump dos resultados diferentes?Codificación de claves hash: ¿Por qué llego aquí con Devel :: Peek :: Dump dos resultados diferentes?

#!/usr/bin/env perl 
use warnings; 
use 5.014; 
use utf8; 
binmode STDOUT, ':encoding(utf-8)'; 
use Devel::Peek; 

my %hash1 = ('müller' => 1); 
say Dump $_ for keys %hash1; 

my %hash2; 
$hash2{'müller'} = 1; 
say Dump $_ for keys %hash2; 

Salida:

SV = PV(0x753270) at 0x76d230 
    REFCNT = 2 
    FLAGS = (POK,pPOK,UTF8) 
    PV = 0x759750 "m\303\274ller"\0 [UTF8 "m\x{fc}ller"] 
    CUR = 7 
    LEN = 8 

SV = PV(0x753270) at 0x7d75a8 
    REFCNT = 2 
    FLAGS = (POK,FAKE,READONLY,pPOK) 
    PV = 0x799110 "m\374ller" 
    CUR = 6 
    LEN = 0 
+0

¿Está seguro de que la fuente tiene exactamente los mismos bytes para ambas claves? – Mat

+0

ambos 'ü' escritos con la tecla' ü' del teclado. –

+0

por cierto, 'diga Dump ...;' debería ser 'Dump ...;'. – ikegami

Respuesta

4

Estos dos escalares contienen exactamente la misma cadena. La única diferencia está solo en cómo la secuencia se almacena internamente.

Supongo que la clave está normalizada para facilitar las comparaciones cuando se trata de localizar la clave en el hash.

+0

Intenté escribir un archivo 'xml' con' XML :: LibXML' desde un hash. Cuando escribo las entradas hash en el modo '$ hash {key} ...' recibo mensajes de error y el script muere: codificador error

+0

@sid_com No es el lugar adecuado para hacer una nueva pregunta y su pregunta es muy poco clara. Publique en el lugar apropiado y proporcione una demostración mínima y ejecutable del problema. – ikegami

+0

Se abrió una nueva pregunta: http://stackoverflow.com/questions/8443863/getting-encoding-error-when-using-hash-keys-to-write-xml-files-with-xmllibxml –

1

Esto no es una respuesta, creo que la respuesta de ikegami es correcta. Solo quería agregar algunas observaciones con algún código.

Ejecuto el siguiente código entre 5.10 a 5.15 y el comportamiento es coherente.

use utf8; 
use Test::More; 

{ 
    my %h = ('müller' => 1); 
    my $k = (keys %h)[0]; 
    ok(utf8::is_utf8($k), 'UTF-8 Latin-1 hash key has SvUTF8 set'); 
} 

{ 
    my %h = ('müller' => 1); 
     $h{'müller'} = 2; 
    my $k = (keys %h)[0]; 
    ok(! utf8::is_utf8($k), 'UTF-8 Latin-1 hash key does not has SvUTF8 set after assignment'); 
} 

{ 
    my %h = ('☺' => 1); 
     $h{'☺'} = 2; 
    my $k = (keys %h)[0]; 
    ok(utf8::is_utf8($k), 'UTF-8 (> Latin-1) hash key has SvUTF8 set after assignment'); 
} 

done_testing; 

Si se espera la segunda prueba, sería la primera degradación silenciosa que conozco. Supongo que p5p tiene la respuesta final ya sea que se trate de un error de optimización o un comportamiento esperado. (sv_dump parece una optimización (POK, FAKE, READONLY, pPOK))

Cuestiones relacionadas