HTML::Entities - decode_entities() erzeugt kein Unicode sondern Latin1 (gelöst) (Fragen zu Perl-Modulen) - Perl-Community.de

Start · Board · Anwendungen/Programme/Skripte in Perl · Fragen zu Perl-Modulen

2024-04-27 09:46:56
Europe/Berlin
Einloggen (Registrieren)
- Einstellungen
- Statistics
Jemand zu Hause?
0 Benutzer online

[thread]21549[/thread]

submit to reddit

HTML::Entities - decode_entities() erzeugt kein Unicode sondern Latin1 [gelöst]

[gelöst]

Tags: perl5 Ähnliche Threads

Leser: 8

Articles: hide open all | hide show old branches

Teilbäume:
HTML::HTML5::Entities (5 Artikel) 2024-03-21 12:13
Hinweis Text::Query für Suchterme (3 Artikel) 2024-03-23 14:30
Problem war Modul Encode (5 Artikel) 2024-03-22 21:26

+41 replies
GwenDragon

2024-03-19 12:49
User since
2005-01-17
14533 Artikel
Admin1
HTML::Entities::decode_entities soll laut Perldoc Unicode erzeugen.

Quote
decode_entities( $string, ... )
This routine replaces HTML entities found in the $string with the corresponding Unicode character.
https://metacpan.org/release/OALDERS/HTML-Parser-3...

Tut es aber nicht.
Code (perl): (dl )

1 2 3 4 5

use strict; use warnings; use 5.020; use utf8; use HTML::Entities (); my $s = HTML::Entities::decode_entities("ä"); say $s =~ /\xE4/;
Ergibt 1.
Aber \xE4 ist eben das ä in Latin1 und nicht Unicode.

Linux Perl 5.36
HTML::Parser ist 3.81

Das ist ganz besonders toll, wenn es Daten gibt die sowohl UTF-8 kodiert sind und HTML-Entity-kodiert. :-(

Hat jemand eine Lösung parat?
Last edited: 2024-03-19 13:04:20 +0100 (CET)
die Drachin, Gwendolyn

Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
- rosti
  
  2024-03-19 13:25
  
  User since
  2011-03-19
  3194 Artikel
  BenutzerIn
  
  say zeigt Dir den Codepoint und der ist völlig korrekt. MFG
  
  PS: Das Zeichen selbst ist jedoch Latin, eben getestet.
  Last edited: 2024-03-19 13:29:05 +0100 (CET)
- barney
  
  2024-03-19 13:36
  User since
  2008-08-31
  128 Artikel
  BenutzerIn
  Ja, das ist die Doku von HTML::Entities ein bisschen ungenau. In deinem Beispiel kommt das 'ä' als latin-1 zurück. Bei der weiteren Verwendung in Strings `"⛄%s"`, die Perl intern als utf-8 kodiert, erfolgt automatisch ein Upgrade. Das kann man auch mit `utf8::upgrade()` erzwingen. Das Matching erfolgt in beiden Fällen auf Codepoint Ebene.
  
  Code: (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12
  
  use strict; use warnings; use 5.020; use utf8; use HTML::Entities (); use Devel::Peek; my $s = HTML::Entities::decode_entities("ä"); Dump "⛄$s"; Dump $s; utf8::upgrade($s); say $s =~ /\xE4/; Dump $s; say $s =~ /\xE4/;
  
  Der Standardtip ist dass man Eingangsdaten die UTF-8 kodiert reinkommen als allererstes dekodiert. Beim rausschreiben dann wieder kodiert.
  
  modedit Editiert von GwenDragon: mod-Tag repariert
  Last edited: 2024-03-20 10:12:06 +0100 (CET)
- rosti
  
  2024-03-19 13:43
  
  User since
  2011-03-19
  3194 Artikel
  BenutzerIn
  
  Andererseits ist es aber auch unsinnig, HTML::Entities jenseits von ASCII anzuwenden.
- +6 replies
- GwenDragon
  
  2024-03-20 10:16
  
  User since
  2005-01-17
  14533 Artikel
  Admin1
  
  Aus irgendeinem Grund funktioniert das Matching nicht immer nach decode_entities().
  Ich versuche nun einen Testcase zu bauen und probiere es auf Linux und Windows.
  
  //EDIT: decode_entities ist unvollständig und zudem nur korrekt mit Latin1 verwendbar.
  Extrem unlustig, dass Browser besser HTML parsen können als Perl selbst.
  Last edited: 2024-03-20 15:06:33 +0100 (CET)
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - +5 replies
  - haj
    
    2024-03-20 15:53
    
    User since
    2015-01-07
    527 Artikel
    BenutzerIn
    
    Mögliche Unterschiede liegen nicht bei HTML::Entities, sondern bei der Interpretation von \x-Escapes. Die ist in perlop erläutert. Bei Werten bis 255 wird das plattform-spezifische Encoding benutzt. Wenn Du unter MS-DOS oder auf einer EBCDIC-Plattform bist, dann ist \xE4 kein ä.
    
    Hast Du denn einen Testcase?
    - +4 replies
    - GwenDragon
      
      2024-03-20 16:38
      
      User since
      2005-01-17
      14533 Artikel
      Admin1
      
      Die Quelle ist eine UTF-8-Datei, und Linux als OS, also UTF-8 ist da per se gesetzt.
      Ich lese ein ohne ein :encoding(…) beim Offnen zu setzen.
      Last edited: 2024-03-20 16:45:03 +0100 (CET)
      die Drachin, Gwendolyn
      
      Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
      - +3 replies
      - haj
        
        2024-03-20 17:29
        
        User since
        2015-01-07
        527 Artikel
        BenutzerIn
        
        Den Teil mit dem HTML-Text verstehe ich der kommt mir auch nicht komisch vor. Es bleiben noch ein paar Unklarheiten zu Deinem Code im anderen Zweig:
        
        Woher kommt $terms? Können da Regex-Sonderzeichen das Ergebnis verfälschen? In dem Fall müsstest Du /\Q$terms/ schreiben.
        Warum use utf8;? Mit use utf8; müssen Literale im Quellcode nicht decodiert werden, das macht Perl selbst. Aber Du hast gar keine Literale in dem Scope!
        Warum eval?
        
        +2 replies
        
        GwenDragon
        
        2024-03-20 18:55
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        $terms ist ein per Formular udn GET übergebene Zeichenkette (UTF-8, Parameter URL-encoded). Also ist dann bei find für ä dann ?find=%C3%A4
        
        $terms kann auch nur äöü oder test sein, muss kein kein regex sein.
        Kann aber auch test|asdf|äöü sein, also ein regex.
        
        das use utf8; ist nur ein nicht gelöschtes Überbleibsel, mein Fehler.
        
        Warum eval? Damit bei defekten Regex das Programm weiter läuft, aber dann als Nichst gefunden anzeigen kann.
        Last edited: 2024-03-20 18:59:54 +0100 (CET)
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        haj
        
        2024-03-20 20:16
        
        User since
        2015-01-07
        527 Artikel
        BenutzerIn
        
        Danke für die Erklärungen.
        
        Dann fehlt mir immer noch ein Beispiel, in welchen Fällen HTML::Entities (oder HTML::HTML5::Entities) danebengreifen.
        
        Ein Nachsatz zum Thema eval: Wenn man per Formular reguläre Ausdrücke angeben kann, dann hast Du hoffentlich nur brave Benutzer. Ein Problem sind nicht Ausdrücke, bei denen Perl den Dienst verweigert, sondern solche, die "endlos" laufen. Das kriegen manche auch ohne bösen Willen hin, sondern einfach durch Schlamperei.
- haj
  
  2024-03-20 15:41
  
  User since
  2015-01-07
  527 Artikel
  BenutzerIn
  
  2024-03-19T11:49:29 GwenDragon
  Aber \xE4 ist eben das ä in Latin1 und nicht Unicode.
  
  Das ä hat in Unicode den Codepunkt U+00E4. Mit welchem \x-Wert hättest Du erwartet, es zu finden?
- GwenDragon
  
  2024-03-20 15:48
  
  Subtree with 6 replies: HTML::HTML5::Entities
  User since
  2005-01-17
  14533 Artikel
  Admin1
  Ich versuche es mal mit was neuerem: HTML::HTML5::Entities
  
  //EDIT:
  Der Schnippsel hilft nicht.
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12
  
  my $contains_term = 0; eval { use HTML::HTML5::Entities; use Encode qw/decode encode/; $terms = decode('UTF-8',$terms); # in Perls interne Zeichenkette $contents = decode('UTF-8',$contents); # in Perls interne Zeichenkette $contents = HTML::HTML5::Entities::decode($contents); # HTML Entities dekodieren $contains_term = ($contents =~ /$terms/); # Matcht es? };
  
  Last edited: 2024-03-20 19:00:23 +0100 (CET)
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
- +22 replies
- GwenDragon
  
  2024-03-21 12:38
  
  User since
  2005-01-17
  14533 Artikel
  Admin1
  
  Ich versuche mal zu erklären, um was es geht; der Fall ist folgender auf einem Linux-System ein 15 Jahre altes CGI, das Dateien im Dateisystem durchsucht.
  Klappt bei Nur-ASCII-Suchterm auch wunderbar.
  
  Formular sendet UTF-8-kodierten Suchstring (accept-encoding gesetzt auf utf-8) per GET (HTML) an ein Perl-CGI
  
  Parameter für Suchterm $term einlesen mit
  $term = CGI::param('term');
  
  Datei mit UTF-8- und HTML-Entities-kodierten Inhalten öffnen
  open ($fh, '<', $filename)
  
  Einlesen in eine Zeichenkette $content einlesen per
  while ($line = <$fh>) { $content .= $line; }
  
  Mit decode $content in Perls Zeichenketten umwandeln
  Encode::decode('UTF-8', $content);
  
  Mit decode_entities in $content die HTML-Entities ersetzen
  $content = HTML::Entities::decode($content);
  
  Später prüfen, ob gefunden
  $found = 0; if ($content =~ /$term/si) { $found++ }
  
  Irgendwas falsch an dem logischen Ablauf? Hab ich was vergessen?
  
  Ich weiß ja wie sowas programmiert wird, ist stolpere nur über das Problem, dass Perl isn interne Format kodiert oder auch nicht.
  Last edited: 2024-03-21 12:43:12 +0100 (CET)
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - +3 replies
  - rosti
    
    2024-03-21 13:19
    
    User since
    2011-03-19
    3194 Artikel
    BenutzerIn
    
    Beim Suchen gibt es 2 Möglichkeiten. Entweder Du bleibst bei der Bytesemantic oder Du schaltest auf Zeichenorientierung. Und zwar sowohl beim Suchstring als auch beim Text der durchsucht werden soll.
    
    Und jetzt kannste mal ausrechnen wieviele Möglichkeiten es gibt das falsch zu machen. Eine Auswahl:
    1. Zeichenorientierung (CS) im Suchausdruck, Byteorientierung (BS) im Text
    2. Wie 1. nur umgekehrt
    3. CS utf8 im Suchausdruck, CS Latin im Text
    4. wie 3. nur umgekehrt
    5. BS utf8 im Suchausdruck, CS utf8 im Text
    6. wie 5. nur umgekehrt
    
    und dann gäbe es noch sehr viele weitere Möglichkeiten der Zeichenkodierung ;)
    
    Mein Tipp: Bleibe bei der Bytesemantic.Dann muß lediglich die Kodierung im Suchausdruck dieselbe sein wie die im zu durchsuchenden Text.
    
    .
    - +2 replies
    - haj
      
      2024-03-21 13:42
      
      User since
      2015-01-07
      527 Artikel
      BenutzerIn
      
      2024-03-21T12:19:44 rosti
      Mein Tipp: Bleibe bei der Bytesemantic.Dann muß lediglich die Kodierung im Suchausdruck dieselbe sein wie die im zu durchsuchenden Text.
      
      Das ist Unsinn. GwenDragon hat geschrieben, dass auch reguläre Ausdrücke möglich sind, und dann nützt das gleiche Encoding gar nichts. Ein /^.$/ matcht in Charakter-Semantik ein einzelnes €, in Byte-Semantik nicht, weil das €-Zeichen als drei Bytes daherkommt.
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13
      
      use 5.032; my $e = "\N{EURO SIGN}"; my $term = '^.$'; my $term3 = '^...$'; say "Characters mit '$term': " , $e =~ /$term/; # 1 say "Characters mit '$term3': ", $e =~ /$term3/; # kein Match { use bytes; say "Bytes mit '$term': ", $e =~ /$term/; # kein Match say "Bytes mit '$term3': ", $e =~ /$term3/; # 1 }
      - rosti
        
        2024-03-21 13:51
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Quote
        weil das €-Zeichen als drei Bytes daherkommt.
        
        Eben. Von daher muß der Suchstring diese 3 Bytes beinhalten. Im Grunde genommen passiert der Vergleich immer auf Byteebene. Weil Dateien eben Bytesequenzen sind.
  - +13 replies
  - haj
    
    2024-03-21 13:59
    User since
    2015-01-07
    527 Artikel
    BenutzerIn
    
    2024-03-21T11:38:40 GwenDragon
    Hab ich was vergessen?
    
    Ja, aber es ist schwer zu sagen, ob das nur zwecks der Kürze oder systematisch ist.
    
    Du musst auch den $term decodieren (oder use CGI '-utf8'; schreiben).
    Encode::decode ersetzt nicht in-place, Du musst den Rückgabewert wieder auf $content zuweisen.
    Du prüfst nicht, ob die Datei wirklich korrekt UTF-8-codiert war. "Früher mal" war ISO-8859-1 das Standard-Encoding im Web. Mit Entities läßt sich so jeder Unicode-Character darstellen, aber ein ä geht in ISO-8859-1 auch als ä.
    - +12 replies
    - GwenDragon
      
      2024-03-21 19:14
      
      User since
      2005-01-17
      14533 Artikel
      Admin1
      
      Tut mir leid, im Code ist eine Zuweisung drin für term und content, habe ich bei der rohen Beschreibung etwas geschlampt beim Posten.
      Ich benutze eigentlich immer Encode::decode('UTF-8', ...) wenn die Datei UTF-8 ist.
      Da ist doch dann wohl das Pragma CGI qw/-utf8/ obsolet, oder.
      
      Die Datei ist korrekt UTF-8.
      file t.txt zeigt mir t.txt: Unicode text, UTF-8 text
      Und hexdump:
      
      Code: (dl )
      
      1 2 3 4 5 6 7 8 9 10
      
      root@srv ~ # hd < t.txt 00000000 54 65 73 74 20 66 c3 bc 72 20 55 6d 6c 61 75 74 |Test f..r Umlaut| 00000010 65 3f 0a 6d 65 74 61 2d 63 72 65 61 74 69 6f 6e |e?.meta-creation| 00000020 5f 64 61 74 65 3a 20 32 30 32 34 2d 30 33 2d 32 |_date: 2024-03-2| 00000030 31 54 31 35 3a 35 34 3a 32 34 0a 0a 46 c3 bc c3 |1T15:54:24..F...| 00000040 9f 65 20 28 61 6c 73 20 55 54 46 2d 38 29 20 75 |.e (als UTF-8) u| 00000050 6e 64 20 26 61 75 6d 6c 3b 26 6f 75 6d 6c 3b 26 |nd äö&| 00000060 75 75 6d 6c 3b 20 28 6b 6f 64 69 65 72 74 20 61 |uuml; (kodiert a| 00000070 6c 73 20 48 54 4d 4c 2d 45 6e 74 69 74 c3 a4 74 |ls HTML-Entit..t| 00000080 29
      
      46 c3 bc c3 9f 65 = Füße
      Last edited: 2024-03-21 19:24:28 +0100 (CET)
      die Drachin, Gwendolyn
      
      Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
      - +11 replies
      - haj
        
        2024-03-22 00:09
        
        User since
        2015-01-07
        527 Artikel
        BenutzerIn
        
        2024-03-21T18:14:18 GwenDragon
        Ich benutze eigentlich immer Encode::decode('UTF-8', ...) wenn die Datei UTF-8 ist.
        Da ist doch dann wohl das Pragma CGI qw/-utf8/ obsolet, oder.
        
        Es geht nicht um die Datei, sondern um den $cgi->param. Entweder musst Du den decodieren oder use CGI qw/-utf8/; verwenden.
        
        Ich habe mal ein vollständiges Programm um Deine Datei gestrickt.
        
        Code (perl): (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 29 30
        
        use 5.024; use autodie; use Encode qw( decode encode ); use HTML::Entities; use URI::Escape; open (my $fh,'<','t.txt'); my $content; { local $/ = undef; $content = <$fh>; } $content = decode('UTF-8',$content,Encode::FB_CROAK); $content = decode_entities($content); my @terms = ( "\N{LATIN SMALL LETTER A WITH DIAERESIS}", "\x{e4}", chr 228, decode('UTF-8',"\xc3\xa4"), decode('UTF-8',uri_unescape("%c3%a4")), ); for my $term (@terms) { my $for_terminal = encode('UTF-8',$term); while ($content =~ /$term/g) { say "Treffer: '$for_terminal' an Position " . pos $content; } }
        
        Die Ausgabe:
        
        Code: (dl )
        
        1 2 3 4 5 6 7 8 9 10
        
        Treffer: 'ä' an Position 81 Treffer: 'ä' an Position 108 Treffer: 'ä' an Position 81 Treffer: 'ä' an Position 108 Treffer: 'ä' an Position 81 Treffer: 'ä' an Position 108 Treffer: 'ä' an Position 81 Treffer: 'ä' an Position 108 Treffer: 'ä' an Position 81 Treffer: 'ä' an Position 108
        
        In allen fünf Varianten, den $term hinzuschreiben, liefert sowohl die umgewandelte Entity wie auch das explizite ä in "Entität" einen Treffer.
        
        Wie mein Mathelehrer in solchen Fällen zu sagen pflegte: Man kann sich des richtigen Ergebnisses kaum erwehren!
        
        rosti
        
        2024-03-22 08:59
        
        Subtree with 4 replies: Hinweis Text::Query für Suchterme
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Die Zeichenorientierung (decode) einzuschalten ist sinnvoll wenn case-insensitive gesucht werden soll. Also wenn es um Zeichen geht.
        
        Und für komplexe Suchterms empfehle ich Text::Query. Suchen im Stil von Suchmaschinen. Text::Query nutze ich seit 20 Jahren. Und ja: Zeichenorientiert UND Suchterms via CGI.
        
        http://rolfrost.de/find
        
        d.h. daß auch Umlaute Case-Insensitive gefunden werden.
        Last edited: 2024-03-23 14:30:30 +0100 (CET)
        
        GwenDragon
        
        2024-03-22 09:23
        
        Subtree with 6 replies: Problem war Modul Encode
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Ich dekodiere beide ja nach UTF-8 mit Encode::decode.
        Aber das
        
        Quote
        $content = decode('UTF-8',$content,Encode::FB_CROAK);
        
        hat mich drauf gebracht, noch mal genau auf decode zu schauen.
        
        Ich hatte früher mal
        eval { $content = decode('UTF-8',$content) };
        sowie
        eval { $term = decode('UTF-8',$term) };
        genutzt, damit bei Dekodierungsproblemen Perl keine Ausnahme wirft.
        
        Kaum aus dem eval genommen, klappte es nicht mehr.
        
        Dann habe ich bei dem fremden Linux-Server doch mal die Module für Encode nachgeforscht. Und siehe da, die waren mehr als 5 Jahre alt, Perl ist 5.28(!), und nicht mehr aktuell.
        So ist das, wenn Perl-Legacy-Programme auf aktuellen Linux- und Windows-Testsystemen laufen und dann auf einen fremden Server portiert werden sollen.
        
        Manche Hoster sind ziemlich schludrig bei Perl auf Webhosting. Da muss ich erst mal den Support des Hosters anfragen, dass der aktualisiert. Mal sehen, ob es dann klappt.
        Last edited: 2024-03-22 10:04:07 +0100 (CET)
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - rosti
    
    2024-03-21 15:22
    
    User since
    2011-03-19
    3194 Artikel
    BenutzerIn
    
    Du bekommst via CGI/HTTP keine Zeichen sondern eine Bytesequenz. Ebenso ist Deine Datei eine Bytesequenz. Und diese Bytes kannst Du vergleichen. Ein Einschalten der Zeichenorientierung ist weder sinnvoll noch notwendig.
    
    MFG
  - +4 replies
  - rosti
    
    2024-03-21 16:16
    
    User since
    2011-03-19
    3194 Artikel
    BenutzerIn
    
    Also wenn Deine Entities like ä in den Dateien so drinstehen dann machs doch mit der Suche einfach umgekehrt und erzeuge aus ä (egal ob utf8 oder latin) die ä und analog die Anderen E. im Suchausdruck.
    
    .
    - +3 replies
    - haj
      
      2024-03-21 17:38
      
      User since
      2015-01-07
      527 Artikel
      BenutzerIn
      
      Das ist eine dumme Idee.
      
      Wenn in der Datei dann ein ä drinsteht und Du suchst nach einem a, dann ist das ein Treffer, auch wenn Du im Suchstring die Entities ersetzt.
      
      Reguläre Ausdrücke wie qr/\w/ oder qr/\d/ funktionieren nur mit Characters, nicht mit Bytes. Wenn man sowas auf UTF-8-encodierte Strings losläßt, gibt's unsinnige Resultate, und auch bei Entities: Ein &leftarrow; matcht qr/\w/, weil eben ein "l" und ein "e" usw. drin sind.
      - +2 replies
      - rosti
        
        2024-03-21 17:54
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Natürlich funktionieren Reguläre Ausdrücke mit Bytes aber sowas von! Und zwar schon immer!
        
        Und wenn Du in einer Datei ein ä suchst muß auch im Suchterm ä drinstehen. Sonst wird das nix ;)
        
        GwenDragon
        
        2024-03-21 19:21
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Klar kann man Bytesequenzen matchen. Hier Lesende sind ja immer dankbar für Hinweise.
        
        Aber beim Thread geht es mir um das Finden der Umlaute und nicht deren HTML-Entitäten.
        Es hat einen Grund warum der so heißt: "HTML::Entities - decode_entities()" ;-)
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
- +2 replies
- GwenDragon
  
  2024-03-24 17:48
  
  User since
  2005-01-17
  14533 Artikel
  Admin1
  
  @rosti @haj @braney Danke an euch Kollegen, die ihr versucht haben, mich mit Tipps in die richtige Richtung zum Entwanzen zu bringen.
  
  Manchmal liegt es doch nicht an der Programmiererin sondern and der installierten Software im Zielsystem.
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - rosti
    
    2024-03-24 18:23
    User since
    2011-03-19
    3194 Artikel
    BenutzerIn
    
    Danke zurück!
    
    Schade daß es so ruhig um Perl geworden ist. Also, ich habe mal ne Zeitlang geglaubt daß c++ was ganz besonderes sei. Das ist es vielleicht auch. Aber an Perl kommt c++ nicht ran. Und wenn jetzt jemand meinen sollte, mit c++ wären die Prinzipien von OOP besser umgesetzt bzw. umsetzbar, den muß ich leider enttäuschen. Webentwicklung mit c++ ist möglich aber nicht sinnvoll.
    
    Denn eine solche Vielseitigkeit wie sie Perl bietet, davon ist c++ weit entfernt. Und auch hier in diesem Thread sehen wird doch, daß Probleme mit Zeichenkodierung lösbar sind. Und wenns nur ein Upgrade ist, in Perl im schlimmsten Fall eine Sache von Minuten.
    
    Und sicher doch sind Perl5-Objekte für alles offen. Das sind C++, PHP und JavaScript-Objekte auch. Weder ein PHP noch ein C++ Profi konnte mir bisher den Sinn privater Eigenschaften plausibel erklären.
    
    mfg
    
    PS: Das Lustige an C++ ist, daß Eigenschaften von Instanzen als Class-Member deklariert sein müssen:
    
    Code: (dl )
    
    1 2
    
    response.i = 1; // Versuch einer Zuweisung 'class Response' has no member named 'i' // sagt Compiler
    
    Last edited: 2024-03-24 19:04:42 +0100 (CET)

View all threads created 2024-03-19 12:49.