On Sat, 02 Aug 2003 at 19:38 (+0200), Ratti wrote:
Am Don, 2003-07-31 um 10.40 schrieb Bernhard Walle:
On Thu, 31 Jul 2003 at 01:25 (+0200), Ratti wrote:
Am Mit, 2003-07-30 um 23.52 schrieb Christian Boltz:
use bytes; hat mich weitergebracht, wenn auch nicht ans Ziel. no utf8 kann man vergessen, das besagt lediglich, das der perl-Quelltext nicht utf8-codiert ist.
bringt mich hier auch nicht weiter.
Nein, aber in der "use bytes;"-Ecke treibt sich noch mehr Doku rum, da muß man mal'n paar Links hinterherlaufen.
Recht interessant ist: http://www.perldoc.com/perl5.8.0/pod/perlguts.html#Unicode-Support http://www.perldoc.com/perl5.8.0/pod/perlunicode.html
Eventuell noch: http://www.perldoc.com/perl5.8.0/lib/Encode.html
Naja, ich habe die Probleme mittlerweile alle (bis auf drei, die aber auf Bugs in Perl beruhen und entsprechend dokumentiert sind) gelöst.
Mein Vorschlag wäre, dass Perl intern Strings *immer* als Unicode behandelt und bei der Ein-/Ausgabe entsprechend der aktuellen locale konvertiert.
Damit kann dann wieder ich nix anfangen. Ich habe Binärdateien (PS-Fonts), die klassisches 8-Bit ASCII enthalten.
Ich kann nix damit anfangen, daß sich ganze Programmsegmente als "use bytes" deklarieren lassen, noch kann ich brauchen, daß da irgendwas als 16-Bit interpretiert wird. Ich bräuchte vielmehr eine Unterscheidung zwischen ASCII und Unicode-Skalaren. Sobald ich in meinem Binärkram die Ascii-Daten rausgefummelt habe, dürfen sie ja gerne nach Unicode konvertiert werden - aber erst dann. Vorher stolpere ich über Binärschrott, der nunmal 192 60 enthalten kann.
Man muss halt zwischen Text und Bytes konsequent unterscheiden, wie dies beispielsweise in Java gelöst ist (da gibt es beispielsweise FileReader zum Einlesen von Zeichenketten und FileInputStream zum Einlesen von Bytes). Aber ich sehe schon, ich ändere die komplette Architektur von Perl. Naja, mir sind halt getypte Programmiersprachen wie C/C++ oder Java lieber. Perl hat zwar durchaus seine Stärken in der Textverarbeitung, aber als allgemeine Programmiersprache bevorzuge ich dann was anderes. Für Muttprint ist es aber sehr gut geeignet, deshalb habe ich es ja auch verwendet und mich damit rumgeärgert. ;-)
Wenn nicht noch ein Wunder passiert wird das hier ein "Known bug". Ich programmiere nicht um Bugs in Perl in dieser Art herum, weil es weder zu Perl 5.6 noch zu Perl 5.8.x (mit behobenem Bug) kompatibel wäre. Dann muss der Anwender halt auf formatierte Datumsangaben in einer Unicode- Locale verzichten.
Eventuell könnte man den ja catchen. Du hast es ja einfach, es betrifft nur das Datum. Man könnte ja mit einer gezielten Streingoperation gucken, ob das Resultat 5.6 / 5.8.1 -kompatibel ist, oder 5.8.bug. Je nachdem kannst du nochmal "entcoden", siehe einer der Links da oben.
Ehrlich gesagt ist mir das zu blöd. Als nächstes programmiere ich dann um einen Bug in der Hardware herum. Der Bug ist dokumentiert, es gibt drei Möglichkeiten für den User: * Perl updaten * keine UTF-8 Umgebung verwenden (was die meisten Leute sowieso nicht machen) * DATE=original, wodurch das Datum nicht in die Landessprache übersetzt wird sondern wie in der Mail angegeben ausgedruckt wird Soll er sich irgendwas aussuchen.
@Ratti: Machen wir einen Club "utf-8 geplagte Perl-Programmierer" auf?
Auch 'ne Alternative. Ich habe mir eigentlich überlegt, mir im Keller einen schalldichten Anspruchshaltungsraum(TM) zu bauen, in dem ich aufblasbare Imitationen von Freie-Software-Programmierern anbrülle, was ich alles fordere, und bis wann. Und daß sie mich beschissen haben. Und daß ich mein Geld zurückwill. Und ihren Vorgesetzten sprechen. SOFORT. :-)
*g* Naja, eigentlich habe ich auch was gegen Anspruchshaltung, aber Unicode wäre meines Erachtens was für Perl 6 gewesen, was man dadurch beschleunigt hätte und nicht in Perl 5 notdürtig mit haufenweise Bugs reinschustern. Just my 2 ¢. Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ "Software is like sex, it's better when it's free." -- Linus Torvalds