regexp, substr(), unicode und ein Brett vor dem Kopf (solved) (Allgemeines zu Perl)

[thread]17658[/thread]

regexp, substr(), unicode und ein Brett vor dem Kopf [solved]

Tags: perl5 regex unicode Similar Threads

Readers: 20

Articles: hide open all | hide show old branches

+3 replies
guest SlowFox

2012-08-13 07:01
Nachdem ein Artikel hier - nach mehreren Stunden vergeblichem herumraten - dafür gesorgt hat, dass ich die Lösung für ein Problem fand, gibt es hier vielleicht auch jemanden, der sie mir erklären kann. Ausgangspunkt war das Skript:
Code: (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

use utf8; use Encode; use Encode::Byte; binmode(STDOUT, ":utf8"); sub do_it { my $from = $_[0]; my $name = undef(); if ($from =~ m/^(.*?) </) { print unpack('U0H*', $1) . "\n\n"; $name = substr($1, 0, 128); print unpack('U0H*', $name) . "\n\n"; } return; } my $from = 'AAçAA AñAA <a@b>'; $from = decode_utf8($from); do_it($from); print "--------------------------------------\n"; $from = 'AüAAA AA <a@b>'; $from = decode_utf8($from); do_it($from);
In der letzten Ausgabe ist (jedenfalls hier und mit Perl 5.10.1) ein Null-Byte am Ende des Strings enthalten, welches dort einfach nicht hingehört. Ändert man die Eingangsdaten (z.B. durch Weglassen des ersten Buchstabens beim ersten Aufruf), so verschwindet der Effekt. Das war nicht sehr erfreulich...

Nachdem ich irgendwann die Unicode-Verarbeitung von Perl verstanden hatte, aber immer noch ratlos war, bin ich hier vorbeigekommen und irgendwo über Devel::Peek gestolpert. Ersetzen der unpack-Befehle durch Dump brachte mich dann auf die Idee, testhalber
Code: (dl )

1 2 3

if (m =~ /.../) { $name = substr($1, 0, 128); }
durch
Code: (dl )

1 2 3 4

if (m =~ /.../) { my $temp = $1; $name = substr($temp, 0, 128); }
zu ersetzen (weil dump($1) irgendwie seltsam und nicht so recht wie die anderen Strings aussah). Lustigerweise war dadurch mein Problem behoben... bloss will ich immer noch nicht so recht einsehen, dass mein ursprünglicher Code falsch war. Kann mir jemand hier erklären, welchen Fehler ich gemacht habe? Im Manual steht jedenfalls

Quote
The numbered match variables ($1, $2, $3, etc.) and the related punctuation set ($+, $&, "$`", "$'", and $^N) are all dynamically scoped until the end of the enclosing block or until the next successful match, whichever comes first.

Last edited: 2012-08-13 08:02:11 +0200 (CEST)
- +2 replies
- pq
  
  2012-08-13 12:43
  User since
  2003-08-04
  12209 articles
  Admin1
  das scheint ein bug zu sein, der in 5.14 gefixt wurde. mit 5.14.2 hier kommt jedenfalls kein null-byte mehr. ich finde allerdings nicht den entsprechenden eintrag in der bugreport-liste.
  
  generell kann man aber sagen, dass es immer gut ist, $1 etc. möglichst schnell in variablen abzuspeichern, da $1 und Co. spezielle variablen sind.
  sie sind eigentlich nur referenzen auf den gematchten string, daher kannst du sowas lustiges machen:
  
  Code (perl): (dl )
  
  1 2 3 4
  
  my $s = "foo"; $s =~ m/(oo)/g; $s = "bar"; say $1;
  
  ausgabe ist nicht "oo", sondern "ar".
  funktioniert aber nur mit dem /g modifier.
  
  alternativ zu einer temporären variable geht auch immer "$1", also:
  $name = substr("$1", 0, 128);
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - guest SlowFox
    
    2012-08-14 11:25
    
    Merci.
    
    Irgendwie habe ich offenbar ein Talent, über solche Dinge zu fliegen... 1 Tag lang Fehler isolieren, und dann ist es noch nicht einmal meiner. Aber wenn's in neueren Versionen gefixed ist, hat das wenigstens ein Ablaufdatum.
    
    Quote
    generell kann man aber sagen, dass es immer gut ist, $1 etc. möglichst schnell in variablen abzuspeichern, da $1 und Co. spezielle variablen sind.
    sie sind eigentlich nur referenzen auf den gematchten string
    
    Was bei näherer Überlegung zwar fast eine zwingende Designentscheidung und im konkreten Fall unerheblich ist, in meinen Augen aber trotzdem gerne explizit in der man-Page vermerkt sein könnte...
    Last edited: 2012-08-14 11:29:38 +0200 (CEST)

View all threads created 2012-08-13 07:01.