Guten Tag Kristis Makris, am Mittwoch, 4. April 2007 um 20:39 schrieben Sie:
> Other people may have the same problem and converting may not be an > option for them. Isn't this a place where Perls internal UTF-8 strings are made for? If you remember my problem with german umlauts because SCMBug didn't recognize the correct encoding while reading some data under Windows I just made SCMBug convert the read string from CP850 under Windows into a nativ perl string. I'm no perl guy but I think I read something about Perls DBI to be capable of doing so automatically dependent of whatever your database is telling perl the retrieved data is encoded in. How does Bugzilla handles this for old installations where no UTF-8 parameter is switched on? The MySQL tables were generated in latin1_swedish_ci as the default. > open my $fh, '>:encoding(iso-8859-1)', $path or die "open($path): $!"; > XMLout($ref, OutputFile => $fh); > which works when actually opening a file (we don't do that -- we > produce the xml string and transmit it across a socket) Shouldn't be the proper way to read some stuff from anywhere, encode it into a native Perl string, which is always properly UTF-8, an writing it to somewhere in whatever encoding that "somewere" needs? Transfer over the socket would just be in UTF-8, too, and one has at least to know in which characterset the data which was read is encoded in, but is able to always output proper encoded UTF-8 Perl strings. > So, preferably with: > my $xml = new XML::Simple (NoAttr=>1, XMLDecl => "iso-8859-1"); > my $ret_message = $xml->XMLout( $vdd ); > which will provide the encoding when the XML file is created. So, > this encoding value could be listed in the daemon.conf file. How > does this sound ? To always output proper UTF-8 should be a real advantage, one could else specify a parameter for output in any other supported character set. The parameter you suggested could be used after reading the data, too, because one already has to know in which character set his data is encoded or else he will get crap, because you encode something unknown to "anything". > Another question: Do we need the encoding explicitly listed in the html > version of the vdd ? It looks like it's displayed well in your browser > so far, but is still missing from the .html file. It's always a good idea to tell the users client about the encoding of the file. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: [EMAIL PROTECTED] Web: http://www.am-soft.de AM-SoFT Potsdam GmbH, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 12480, Geschäftsführer Andreas Muchow _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
