Front page | perl.perl5.porters |
Postings from January 2005
Re: Perl setlocale?
Thread Previous
|
Thread Next
From:
Abe Timmerman
Date:
January 1, 2005 18:48
Subject:
Re: Perl setlocale?
Message ID:
200501020348.27738.abe@ztreet.demon.nl
Op een grimmige herfstdag (Friday 31 December 2004 05:38),schreef Glenn
Linderman:
> The following message has gone unanswered on ActiveState's Win32 perl
> user's group. Of course, maybe it is the holidays. But I wondered if
> maybe a Windows porter could point me in the right direction to figure
> this out. The documentation for setlocale is quite generic, and could
> probably be improved, at least for Windows users. And from what I've
> encountered so far, maybe there are also bugs in the code, as I get
> screwy errors, unchanged locale information, and inability to change to
> a new code page.
>
> Here are the details:
>
>
> So, I'm experimenting with trying to change code pages. Although
> Windows documents GetACP to discover the current code page, there is no
> corresponding SetACP...
Do you mean the equivalent of:
mode CON: CP select=yyy
> Finally discovered that Windows setlocale function is supposed to change
> code pages... and that Perl wraps Windows setlocale... but
>
> 1) The default code page is 437. When I call setlocale with no
> parameters, it reports "English_United States.1252".
>
> 2) I change the code page to 65001 (UTF-8, supposedly). I get the same
> report from setlocale.
The idea behind codepages used to be, "a selection of 255 char-codes to
represent", so a unicode-codepage seems contradictory.
The only reference to the UTF-8 codepage 65001 I could find had to do with
IIS. It might well be that this is only implemented in IIS.
> 3) I try calling setlocale with "English_United States.65001" and it
> gives me an error, that says "strxfrm() gets absurd", which is,
> admittedly, an absurd error, but it is not clear what is absurd about
> the string such that strxfrm shouldn't like it... even if the string
> isn't in the proper format.
The error is from locale.c:Perl_new_collate() and covers up the fact that the
(ASCII)strings "a" and "ab" cannot be transformed into this new locale
setting (strxfrm() returns INT_MAX for both, which indicates an error)
> 4) I try calling setlocale with "en_us.65001", and various other
> capitalizations that I see floating around the web, and no errors are
> reported.... but neither does the output of a parameterless setlocale
> call change from the "English_United States.1252".
You need to follow the Windows syntax for specifying locales:
locale:: Language[_Country[.codepage]] || .codepage || "" || NULL
"en" is not a valid abbrevation for the Language "English"
http://msdn.microsoft.com/library/en-us/vclib/html/
_crt_language_and_country_strings.asp
> Windows 2000, if it matters. Version 5.00.2195 and autoupdate turned on.
To demonstrate that changing the codepage with setlocale() doesn't change your
terminal:
C:>mode con: cp select=1252
C:>perl -MPOSIX=locale_h -wle "print
chr(192);setlocale(LC_ALL,'.1250');print chr(192);system 'mode con: cp
select=1250';print chr(192);"
This should print two CAPITAL LETTER A WITH GRAVE and the last is CAPITAL
LETTER R WITH ACUTE
(And mind you the codepage(1250) sticks around in your CMD window)
I believe setlocale() on windows does work:
#! perl
use strict;
use warnings;
use POSIX qw( locale_h strftime );
setlocale( LC_ALL, "Dutch" );
my $dutch = strftime( "%A, %B %d, %Y", 0, 0, 0, 12, 11, 95, 0);
setlocale( LC_ALL, "English" );
my $english = strftime( "%A, %B %d, %Y", 0, 0, 0, 12, 11, 95, 0);
print " Dutch: $dutch\n";
print "English: $english\n";
__END__
C:\klad>perl localedate.pl
Dutch: zondag, december 12, 1995
English: Sunday, December 12, 1995
HTH +
Good luck,
Abe
--
Tim Bunce> Here's an easy fix: deprecate them.
*All* of them? <finger wavering over the red big button INITIATE
VSTRINGS ANNIHILATION>
-- Jarkko Hietaniemi on p5p @ 2001-11-14
Thread Previous
|
Thread Next