On Wed, Jul 03, 2013 at 09:50:36AM +0530, Arun wrote:
> Hi Team,
>
> We have a legacy Perl application which was developed using Perl 5.6.1.
>
> I would like to Install Encode.pm which is a pre requisite for
> Cache::Memcached.
>
> When i tried to install Encode.pm for P
Hi Team,
We have a legacy Perl application which was developed using Perl 5.6.1.
I would like to Install Encode.pm which is a pre requisite for
Cache::Memcached.
When i tried to install Encode.pm for Perl 5.6.1 it fails as it compatible
with Perl 5.7, Is there any other way to install it for
Bjoern Hoehrmann <[EMAIL PROTECTED]> writes:
>
>>> Now that we have this problem, introducing more places where one needs
>>> to carefully check the documentation what is considered UTF-8 does not
>>> seem like the best option, having decode_utf8() and decode(utf8=>...)
>>> mean some- thing differe
On Dec 04, 2004, at 20:28, Gisle Aas wrote:
Dan Kogai <[EMAIL PROTECTED]> writes:
2.1. What will the canonnical name of the strict version of "UTF-8"
be ? Gisle already submitted me a test patch and it uses
'utf-8-strict'. If there is no objection, I would like to use that.
This is the complete p
Dan Kogai <[EMAIL PROTECTED]> writes:
> 2.3. Degree of stricture. How strict are we going to make utf-8-strict?
> a. simply make use of UTF8_ALLOW_* in utf8.h ?
> b. unmapped codepoints banned as well?
> IMHO a. is strict enough since mapped codepoints are subject to
> increase as
t encoder.
Regards,
Gisle
diff -ru contrib/Encode-2/Encode.pm Encode/Encode.pm
--- contrib/Encode-2/Encode.pm 2004-12-03 11:17:01.0 -0800
+++ Encode/Encode.pm2004-12-03 13:27:11.0 -0800
@@ -300,6 +300,8 @@
};
$Encode::Encoding{utf8} =
bless {Name
On Sat, Dec 04, 2004 at 01:40:30PM +0900, Dan Kogai wrote:
> On Dec 04, 2004, at 11:51, Larry Wall wrote:
> >On Fri, Dec 03, 2004 at 10:12:12PM +, Tim Bunce wrote:
> >: I've no problem with 'utf8' being perl's unrestricted uft8 encoding,
> >: but "UTF-8" is the name of the standard and should g
On Dec 04, 2004, at 11:51, Larry Wall wrote:
On Fri, Dec 03, 2004 at 10:12:12PM +, Tim Bunce wrote:
: I've no problem with 'utf8' being perl's unrestricted uft8 encoding,
: but "UTF-8" is the name of the standard and should give the
: corresponding behaviour.
For what it's worth, that's how I'v
On Fri, Dec 03, 2004 at 10:12:12PM +, Tim Bunce wrote:
: I've no problem with 'utf8' being perl's unrestricted uft8 encoding,
: but "UTF-8" is the name of the standard and should give the
: corresponding behaviour.
For what it's worth, that's how I've always kept them straight in my head.
Als
On Sat, Dec 04, 2004 at 04:06:46AM +0900, Dan Kogai wrote:
> On Dec 02, 2004, at 23:25, Tim Bunce wrote:
> >On Wed, Dec 01, 2004 at 01:28:05PM -0800, Gisle Aas wrote:
> >>As you probably know perl's version of UTF-8 is not the real thing. I
> >>thought I would hack up a patch to support the encodi
On Dec 02, 2004, at 23:25, Tim Bunce wrote:
On Wed, Dec 01, 2004 at 01:28:05PM -0800, Gisle Aas wrote:
As you probably know perl's version of UTF-8 is not the real thing. I
thought I would hack up a patch to support the encoding as defined by
Unicode. That involves rejecting illegal chars (like s
On 02/12/2004 14:25:27 Tim Bunce wrote:
>Isn't there a standard name for the 'unrestricted' encoding?
>(Might be an IETF RFC rather than a unicode standard.)
Are you thinking of CESU-8 (see Unicode Technical Report #26 at
http://www.unicode.org/reports/tr26/). This is similar to Perl's UTF-8 in
Bjoern Hoehrmann <[EMAIL PROTECTED]> writes:
> Hmm, maybe I should ask why you proposed to keep the old behavior of
> encode_utf8 in the first place? The change would make more sense to
> me if both encode("UTF-8" => ...) and encode_utf8(...) were changed.
I just wanted to keep the the ability st
Bjoern Hoehrmann <[EMAIL PROTECTED]> writes:
> * Gisle Aas wrote:
> >As you probably know perl's version of UTF-8 is not the real thing. I
> >thought I would hack up a patch to support the encoding as defined by
> >Unicode. That involves rejecting illegal chars (like surrogates,
> >"\x{}" an
On Wed, Dec 01, 2004 at 01:28:05PM -0800, Gisle Aas wrote:
> As you probably know perl's version of UTF-8 is not the real thing. I
> thought I would hack up a patch to support the encoding as defined by
> Unicode. That involves rejecting illegal chars (like surrogates,
> "\x{}" and "\x{FDD0})
* Gisle Aas wrote:
>More interesting is:
>
> decode("UTF8", "Bj\xEF\xBF\xBFrn")
>
>where "\xEF\xBF\xBF" is not legal UTF-8 because "\x{}" is not
>legal Unicode. Either the whole sequence "\xEF\xBF\xBF" is replaced
>by "\x{FFFD}" or each bad byte is giving us
>"Bj\x{FFFD}\x{FFFD}\x{FFFD}rn".
* Gisle Aas wrote:
>As you probably know perl's version of UTF-8 is not the real thing. I
>thought I would hack up a patch to support the encoding as defined by
>Unicode. That involves rejecting illegal chars (like surrogates,
>"\x{}" and "\x{FDD0}), chars above 0x10, overlong sequences
>
As you probably know perl's version of UTF-8 is not the real thing. I
thought I would hack up a patch to support the encoding as defined by
Unicode. That involves rejecting illegal chars (like surrogates,
"\x{}" and "\x{FDD0}), chars above 0x10, overlong sequences
and such.
Before I do t
On Oct 18, 2004, at 11:16 AM, Shoenfelt, Todd wrote:
I need to create files programmatically containing Unicode data for
Quality Assurance testing, but the current version of Encode.pm
requires
v5.7.3. Is there a version of Encode.pm that works with v5.6.1?
No, but you might be able to use Text
Hi,
I need to create files programmatically containing Unicode data for
Quality Assurance testing, but the current version of Encode.pm requires
v5.7.3. Is there a version of Encode.pm that works with v5.6.1?
--
Todd Shoenfelt "Imagination is More Important Than Knowledge" - Albert
Einstein
Hi,
I noticed that in Encode versions higher than 1.83 (which came with
Perl 5.8.0), including the recent 1.99, the predefine_encodings()
subroutine has been expanded by *cat_decode(). Not sure what this is
for, but it now requires Encode.pm to always require bytes.pm on
BEGIN, even if it is not
On Fri, Aug 29, 2003 at 11:00:38AM +0200, Sven Neuhaus wrote:
> Hi,
>
> I'm seeing a script using XML::Simple go berserk (eats CPU + Memory) when
> feeding it XML with illegal UTF-8.
>
> The perl debugger is telling me it's jumping around in Encode.pm
> between l
Hi,
I'm seeing a script using XML::Simple go berserk (eats CPU + Memory) when
feeding it XML with illegal UTF-8.
The perl debugger is telling me it's jumping around in Encode.pm
between line 187 ("sub decode_utf8") and line 246 ("*decode = sub {...").
It's
CJKT experts,
To address the issue first raised by SADAHIRO-san for missing EURO SIGN
in CP936 map that leads to the further doubts for the correctness of
the original data for cp9?? in either unicode.org or microsoft.com, I
have regenerated the map again based upon
http://oss.software.ibm.co
On Thursday, Mar 27, 2003, at 00:44 Asia/Tokyo, SADAHIRO Tomoyuki wrote:
sigh, I've made such a patch long before.
cf.
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-09/
msg01568.html
I've checked the RCS entries on my repository and it did include EURO
SIGN until ver 1.20.
rcsdif
Sorry. I also dislike dead links and a typo.
(snip)
> This table does not include any UDC mappings
> as well as the table provided on unicode.org.
> I don't know why Microsoft has ceased to provides UDC mapping.
>
> http://http.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT
http:
On Thu, 27 Mar 2003 10:02:28 +0900
Dan Kogai <[EMAIL PROTECTED]> wrote:
> SADAHIRO-san and cp9?? experts,
>
> On Thursday, Mar 27, 2003, at 00:44 Asia/Tokyo, SADAHIRO Tomoyuki wrote:
> > + \x80 |0 # EURO SIGN
>
> Is this right? Yes, U20AC is indeed missing from cp936.ucm but see
> this;
(
SADAHIRO-san and cp9?? experts,
On Thursday, Mar 27, 2003, at 00:44 Asia/Tokyo, SADAHIRO Tomoyuki wrote:
+ \x80 |0 # EURO SIGN
Is this right? Yes, U20AC is indeed missing from cp936.ucm but see
this;
grep U20AC ucm/cp*.ucm
/Users/dankogai/work/Encode/ucm/cp1250.ucm: \x80 |0 # EURO SIGN
/Use
diff -urN ucm~/cp936.ucm ucm/cp936.ucm
--- ucm~/cp936.ucm Mon Mar 10 05:07:44 2003
+++ ucm/cp936.ucm Wed Mar 26 23:54:26 2003
@@ -137,7 +137,6 @@
\x7D |0 # RIGHT CURLY BRACKET
\x7E |0 # TILDE
\x7F |0 # DELETE
- \x80 |0 #
\xA1\xE8 |0 # CURRENCY SIGN
\xA1\xEC |0 # SECTION SIGN
Anton Tagunov <[EMAIL PROTECTED]> writes:
>
>
>To my worst confusion I had an impression that the real canonical
>name is the name of the .enc file which is different from
>both from MIME names and from 'ISO 8859-1' :-/
That is a weakness of Tcl's .enc files - .ucm files are better.
AFAIK all the
Hello Markus!
I'm very glad to hear your clarification :-)
Still there's something that bothers me:
Details.pod
=head2 Encoding Names
Encoding names are case insensitive. White space in names is ignored.
In addition an encoding may have aliases. Each encoding has one
"canonical" name. The "ca
Just for the record: The correct way to spell an ISO standard is to
have a space between ISO and its number. Correct: ISO 8859-1.
Other spellings such as ISO-8859-1 or ISO_8859-1 are merely
workarounds for situations, where spaces are inconvenient.
That's why MIME uses ISO-8859-1. In documentatio
On Thursday, March 21, 2002, at 03:49 , Jarkko Hietaniemi wrote:
> I don't think perlencode would work, a perl*.pod for a module is not
> our habit. Maybe a subpod Encode::Naming, or something like that?
Okay, then how about Encode::Description, with pod file stored as
lib/Description.pod?
Dan
>I will apply the patch then revise the pod. Well, Encode.pm's pod
> seems too long now. I think the general question should be exported
> to, say, perlencode.pod and Encode.pm's pod slim down to API
> documentations. What do you say, jhi?
I don't think perlencode would work, a perl*.p
On Wednesday, March 20, 2002, at 11:48 , Anton Tagunov wrote:
> With my upgraded knowledge of encoding naming I propose this.
>
> Justification:
>
> 1)
> Shift-JIS -> Shift_JIS does not hurt anyone, cause it does
> not work either way, Encode::encode
>
This is a forwarded message
From: Anton Tagunov <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, March 19, 2002, 9:48:06 PM
Subject: [PATCH][docs] Encode.pm
===8<==Original message text===
Hello, developers!
With my upgrad
nd beauty ? :-)
>
>Proposition:
>
> Should Name: HZ-GB-2312 be established as a synonym to HZ?
> Or not worth the trouble?
>
>Looking forward to your opinions! :-)))
>
>- Anton
>
>
>--- ext/Encode/Encode.pm.orig Mon Mar 18 00:20:24 2002
>+++ ext/Encode/Encode.pm
Hello, here is a patch for Encode.pm
to use escape-sequence encoding.
Known problems:
(1)
For present, any compiled encodings
(ASCII, ISO-8859-*, etc.) are not available
for the code extension of escape-sequence encoding.
(2) encodings with SINGLE SHIFTs (SS2, SS3)
are not avaliable
38 matches
Mail list logo
