Apache - FCGI - Perl - Encoding kaputt

Alles, was den Apache betrifft, kann hier besprochen werden.

Apache - FCGI - Perl - Encoding kaputt

Postby j_d » 25. October 2018 09:26

Ich habe auf einem UTF-8-Linux-System einen Apache laufen. In /etc/apache2.conf und in der Host-Config (in /etc/apache2/sites-enabled/) habe ich "AddDefaultCharset utf-8" gesetzt. fcgid ist aktiviert und ruft meine index.pl auf, die als Optionen gesetzt hat:

Code: Select all
use utf8;
binmode(STDOUT,':utf8')


Auf dem gleichen Host habe ich auch eine MySQL-Datenbank laufen, die ich unter Schmerzen auf richtiges UTF-8 (utf8mb4) getrimmt habe:

Code: Select all
mysql> SHOW variables LIKE 'character%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8mb4                    |
| character_set_connection | utf8mb4                    |
| character_set_database   | utf8mb4                    |
| character_set_filesystem | binary                     |
| character_set_results    | utf8mb4                    |
| character_set_server     | utf8mb4                    |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+


Die index.pl verbindet sich bei Requests auf diese Datenbank mit der Option mysql_enable_utf8, um die Daten direkt als UTF-8-abzuholen.

Rufen wir also mal das Script (auf meiner UTF-8-Konsole) auf:

Code: Select all
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
Weiß
</body>
</html>


Also, HTTP und HTML-Header werden auf jeden Fall UTF-8 gesetzt.

Was ist jetzt das Problem? Nun, Wenn ich die Option "mysql_enable_utf8" beim Connect mit der Datenbank gesetzt habe, dann bekomme ich auf der Website (im Browser, nicht auf der Konsole) Mojibake:

Code: Select all
Wei�


Aber: wenn ich einem HTML-Element eine ID zuweise, die nicht-ISO-8859-1-kompatible Zeichen beinhaltet (z.B. id="文字化け" - Mojibake), DANN verschwindet die Mojibake:

Code: Select all
<span id="文字化け">Weiß</span>


Da ich das Problem auf der Konsole nicht reproduzieren kann, gehe ich davon aus, dass das Problem nicht in meinem Script liegt, sondern dass der Apache einen Hirnriss hat und meine Daten lieber vorher nochmal in ISO-8859-1 konvertiert. Nur, wenn das nicht möglich ist (weil Japanische Schriftzeichen z.B. nicht in ISO-8859-1 vorkommen), lässt Apache diesen Hirnriss und reicht meine Daten einfach als UTF-8 durch.

Dazu sollte noch gesagt werden, dass das Zeichen "�" so ungefähr das ist, was ich als Zeichen erwarten würde, wenn ich das UTF-8-Zeichen "ß" an eine ISO-8859-1-Ausgabe senden würde.

Jetzt kann ich zwar überall in meine Ausgaben Japanische Zeichen einfügen, aber das kann's doch nicht sein, oder?
j_d
 
Posts: 4
Joined: 25. October 2018 09:04
XAMPP version: Keine
Operating System: Reicht Linux?

Re: Apache - FCGI - Perl - Encoding kaputt

Postby Nobbie » 25. October 2018 21:07

Auf welchem Linux und insbesondere welche Hardware (CPU) passiert das, auf welchem System läuft MySQL und Apache?
Nobbie
 
Posts: 11219
Joined: 09. March 2008 13:04

Re: Apache - FCGI - Perl - Encoding kaputt

Postby j_d » 26. October 2018 09:13

Auf welchem Linux


Code: Select all
$uname -a
Linux <PC-Name> 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux


welche Hardware (CPU)


Code: Select all
$ cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family   : 21
model      : 101
model name   : AMD A10-9700 RADEON R7, 10 COMPUTE CORES 4C+6G
stepping   : 1
microcode   : 0x6006118
cpu MHz      : 1984.528
cache size   : 1024 KB
physical id   : 0
siblings   : 4
core id      : 0
cpu cores   : 2
apicid      : 16
initial apicid   : 0
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate ssbd vmmcall fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov
bugs      : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips   : 6986.90
TLB size   : 1536 4K pages
clflush size   : 64
cache_alignment   : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro acc_power [13]

[noch mal die gleichen Infos für die drei restlichen Threads]


Aber was zur Hölle soll denn die Hardware und das System damit zu tun haben? Das Problem ist doch offensichtlich: meine UTF-8-Konsole bekommt Daten, der Apache bekommt Daten. Meine Konsole interpretiert diese korrekt, der Apache verhunzt es. Solange das nicht ein extrem seltener Hardwarefail ist, ist das entweder ein Konfigurationsproblem oder ein Softwarebug - oder interpretiere ich die Eingangsdaten inkorrekt?
j_d
 
Posts: 4
Joined: 25. October 2018 09:04
XAMPP version: Keine
Operating System: Reicht Linux?

Re: Apache - FCGI - Perl - Encoding kaputt

Postby j_d » 29. October 2018 11:39

Könnt ihr inzwischen vergessen. Für meine sämtlichen Anfragen habe ich eine HTML-Datei, die ich zu Prozessanfang einlade:

Code: Select all
my $tmp_header;&file_read(\"/var/www/my_site/tmp_header.html",\$tmp_header,':utf8');
_utf8_on($tmp_header);


In der Datei habe ich jetzt den Kommentar:

Code: Select all
<!--ẞ-->


eingetragen (ein großes scharfes 'S'). Weil das Zeichen auch nicht in ISO-8859-1 vorkommt, wird der Dreck jetzt nicht mehr fehlerhaft encodiert, sondern einfach durchgereicht. Der Browser erkennt dann korrekt UTF-8, und die Mojibake ist verschwunden.

Im Jahre 2018 UTF-8, welches 1993 rausgekommen ist, nicht ordentlich unterstützen - das ist schon ein rechtes Armutszeugnis (entweder für die Apache- oder die CGI::Fast-Entwickler). Wie dem auch sei: kann geschlossen werden.
j_d
 
Posts: 4
Joined: 25. October 2018 09:04
XAMPP version: Keine
Operating System: Reicht Linux?

Re: Apache - FCGI - Perl - Encoding kaputt

Postby j_d » 29. October 2018 17:12

Ach, noch der Vollständigkeit halber: ich bekomme jetzt Warnungen in meine Apache-Logfiles geschrieben:

Code: Select all
mod_fcgid: stderr: [...] index.pl: Use of wide characters in FCGI::Stream::PRINT is deprecated and will stop wprking in a future version of FCGI at <mein Script und die Zeilennummer>


Ey, das ist so großartig, was einige Leute so für Code abliefern. Nicht mal eine ordentliche Fehlermeldung bekommen die noch hingerotzt.

Und der Grund, warum binmode setzen nicht funktioniert, ist laut diesem Posting:

http://git.661346.n2.nabble.com/Gitweb-running-as-FCGI-does-not-print-its-output-in-UTF-8-td7573415.html

, dass die Spezis, die den Code zu verantworten haben, ein veraltertes API verwenden, bei dem binmode nicht funzt. Stattdessen nageln die das einfach auf ISO-8859-1 fest, außer, sie bekommen Daten zugesendet, die da nicht reinpassen - und selbst dann noch rotzen sie mir die Logs voll. Sag mal, wer *programmiert* denn so einen Scheiß!? Und wer segnet sowas ab?

Und mit der verlinkten Lösung kann ich auch nix anfangen - weil ich nicht bereit bin, lobotomiertem Code hinterherzulaufen. Das ist ein UTF-8-System mit einer UTF-8-Datenbank, einem UTF-8-Script, und ich werde bestimmt keinem kaputten Modul hinterherrennen und meine Daten nochmal encodieren.

So, aber jetzt wirklich, kann geschlossen werden.
j_d
 
Posts: 4
Joined: 25. October 2018 09:04
XAMPP version: Keine
Operating System: Reicht Linux?


Return to Apache

Who is online

Users browsing this forum: No registered users and 4 guests