Philip,
Thank you for your help.
This work is being done by a couple of students of mine, so I just sent you one of the
results of
the experiments. But they have tried other things. So I'll make some localized
comments bellow.
> On Tue, 20 Nov 2001 16:35:25 -0000, in perl.unicode you wrote:
>
> > open(FICH1,"fich1.txt")||die"Nao foi possivel abrir o ficheiro fich1.txt";
> > open(FICH3,">fich3.txt")||die"Nao foi possivel abrir o ficheiro fich3.txt";
>
> Good that you check for success, but you should also include the reason
> -- it's in $!. For example:
>
> open(FICH1, "fich1.txt") || die "Nao foi possivel abrir " .
> "o ficheiro fich1.txt: $!";
>
> > use utf8;
Yes, there is no need for it;
>
> You shouldn't need that. Unicode::String will do all the Unicodery for
> you; your program only needs to handly 'plain' bytes.
>
> > while (<FICH1>) {
> > chomp($_);
> > $palavra1=$_;
> > @array=split(/ /,$palavra1);
>
> What do you use $palavra1 and @array for? (And @array is usually a bad
> variable name.)
Yes, quite true. I guess they left it from some experiment and I overlooked it.
> > $palavra2=utf16($_);
>
> Here is a mistake. If you call utf16($_), it means "$_ is a string
> encoded in UTF-16. Take it and convert it into a Unicode::String
> object."
We've tried with utf8. It does read well and it writes well as long as you write it in
utf8.
>
> But you said you wanted to convert from UTF-8 to UTF-16. So you probably
> want something like
>
> $palavra_objeito = utf8($_);
> $palavra_em_utf16 = $palavra_objeito->utf16;
We've tried just that and the result wasn't what we expected...
>
> Note that ->utf16 will return UTF-16BE, as I understand it, since
> "Internally a Unicode::String object is a string of 2 byte values in
> network byte order (big-endian)" (quote from the docs). So if your
> database and/or file wants UTF-16LE (which is more natural for Intel
> chips), then you need to do something such as
>
> $palavra_objeito->byteswap;
Now there's something we didn't try.
>
> first (after you assign to $palavra_objeito and before you call ->utf16)
> to convert from big-endian to little-endian.
>
> > $sql = "INSERT INTO Tipo_Referencia ( Descricao ) SELECT '$palavra2' AS
>Expr1;";
>
> Is there a reason why you don't write this as
>
> $sql = "INSERT INTO Tipo_Referencia ( Descricao ) " .
> "VALUES ('$palavra_em_utf16')"
Not really, but the previous sintax has worked many times.
>
> ? The "INSERT INTO table (columns) VALUES (literals)" is, for me, the
> usual syntax, and "INSERT INTO table (columns) SELECT literals AS dummy"
> looks strange to me.
Maybe, I just copied the sintax from an Access Query. It worked in many occasions.
Even writing an
UTF-8 value worked with that sintax. Obviously Access didn't make much sense of it as
UTF-8 isn't
really something it "understands".
But your sintax is the most correct one (and the one respecting SQL standard).
>
> > print FICH3 $palavra2,"\n";
> > $conn->execute($sql,,,adExecuteNoRecords);
>
> This is the same as
>
> $conn->execute($sql,adExecuteNoRecords);
>
> .. If the constant adExecuteNoRecords has to be the fourth parameter to
> ->execute, then say so:
>
> $conn->execute($sql, undef, undef, adExecuteNoRecords);
>
> .. Perl isn't Visual Basic :)
There, you caught me. I'm much more fluent in VB than in Perl, and I was the one that
gave my
students the ADO code...
>
> To summarise, I think you have misunderstood how Unicode::String works.
> utf16() (called as a function, not a method) doesn't convert a strong
> *to* UTF-16, it expects a string in UTF-16 and converts *from* that
> encoding into the internal format used by Unicode::String and returns an
> object. Then you can call methods on that object to produce another
> encoding such as UTF-8 or Latin-1 or whatever. So conversions involving
> Unicode::String generally involve at least two calls.
Not quite, but it is clear that it was a bad example and your conclusions are,
therefore justified.
I'll try your suggestions and let you know about the result.
Thank you for your time and your help.
Regards.
Rui
