No subject

```=0D
"Felix Antonius Wilhelm Ostmann via RT"=0D
<bug-DBIx-Class-Schema-Loader at rt.cpan.org> writes:=0D
=0D
> It is not really the same ...=0D
=0D
The _internal_ representation is not the same; the \x from will be=0D
represented internally as one byte per code point ("downgraded"), while=0D=

the literal form will be utf-8-encoded ("upgraded"). Semantically they=0D=

are the same, as evidenced by "eq" returning true.=0D
=0D
> In the real code i have to make a Encode::decode('ISO-8859-15', $enum) =
as a quickfix. =0D
=0D
Please show where in the real code you have to do this.  It smells like=0D=

something you're passing it to suffering from the Unicode Bug,=0D
i.e. treating the characters in the 128..255 range differently depending=0D=

on the internal representation (see=0D
https://metacpan.org/pod/perlunicode#The-%22Unicode-Bug%22 for details).=0D=

=0D
> $ cat ticket123698.pl =0D
> use utf8;=0D
> use 5.20.0;=0D
> use Data::Dumper;=0D
> say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgestellt";=0D
> print Dumper("zur\xFCckgestellt","zur=C3=83=C2=BCckgestellt");=0D
> $ perl ticket123698.pl =0D
> 1=0D
> $VAR1 =3D 'zur=C3=AF=C2=BF=C2=BDckgestellt';=0D
> $VAR2 =3D "zur\x{fc}ckgestellt";=0D
=0D
The different outputs here are a quirk of how Data::Dumper deals with=0D
downgraded vs. upgraded strings (which could be viewed as an instance of=0D=

the Unicode Bug, but doesn't actually affect semantics).  The first one=0D=

is showing as =C3=AF=C2=BF=C2=BD because you haven't thold perl that your=
 terminal=0D
expects UTF-8-encoded strings.  Adding=0D
=0D
    use open qw(:std :utf8);=0D
=0D
to the script will make it apply a UTF-8 encoding layer to the standard=0D=

input/output/error filehandles, so non-ASCII charcters show correctly.=0D=

=0D
- ilmari=0D
-- =0D
"I use RMS as a guide in the same way that a boat captain would use=0D
 a lighthouse.  It's good to know where it is, but you generally=0D
 don't want to find yourself in the same spot." - Tollef Fog Heen=0D
```=0D
=0D