2019-10-05T11:42:11 rosti

Mein Provider bietet mir

Quote

This is perl 5, version 12, subversion 4 (v5.12.4) built for x86_64-linux

, da ist es schon OK dafür auf einem 5.16.3 zu entwickeln.

2019-10-05T11:42:11 rosti

Und in meiner beruflichen Praxis musste ich mit der Abwärtskompatibilität sogar noch weiter runter gehen. So ist mein Framework abwärtskompatibel bis 5.6.1, abgesehen davon daß es auch in C und PHP 5.3.0 funktioniert.

2019-10-05T11:42:11 rosti

Empfehlungen richten sich stets nach Erfordernissen und dem was verfügbar ist.

2019-10-05T11:42:11 rosti

Und was den Umgang mit der Zeichenkodierung betrifft, habe ich in den letzten Firmen wo ich angestellt war gesehen wie man es besser nicht machen sollte. Z.B. sämtliche Bytesequenzen die über CGI/1.1 reinkommen in UTF-8-kodierte Zeichen umwandeln obwohl man zum Insert nach MySQL die Kodierung gar nicht braucht und von daher die Kodierung wieder ausschalten muss.

2019-10-05T11:42:11 rosti

Übrigens ist Latin1 auch nur eine Annahme was 0xC9 betrifft. charname LATIN CAPITAL LETTER E WITH ACUTE stimmt nämlich nur, wenn 0xC9 als Codepoint angenommen wird. Als Byte hingegen kann C9 auch ein ganz anderes Zeichen sein wenn man eine andere Kodierung annimmt:

Code (perl): (dl )

1
2
3
4
5
6
7
8

#!/usr/bin/perl

use strict;
use warnings;

my $c = chr 0xC9;
print "Content-Type: text/plain; Charset=ISO-8859-5\n\n $c";
# Щ

2019-10-05T11:42:11 rosti

Meine Empfehlung: Zum Erzeugen utf8kodierter Zeichen Finger weg von der chr()-Funktion! Besser ist:

Code (perl): (dl )

   $c = pack "UU", 0xC9, 0x20AC;

weil das die utf8kodierten Zeichen direkt anhand des Codepoint erzeugt.

   $c = "\x{C9}\x{20ac}"

1
2

use utf8;
$c = 'É€';

2019-10-05T11:42:11 rosti

Im Übrigen habe ich geschriebe daß lc() und uc() nur mit kodierten Zeichen funktionieren. Mit Bytes hingegen funktionieren lc() und uc() nicht. Darüber müssen wir nicht streiten. Der von Dir gezeigte Code bestätigt ja diesen Fakt!
.