Unicode

[Name]

warum
use utf8;
statt
use encoding 'utf8';

* Das erste Pragma gab es schon länger als das zweite, also bin ich es gewohnt, so zu schreiben.
* Es ist kürzer.
* Es gibt keinen funktionalen Unterschied. http://perldoc.perl.org/utf8.html, greppe nach works much the same
* TIMTOWTDI.

Kannst du mich auf ein paar solche Empfehlungen für meine Sammlung verlinken? Danke!

ich empfange von aussen Strings, die eigentlich schon in UTF-8 codiert sind muss diese aber zuvor decoden, sodass ich sie in meinem Programm benutzen kann?

Generell ja. Perls internes Format ist zwar in Wirklichkeit UTF-8, aber erst decodieren setzt das passende Flag in der Variable. Du kannst dir Variablenflags mit Devel::Peek anschauen. http://search.cpan.org/dist/Devel-Peek/Peek.pm

Bei massivem IO führt dieses ständige decoding doch zu hohen Performanceverlusten?

Der ehemalige Pumpking Nick Clark hat Performanceverbesserungen rund ums Thema UTF-8 eingebaut. Ich kann die Ankündigung ums Verrecken nicht mehr im Web oder perldelta finden, aber er hat beim GPW8 darüber geredet. http://www.perl-workshop.de/

Kurz: Wenn du schon Daten im Format UTF-8 zuführst, ist das Decodieren eine sehr schnelle Operation.

Du darfst gerne Benchmarken, um zu sehen, ob tatsächlich ein hoher Performanceverlust auftritt. http://search.cpan.org/dist/perl-5.8.8/lib/Benchmark.pm Sehr viel schneller wird's nicht mehr gehen, das Potenzial ist gut ausgereizt.

(Beachte, dass du zuerst Profiling betreiben musst, bevor du blind Optimierung in Angriff nimmst. http://search.cpan.org/dist/Bundle-Devel/ Es lohnt nicht, einen 1%-Flaschenhals zu verbessern, wenn woanders ein 20%-Loch klafft.)

Wenn ich eine Datenbankabfrage mache, und einen "arrayref" zurück bekomme, dann muss ich nun alle Strings decoden:

for(@$t) {

my $a = $;
    for(0..length(@{$a})) {
        $a->[$] = decode("UTF-8", $a->[$_]);
    }
}

> Das ist hässlich  

Da stimme ich dir zu. Jeder Code, der nicht unmittelbar mit dem Ziel zu tun hat, wird vom Programmierer so empfunden. Das gleiche gilt für Untainting.  
  
Leider sind diese hässlichen Sachen notwendig, weil Perl uns hier (derzeit?) kein DWIMmery oder Syntaxzucker anbieten kann. Wenn du ein langes Gesicht ob der Vorstellung machst, denk immer an die armen Javaprogrammierer, die viel lästigere Syntax ertragen müssen.  
  

> und wahrscheinlich nicht performant.  

Siehe Bemerkungen oben. Spekulieren kann jeder. Die manchmal verblüffende Wahrheit fördern nur die Werkzeuge zu Tage.  
  

> Wie würde man das lösen, denn ich müsste das ja nun an ganz vielen Stellen einbauen..  

1\. Wo nur möglich, benutze die impliziten Konstrukte. Die halten deinen Code sauber.  
2\. Stelle deine Datenbank auf UTF-8 um und sage das auch deinem DBD-Treiber. Ich habe mit DBD::Pg hier vorbildlich gute Erfahrungen gemacht. <http://search.cpan.org/dist/DBD-Pg/Pg.pm#Database_Handle_Attributes>  
3\. Wenn du explizite Decodierung benötigst, verzögere den Schritt so lang wie möglich, bevor du Manipulation an den Daten vornehmen musst. Eventuell fallen bei gewissen Umständen einige Datensätze unter den Tisch, und du sparst dir dann den Decodierungsschritt.  
Hier ist es sehr hilfreich, ein passendes Variablennamensschema einzusetzen, damit du nicht durcheinanderkommst, ob die Daten schon decodiert sind oder nicht. Lies dazu <http://www.joelonsoftware.com/articles/Wrong.html>