Opened by ALE1981 at 2019-09-20 11:41
User since
2011-03-19
3505 Artikel
BenutzerIn
![[Homepage]](/battie/theme/default/homepage.gif)
2011-03-19
3505 Artikel
BenutzerIn
Mein Provider bietet mir
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.
Empfehlungen richten sich stets nach Erfordernissen und dem was verfügbar ist. 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.
Ü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:
Meine Empfehlung: Zum Erzeugen utf8kodierter Zeichen Finger weg von der chr()-Funktion! Besser ist:
weil das die utf8kodierten Zeichen direkt anhand des Codepoint erzeugt.
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!
.
Last edited: 2019-10-05 14:24:05 +0200 (CEST)
Quote, da ist es schon OK dafür auf einem 5.16.3 zu entwickeln.This is perl 5, version 12, subversion 4 (v5.12.4) built for x86_64-linux
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.
Empfehlungen richten sich stets nach Erfordernissen und dem was verfügbar ist. 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.
Ü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"; # Щ
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.
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!
.
Last edited: 2019-10-05 14:24:05 +0200 (CEST)