Jeff,
Interestingly enough, it appears that Win32::Unicode::File does actually
seem to solve the problem. I changed OpenFile1 to
sub OpenFile1 {
my $filename = Tkx::tk___getOpenFile();
print $filename . "\n";
@list = statW($filename);
print Dumper(\@list);
$fh = Win32::Unicode::File->new();
$fh->open('<', $filename) or die;
while ($line = $fh->readline()) {
print $line;
}
}
And the file opened and displayed correctly. How COOL!
Thanks,
Scott
----------------------------------------------------------------------
Scott Parrill
Information Technology Specialist
Enterprise Technology Services /
Wyoming State Geological Survey
State of Wyoming
P.O. Box 1347
Laramie, WY 82073
Phone: 307-766-2286 x242
Fax: 307-766-2605
E-mail:
[email protected]<https://uwmail.uwyo.edu/owa/redir.aspx?C=4dc4ce62e583463fb8ad86380018935b&URL=mailto%3aScott.Parrill%40wyo.gov>
----------------------------------------------------------------------
E-Mail to and from me, in connection with the transaction of public
business, is subject to the Wyoming Public Records Act and may be
disclosed to third parties.
----------------------------------------------------------------------
On Thu, Aug 1, 2013 at 10:01 AM, Scott Parrill <[email protected]>wrote:
> Jeff,
>
> The print statement in OpenFile1 and OpenFile2 display different
> characters when opening the same file. OpenFile1 prints "ƒ.txt" where as
> OpenFile2 prints "â.txt". Incidentally, the Windows dir command and
> Windows Explorer display the file name as "ƒ.txt".
>
> The difference between the way the file name prints between the OpenFile1
> (which fails to open the file) and OpenFile2 (which correctly opens the
> file) makes me think this is problem in the Tkx::tk___getOpenFile()
> function.
>
> The difference between the way OpenFile2 and the Windows dir command
> display the file name is most likely a Unicode translation problem which is
> only an issue when I try to store the file name in a database or something
> of the sort. (I'll eventually have to work this one out as well.)
>
> Scott
>
>
> ----------------------------------------------------------------------
> Scott Parrill
> Information Technology Specialist
> Enterprise Technology Services /
> Wyoming State Geological Survey
> State of Wyoming
> P.O. Box 1347
> Laramie, WY 82073
> Phone: 307-766-2286 x242
> Fax: 307-766-2605
> E-mail:
> [email protected]<https://uwmail.uwyo.edu/owa/redir.aspx?C=4dc4ce62e583463fb8ad86380018935b&URL=mailto%3aScott.Parrill%40wyo.gov>
> ----------------------------------------------------------------------
> E-Mail to and from me, in connection with the transaction of public
> business, is subject to the Wyoming Public Records Act and may be
> disclosed to third parties.
> ----------------------------------------------------------------------
>
>
>
>
>
>
> On Wed, Jul 31, 2013 at 6:13 PM, Jeff Hobbs <[email protected]> wrote:
>
>> It is my understanding that on Windows, you need to use
>> Win32::Unicode::File/Dir functions to manipulate unicode filenames.
>> If you print out (or display in Unicode-compliant way) $filename
>> before the stat() call, does it show the right unicode? If so, try
>> the Win32::Unicode alternatives.
>>
>> Jeff
>>
>> On Wed, Jul 31, 2013 at 9:03 AM, Scott Parrill <[email protected]>
>> wrote:
>> > I've noted that the Tkx::tk__getOpenFile function does not seem to like
>> > high-ASCII characters in file names on Windows. (I haven't had an
>> > opportunity to test this on non-Windows platforms at this point.)
>> >
>> > Given the following code:
>> > ---------------------------------------
>> > use feature 'unicode_strings';
>> >
>> > use Encode qw(encode decode);
>> > use Data::Dumper;
>> > use Tkx;
>> >
>> > sub OpenFile1 {
>> > my $filename = Tkx::tk___getOpenFile();
>> > @list = stat($filename);
>> > print Dumper(\@list);
>> >
>> > open IN, "<", $filename or die;
>> > while ($line = <IN>) {
>> > print $line;
>> > }
>> > close IN;
>> > }
>> >
>> > sub OpenFile2 {
>> > opendir DIR, ".";
>> > while ($filename = readdir(DIR)) {
>> > next if ($filename eq '.' or $filename eq '..');
>> > if ($filename =~ /txt$/) {
>> > @list = stat($filename);
>> > print Dumper(\@list);
>> >
>> > open IN, "<", $filename or die;
>> > while ($line = <IN>) {
>> > print $line;
>> > }
>> > close IN;
>> > }
>> > }
>> > }
>> >
>> > $mw = Tkx::widget->new(".");
>> > $b = $mw->new_ttk__button(-text => 'Open File 1',
>> > -command => sub { OpenFile1() },
>> > );
>> > $b->g_pack();
>> >
>> > $b2 = $mw->new_ttk__button(-text => 'Open File 2',
>> > -command => sub { OpenFile2() },
>> > );
>> > $b2->g_pack();
>> >
>> > Tkx::MainLoop();
>> > ---------------------------------------
>> >
>> > Now create a file in the working directory, so that OpenFile2() will
>> find
>> > it, with a name containing a high-ASCII character (I used
>> "\x{0092}.txt").
>> > What I have found is that the OpenFile1() button will die on the "open
>> > IN,..." statement at line 12 and the stat() function, on line 9,
>> returns no
>> > data. However, the OpenFile2() function will correctly open and read
>> the
>> > file and the stat() function, on line 24, returns correct data for the
>> file.
>> > Using a file with unicode charaters in the name (like "\x{0289}.txt")
>> seems
>> > to work correctly in both OpenFile1() and OpenFile2().
>> >
>> > Does anyone have a suggestion on how to either get the
>> > Tkx::tk__getOpenFile() to return the file name correctly or how to work
>> > around the problem?
>> >
>> > Thanks,
>> > Scott
>> >
>> >
>> > ----------------------------------------------------------------------
>> > Scott Parrill
>> > Information Technology Specialist
>> > Enterprise Technology Services /
>> > Wyoming State Geological Survey
>> > State of Wyoming
>> > P.O. Box 1347
>> > Laramie, WY 82073
>> > Phone: 307-766-2286 x242
>> > Fax: 307-766-2605
>> > E-mail: [email protected]
>> > ----------------------------------------------------------------------
>> > E-Mail to and from me, in connection with the transaction of public
>> > business, is subject to the Wyoming Public Records Act and may be
>> > disclosed to third parties.
>> > ----------------------------------------------------------------------
>> >
>> >
>> >
>> >
>> > E-Mail to and from me, in connection with the transaction
>> > of public business, is subject to the Wyoming Public Records
>> > Act and may be disclosed to third parties.
>> >
>>
>
>
E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.
