Przede wszystkim pragnę wszystkich zgromadzonych powitać wszem i wobec.

bardzo proszę o pomoc bo straciłem już nadzieję na rozwiązanie.

Mam serwer apache, z php 7.3.
Mam prosty skrypt, który po ODBC pobiera dane a część posiada tekst cyrylicą.
Niestety uruchamiając skrypt w przeglądarce na kompie w sieci, wszystkie dane cyrylicą po ODBC wyświetlają się jako znaki zapytania.
Wyświetlając echo "napis cyrylicą" wszystko ładnie się wyświetla.

Podejrzewam apacha bo z kolei uruchamiając w bashu poprzez php skrypt.php wyświetla się wszystko prawidłowo i z odbc i z echo.
Gdzie się da ustawiłem UTF-8, w apachu, php dla cli i dla apacha, w nagówku pliku php. Próbowałem też bez ustawionego domyślnego kodowania w apachu i ustawione było tylko kodowanie w header pliku php. Wytłumaczcie mi proszę gdzie szukać przyczyny skoro teoretycznie to nie wina ODBC bo w bashu interpreter php wyświetla poprawnie ale też nie wina apacha bo tekst cyrylicą wywołany w pliku php też wyświetla się poprawnie. Będę wdzięczny za wszelką pomoc.

Skomplikowany problem to jest.

Czy w apache.conf użyłeś:

AddDefaultCharset Off
AddCharset UTF-8 .html

??

Sprawdź w dev toolsach w zakładce Network jaki jest Content-Type odpowiedzi. Jeśli jest tam inne kodowanie niż UTF-8, to rzeczywiście jest wina konfiguracji Apache. A jesteś pewien w ogóle, że ta Twoja baza jest w UTF-8?

Używałem i OFF i komentowałem i UTF-8
Nie bardzo rozumiem co miałby dać drugi wpis?




Content-Type text/html; charset=utf-8
baza raczej utf, wnioskuję po tym że w bashu z lini poleceń wszystko wyświetla prawidłowo.

w sumie tutaj efekt http://software.hanipol.com/admin/j.php

ręce mi opadają walczę z tym od wczoraj. Myślę czy nie odpalić ngix.

Na 100% Apache nie ma nic do tego. Masz prawidłowo ustawiony UTF-8, zresztą domyślnie jest ustawiony.

Miałem kiedyś podobne babolki z polskimi znakami w bazie. Spróbuj dać to zaraz po połączeniu się z bazą:

[PHP] pobierz, plaintext 
odbc_exec($conn, "SET NAMES 'UTF8'");
[PHP] pobierz, plaintext 

Jeśli to nie pomogło, to raczej baza ma inne kodowanie. Musiałbyć się dowiedzieć jakie i albo przetłumaczyć to w bazie na utf8, albo skonwertować dane w locie dla swojego skryptu.

Ale dlaczego w takim razie z poziomu basha wszystko działa prawidłowo ? Wnioskuję, że coś nie halo na drodze php->apache.
Oczywiście to co podałeś próbowałem i dupa:


Macie jakąś sprawdzoną metodę w PHP aby sprawdzić kodowanie ciągu?
Co ciekawe niemieckie, polskie znaki wyświetlają się prawidłow, tylko ta nieszczęsna cyrylica.
Właściwie wyświetlenie mi nie potrzebne a tylko wygenerowanie prawidłowego XML ale z poziomu przeglądarki. Ewentualnie poprzez przeglądarkę mogę wywołać linię poleceń i wtedy generować. Ale to strasznie druciarstwo.

Dziwne. Jesteś na 100% pewien, że odpalasz dokładnie ten sam skrypt w konsoli? Zajrzyj do źródła strony i zobacz jakie generuje znaczki.

Tak tak, jestem pewien. Efekt w bashu, locale oczywiście też wskazuje UTF-8

~# php j.php
from echo : AAAКоллекция, вдохновленная картинами Климта<br><pre>from odbc: Коллекция, вдохновленная картинами Климта<br>

Niestety nie wiem jak pomóc. Nie mam pojęcia dlaczego działa w konsoli.

Tak czy siak dzięki za zainteresowanie, ja właśnie też nie wiem

Na serio kiedyś miałem identyczne znaki zapytania jak nie ustawiłem SET NAMES. Mogę jeszcze sprawdzić czy taki skrypt w konsoli też mi wypluwa znaki zapytania czy litery, chociaż dziwne to by było, gdyby prawidłowo je zinterpretował. Wydaje mi się, że driver do bazy danych wyrzuca te znaki zapytania na wyjściu. Tylko dlaczego ta cholerna konsola dostaje prawidłowe znaki

EDIT

Zrobiłem test w czystym PHP i PDO, ale zadziałało mi bez SET NAMES. Nie wiem co się zmieniło, może w MySQL 8 to już nie jest potrzebne.

A może tak? Choć tu nie ma rozróżnienia na to gdzie działa, a gdzie nie:
https://stackoverflow.com/questions/2831168...ss-via-pdo-odbc

Niestety, efekt za każdym razem ten sam.

A w konsoli i w przeglądarce uruchamiane są te same wersje PHP?

Liczyłem że nie ale, tu i tu
phpinfo()
PHP Version => 7.4.7

A przepuść stringi z echo i z bazy przez mb_strlen() i strlen() i zobacz czy ilośći się zgadzają.

Kolejnym co bym strzelał to że CLI i Apache używają innych zestawów ini. Porównaj je. Tu masz skrypty do robienia diffów https://stackoverflow.com/questions/1623681...hpinfo-settings (jeśli cli i apache dają inne wyniki to jest ot jedyna możliwość)

To oczywiście już sprawdziłem, praktycznie zrównałem je aby nie było różnic.




w zasadzie różni się tym że w jednym opcja pusta a w drugim zakomentowana, więc praktycznie to samo w cli i w apachu
php.ini changes

php.ini#disable_functions: pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped
,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wsto
psig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_e
rror,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_
exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare, ----> php.ini.save :

Czy w opcjach tego źródła danych nie ma możliwości ustawienia kodowania?
https://www.easysoft.com/support/kb/kb01072.html

Oczywiście zaraz zerknę ale to jakiś wynalazek. Natomiast ciągle nie daje mi spokoju dlaczego php wyświetla prawidłowo a apache nie.