encoding error in UTF-8 locales #8385

p5pRT · 2006-03-29T22:51:34Z

Migrated from rt.perl.org#38812 (status was 'resolved')

Searchable as RT38812$

p5pRT · 2006-03-29T22:51:35Z

From vincent-perl@vinc17.net

Created by vincent@vinc17.org

Consider the following script:

#!/usr/bin/env perl

use strict;
use encoding ':locale';
use XML::LibXML;

my $parser = XML::LibXML->new();
my $doc = $parser->parse_file('file.xml');

open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = $doc->toString(0);
$string =~ s/xml//s;
print OUT $string;
close OUT or die "$!";

where file.xml is:

<?xml version="1.0" encoding="iso-8859-1"?>

<root/>

I get the following error:

$ LC_CTYPE="en_US.UTF-8" ./encoding-bug
"\x{fffd}" does not map to iso-8859-1 at ./encoding-bug line 14.

Without the "$string =~ s/xml//s;", there are no errors. The problem
is reproducible on both Mac OS X and Linux.

Perl Info


Flags:
    category=core
    severity=medium

Site configuration information for perl v5.8.8:

Configured by vinc17 at Fri Feb 24 03:27:08 CET 2006.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=darwin, osvers=8.5.0, archname=darwin-2level
    uname='darwin prunille.vinc17.org 8.5.0 darwin kernel version 8.5.0: sun jan 22 10:38:46 pst 2006; root:xnu-792.6.61.obj~1release_ppc power macintosh powerpc '
    config_args='-des -Dprefix=/opt/local -Dccflags=-I'/opt/local/include' -Dldflags=-L/opt/local/lib -Dvendorprefix=/opt/local -Dcc=/usr/bin/gcc-4.0'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='/usr/bin/gcc-4.0', ccflags ='-I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/local/include',
    optimize='-O3',
    cppflags='-no-cpp-precomp -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/local/include'
    ccversion='', gccversion='4.0.1 (Apple Computer, Inc. build 5250)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='-L/opt/local/lib -L/usr/local/lib'
    libpth=/usr/local/lib /opt/local/lib /usr/lib
    libs=-ldbm -ldl -lm -lc
    perllibs=-ldl -lm -lc
    libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-L/opt/local/lib -bundle -undefined dynamic_lookup -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.8:
    /Users/vinc17/lib/site_perl
    /opt/local/lib/perl5/5.8.8/darwin-2level
    /opt/local/lib/perl5/5.8.8
    /opt/local/lib/perl5/site_perl/5.8.8/darwin-2level
    /opt/local/lib/perl5/site_perl/5.8.8
    /opt/local/lib/perl5/site_perl/5.8.7/darwin-2level
    /opt/local/lib/perl5/site_perl/5.8.7
    /opt/local/lib/perl5/site_perl
    /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level
    /opt/local/lib/perl5/vendor_perl/5.8.8
    /opt/local/lib/perl5/vendor_perl/5.8.7/darwin-2level
    /opt/local/lib/perl5/vendor_perl/5.8.7
    /opt/local/lib/perl5/vendor_perl
    .


Environment for perl v5.8.8:
    DYLD_LIBRARY_PATH (unset)
    HOME=/Users/vinc17
    LANG=POSIX
    LANGUAGE (unset)
    LC_CTYPE=en_US.ISO8859-1
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/Users/vinc17/bin:/usr/local/bin:/opt/local/bin:/usr/bin:/bin:/opt/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin:.
    PERL5LIB=/Users/vinc17/lib/site_perl
    PERL_BADLANG (unset)
    SHELL=/opt/local/bin/zsh

p5pRT · 2006-03-30T10:49:36Z

From @nwc10

On Wed, Mar 29, 2006 at 02:51:36PM -0800, Vincent Lefevre wrote:

Consider the following script:

#!/usr/bin/env perl

use strict;
use encoding ':locale';
use XML::LibXML;

my $parser = XML::LibXML->new();
my $doc = $parser->parse_file('file.xml');

open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = $doc->toString(0);
$string =~ s/xml//s;
print OUT $string;
close OUT or die "$!";

where file.xml is:

<?xml version="1.0" encoding="iso-8859-1"?>

<root/>

I get the following error:

$ LC_CTYPE="en_US.UTF-8" ./encoding-bug
"\x{fffd}" does not map to iso-8859-1 at ./encoding-bug line 14.

Without the "$string =~ s/xml//s;", there are no errors. The problem
is reproducible on both Mac OS X and Linux.

Removing the non-core dependency gives:

use strict;
use encoding ':locale';

open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n<!-- \303\251 --\

\n<root/>\n";
use Devel::Peek;
Dump $string;
$string =~ s/xml//s;
Dump $string;
print OUT $string;
close OUT or die "$!";
__END__

With the output

SV = PV(0x8147080) at 0x81e0260
REFCNT = 1
FLAGS = (PADMY,POK,pPOK,UTF8)
PV = 0x8141880 "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n\n<root/>\n"\0 [UTF8 "<?xml version="1.0" encoding="iso-8859-1"?>\n\n<root/>\n"]
CUR = 68
LEN = 72
SV = PVMG(0x816986c) at 0x81e0260
REFCNT = 1
FLAGS = (PADMY,SMG,POK,OOK,pPOK,UTF8)
IV = 3 (OFFSET)
NV = 0
PV = 0x8141883 ( "<?x" . ) "<? version=\"1.0\" encoding=\"iso-8859-1\"?>\n\n<root/>\n"\0 [UTF8 "<? version="1.0" encoding="iso-8859-1"?>\n\n<root/>\n"]
CUR = 65
LEN = 69
MAGIC = 0x81fd760
MG_VIRTUAL = &PL_vtbl_utf8
MG_TYPE = PERL_MAGIC_utf8(w)
MG_LEN = 61
"\x{fffd}" does not map to iso-8859-1 at /home/nick/tmp/38812.pl line 11.
"\x{fffd}" does not map to iso-8859-1 at /home/nick/tmp/38812.pl line 11.

The 0xfffd characters are coming as a side effect of the regular expression
engine converting the internal format of the string from
bytes(-which-use-encoding-has-declared-are-ISO-8859-1) to UTF-8, and in the
process finding bytes which are not ISO-8859-1

I'm not sure what's at fault. Possibly the documentation.
Possibly the core for use encoding not being able to enforce strictness of
encoding early enough.

Nicholas Clark

p5pRT · 2006-03-30T10:49:38Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2006-03-30T21:52:28Z

From vincent-perl@vinc17.net

On 2006-03-30 02:49:37 -0800, Nicholas Clark via RT wrote:

Removing the non-core dependency gives:

use strict;
use encoding ':locale';

open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n\n<root/>\n"\0 [UTF8 "<?xml version="1.0" encoding="iso-8859-1"?>\n\n<root/>\n"]
CUR = 68
LEN = 72

It seems that you significantly changed the script, since with still
the XML::LibXML code and the "Dump $string;" lines, I get:

SV = PV(0x1844754) at 0x1861cc8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x1118220 "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n\n<root/>\n"\0
CUR = 63
LEN = 64
SV = PV(0x1844754) at 0x1861cc8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK,UTF8)
PV = 0x11182e0 "<? version=\"1.0\" encoding=\"iso-8859-1\"?>\n\n<root/>\n"\0 [UTF8 "<? version="1.0" encoding="iso-8859-1"?>\n\n<root/>\n"]
CUR = 62
LEN = 64
"\x{fffd}" does not map to iso-8859-1 at ./encoding-bug line 17.

I'm not sure what's at fault. Possibly the documentation.

On more complex files, this leads to a

panic: sv_setpvn called with negative strlen.

so, I wouldn't say this is just the documentation.

--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

p5pRT · 2006-03-30T22:18:25Z

From vincent-perl@vinc17.net

On 2006-03-30 15:06:28 +0200, Vincent Lefevre wrote:

On 2006-03-30 02:49:37 -0800, Nicholas Clark via RT wrote:

I'm not sure what's at fault. Possibly the documentation.

On more complex files, this leads to a

panic: sv_setpvn called with negative strlen.

so, I wouldn't say this is just the documentation.

Here's a simple example:

#!/usr/bin/env perl

use strict;
use Devel::Peek;

my @t = qw/230 13 90 65 34 239 86 15 8 26 181 25 305 123 22 139 111 6 3
100 37 1 20 1 166 1 300 19 1 42 153 81 106 114 67 1 32 34/;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = join "\x{fffd}", map { '.'x$_ } @t;
Dump $string;
print OUT $string;
close OUT or die "$!";

--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

p5pRT · 2006-04-01T02:15:11Z

From BQW10602@nifty.com

On Thu, 30 Mar 2006 17:03:02 +0200, Vincent Lefevre <vincent@vinc17.org> wrote

Here's a simple example:

#!/usr/bin/env perl

use strict;
use Devel::Peek;

my @t = qw/230 13 90 65 34 239 86 15 8 26 181 25 305 123 22 139 111 6 3
100 37 1 20 1 166 1 300 19 1 42 153 81 106 114 67 1 32 34/;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = join "\x{fffd}", map { '.'x$_ } @t;
Dump $string;
print OUT $string;
close OUT or die "$!";

It can be simplified more; it smells of some buffer of 1024 bytes.

use strict;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = "." x 1022 . "\x{fffd}";
print OUT $string;
close OUT or die "$!";
__END__
"\x{ffc0}" does not map to iso-8859-1 at ....
panic: sv_setpvn called with negative strlen at ...

SADAHIRO Tomoyuki

p5pRT · 2008-05-16T22:46:45Z

p5p@spam.wizbit.be - Status changed from 'open' to 'stalled'

p5pRT · 2013-06-21T21:08:58Z

From @nwc10

On Fri Mar 31 18:15:11 2006, BQW10602@nifty.com wrote:

It can be simplified more; it smells of some buffer of 1024 bytes.

use strict;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = "." x 1022 . "\x{fffd}";
print OUT $string;
close OUT or die "$!";
__END__
"\x{ffc0}" does not map to iso-8859-1 at ....
panic: sv_setpvn called with negative strlen at ...

For reference, this test case:

use strict;
use Devel::Peek;

my @t = qw/230 13 90 65 34 239 86 15 8 26 181 25 305 123 22 139 111 6 3
100 37 1 20 1 166 1 300 19 1 42 153 81 106 114 67 1 32 34/;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = join "\x{fffd}", map { '.'x$_ } @t;
Dump $string;
print OUT $string;
close OUT or die "$!";

which Karl created in an attempt to bisect to find the commit which
resolves the "panic", turns out to show errors with valgrind.

So figuring out those may shed more light on this.

Nicholas Clark

p5pRT · 2013-06-21T21:08:59Z

The RT System itself - Status changed from 'stalled' to 'open'

p5pRT · 2013-06-22T16:03:47Z

From @khwilliamson

On Fri Jun 21 14:08:58 2013, nicholas wrote:

On Fri Mar 31 18:15:11 2006, BQW10602@nifty.com wrote:

It can be simplified more; it smells of some buffer of 1024 bytes.

use strict;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = "." x 1022 . "\x{fffd}";
print OUT $string;
close OUT or die "$!";
__END__
"\x{ffc0}" does not map to iso-8859-1 at ....
panic: sv_setpvn called with negative strlen at ...

For reference, this test case:

use strict;
use Devel::Peek;

my @t = qw/230 13 90 65 34 239 86 15 8 26 181 25 305 123 22 139 111 6 3
100 37 1 20 1 166 1 300 19 1 42 153 81 106 114 67 1 32 34/;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = join "\x{fffd}", map { '.'x$_ } @t;
Dump $string;
print OUT $string;
close OUT or die "$!";

which Karl created in an attempt to bisect to find the commit which
resolves the "panic", turns out to show errors with valgrind.

So figuring out those may shed more light on this.

Nicholas Clark

I worked a little more on this and have come to believe that the fault
is entirely in Encode. So I filed a ticket there:
https://rt.cpan.org/Ticket/Display.html?id=86327

--
Karl Williamson

p5pRT · 2013-06-22T18:14:04Z

From @khwilliamson

On Sat Jun 22 09:03:47 2013, khw wrote:

On Fri Jun 21 14:08:58 2013, nicholas wrote:

On Fri Mar 31 18:15:11 2006, BQW10602@nifty.com wrote:

It can be simplified more; it smells of some buffer of 1024 bytes.

use strict;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = "." x 1022 . "\x{fffd}";
print OUT $string;
close OUT or die "$!";
__END__
"\x{ffc0}" does not map to iso-8859-1 at ....
panic: sv_setpvn called with negative strlen at ...

For reference, this test case:

use strict;
use Devel::Peek;

my @t = qw/230 13 90 65 34 239 86 15 8 26 181 25 305 123 22 139 111 6 3
100 37 1 20 1 166 1 300 19 1 42 153 81 106 114 67 1 32 34/;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = join "\x{fffd}", map { '.'x$_ } @t;
Dump $string;
print OUT $string;
close OUT or die "$!";

which Karl created in an attempt to bisect to find the commit which
resolves the "panic", turns out to show errors with valgrind.

So figuring out those may shed more light on this.

Nicholas Clark

I worked a little more on this and have come to believe that the fault
is entirely in Encode. So I filed a ticket there:
https://rt.cpan.org/Ticket/Display.html?id=86327

I already got a response to that ticket!

=============
I also took a look at

https://rt-archive.perl.org/perl5//Public/Bug/Display.html?id=38812

and found if it is due to the hard-codeded buffer size of 1024 @
PerlIO::encoding, Encode.pm cannot solve this problem alone.

Dan the Encode Maintainer

So my belief was wrong that it was Encode alone. I'm hoping someone
familiar with PerlIO might have an idea about this
--
Karl Williamson

p5pRT · 2013-06-22T18:50:18Z

From dankogai@dan.co.jp

Though this is not a solution, we'd better increase the buffer size of PerlIO::Encode. I don't quite remember why it is 1024 but it is terribly low for today's use cases.

Also not that the use of encoding pragma is not recommended when there is a chance of encoding error since PerlIO has no room for error detection and recovery (besides emitting errors). In which case you should decode after read and encode before print.

Dan the Encode Maintainer

On 23 Jun 2013, at 03:14 , "Karl Williamson via RT" <perlbug-followup@perl.org> wrote:

On Sat Jun 22 09:03:47 2013, khw wrote:

On Fri Jun 21 14:08:58 2013, nicholas wrote:

On Fri Mar 31 18:15:11 2006, BQW10602@nifty.com wrote:

It can be simplified more; it smells of some buffer of 1024 bytes.

use strict;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = "." x 1022 . "\x{fffd}";
print OUT $string;
close OUT or die "$!";
__END__
"\x{ffc0}" does not map to iso-8859-1 at ....
panic: sv_setpvn called with negative strlen at ...

For reference, this test case:

use strict;
use Devel::Peek;

my @t = qw/230 13 90 65 34 239 86 15 8 26 181 25 305 123 22 139 111 6 3
100 37 1 20 1 166 1 300 19 1 42 153 81 106 114 67 1 32 34/;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = join "\x{fffd}", map { '.'x$_ } @t;
Dump $string;
print OUT $string;
close OUT or die "$!";

which Karl created in an attempt to bisect to find the commit which
resolves the "panic", turns out to show errors with valgrind.

So figuring out those may shed more light on this.

Nicholas Clark

I worked a little more on this and have come to believe that the fault
is entirely in Encode. So I filed a ticket there:
https://rt.cpan.org/Ticket/Display.html?id=86327

I already got a response to that ticket!

=============
I also took a look at

https://rt-archive.perl.org/perl5//Public/Bug/Display.html?id=38812

and found if it is due to the hard-codeded buffer size of 1024 @
PerlIO::encoding, Encode.pm cannot solve this problem alone.

Dan the Encode Maintainer

So my belief was wrong that it was Encode alone. I'm hoping someone
familiar with PerlIO might have an idea about this
--
Karl Williamson

---
via perlbug: queue: perl5 status: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=38812

p5pRT · 2013-06-22T19:04:20Z

From @cpansprout

On Sat Jun 22 11:14:04 2013, khw wrote:

On Sat Jun 22 09:03:47 2013, khw wrote:

On Fri Jun 21 14:08:58 2013, nicholas wrote:

On Fri Mar 31 18:15:11 2006, BQW10602@nifty.com wrote:

It can be simplified more; it smells of some buffer of 1024 bytes.

use strict;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = "." x 1022 . "\x{fffd}";
print OUT $string;
close OUT or die "$!";
__END__
"\x{ffc0}" does not map to iso-8859-1 at ....
panic: sv_setpvn called with negative strlen at ...

For reference, this test case:

use strict;
use Devel::Peek;

my @t = qw/230 13 90 65 34 239 86 15 8 26 181 25 305 123 22 139
111 6 3
100 37 1 20 1 166 1 300 19 1 42 153 81 106 114 67 1 32 34/;
open OUT, '>:encoding(iso-8859-1)', 'out.xml' or die "$!";
my $string = join "\x{fffd}", map { '.'x$_ } @t;
Dump $string;
print OUT $string;
close OUT or die "$!";

which Karl created in an attempt to bisect to find the commit which
resolves the "panic", turns out to show errors with valgrind.

So figuring out those may shed more light on this.

Nicholas Clark

I worked a little more on this and have come to believe that the fault
is entirely in Encode. So I filed a ticket there:
https://rt.cpan.org/Ticket/Display.html?id=86327

I already got a response to that ticket!

=============
I also took a look at

https://rt-archive.perl.org/perl5//Public/Bug/Display.html?id=38812

and found if it is due to the hard-codeded buffer size of 1024 @
PerlIO::encoding, Encode.pm cannot solve this problem alone.

Dan the Encode Maintainer

So my belief was wrong that it was Encode alone. I'm hoping someone
familiar with PerlIO might have an idea about this

Interesting. Could this be related to #115262? I don’t know much about
PerlIO per se, but I do know about basic SV handling, which
PerlIO::encoding was getting wrong in many places.

In the process of fixing it, I noticed that it might pass partial
characters to the encoding handler. So I filed #115262. I don’t know
whether this is related.

If it is, then the real solution (as mention in #115262) is to cache the
partial characters and add them to the next call to the encoding object.

--

Father Chrysostomos

p5pRT · 2016-07-15T15:49:02Z

From @cpansprout

I removed the link to the encoding.pm ticket, since the bug was actually coming from PerlIO::encoding. The use of encoding.pm was unrelated.

--

Father Chrysostomos

p5pRT · 2019-03-29T03:25:47Z

From @khwilliamson

This has been fixed by many changes to locale handling over the years.
I had to comment out the encoding pragma to run it, as that is no longer supported
--
Karl Williamson

p5pRT · 2019-03-29T03:25:48Z

@khwilliamson - Status changed from 'open' to 'resolved'

p5pRT closed this as completed Mar 29, 2019

p5pRT added Severity Medium distro-darwin type-core labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

encoding error in UTF-8 locales #8385

encoding error in UTF-8 locales #8385

p5pRT commented Mar 29, 2006

p5pRT commented Mar 29, 2006

p5pRT commented Mar 30, 2006

p5pRT commented Mar 30, 2006

p5pRT commented Mar 30, 2006

p5pRT commented Mar 30, 2006

p5pRT commented Apr 1, 2006

p5pRT commented May 16, 2008

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 22, 2013

p5pRT commented Jun 22, 2013

p5pRT commented Jun 22, 2013

Dan the Encode Maintainer

p5pRT commented Jun 22, 2013

Dan the Encode Maintainer

p5pRT commented Jul 15, 2016

p5pRT commented Mar 29, 2019

p5pRT commented Mar 29, 2019

encoding error in UTF-8 locales #8385

encoding error in UTF-8 locales #8385

Comments

p5pRT commented Mar 29, 2006

p5pRT commented Mar 29, 2006

From vincent-perl@vinc17.net

Created by vincent@vinc17.org

p5pRT commented Mar 30, 2006

From @nwc10

p5pRT commented Mar 30, 2006

p5pRT commented Mar 30, 2006

From vincent-perl@vinc17.net

p5pRT commented Mar 30, 2006

From vincent-perl@vinc17.net

p5pRT commented Apr 1, 2006

From BQW10602@nifty.com

p5pRT commented May 16, 2008

p5pRT commented Jun 21, 2013

From @nwc10

p5pRT commented Jun 21, 2013

p5pRT commented Jun 22, 2013

From @khwilliamson

p5pRT commented Jun 22, 2013

From @khwilliamson

Dan the Encode Maintainer

p5pRT commented Jun 22, 2013

From dankogai@dan.co.jp

Dan the Encode Maintainer

p5pRT commented Jun 22, 2013

From @cpansprout

Dan the Encode Maintainer

p5pRT commented Jul 15, 2016

From @cpansprout

p5pRT commented Mar 29, 2019

From @khwilliamson

p5pRT commented Mar 29, 2019