System kodowania Unicode UTF-8 jest najlepszym, i zarazem najpopularniejszym który obsługuje znaki diakrytyczne. Niestety często spotykanym problemem jest to, że wykonany skrypt PHP ma problemy z ich wyświetleniem lub przetworzeniem. Może to być spowodowane zła konfiguracją serwer, brakiem meta tagu lub kodowaniem pliku. Poniżej postaram się pokazać, jak w prosty sposób temu zaradzić. 1. Zła konfiguracja serwera. Może się zdarzyć, że Twój serwer ma ustawione błędne kodowanie. Aby to sprawdzić wywołaj funkcję phpinfo(), a następnie odszukaj pozycję default_charset. Jeżeli przyjmuje ona wartość no value lub utf-8, to twój serwer jest skonfigurowany poprawnie. W przeciwnym wypadku, jeżeli posiadasz Windows’a wystarczy odtworzyć w edytorze plik php.ini, a następnie zakomentować linijkę default_charset(u mnie 814). Jeżeli postawiłeś serwer na systemie Linux, w pliku httpd.conf dodaj AddDefaultCharset utf-8 (o ile nie jest już tak ustawione. Możesz zrobić to jeszcze w całkiem inny sposób, dodając zaraz po otwarciu klamry PHP:
| 1 | ini_set('default_charset', 'UTF-8'); |
2. Kodowanie pliku.
Każdy plik wykonywany wraz z uruchomieniem Twojej strony (zaincludowany też), musi mieć ustawione odpowiednie kodowanie. Zmienić je możesz za pomocą większości edytorów,
jak np. Notepad++. Wystarczy że wejdziesz w sekcję Format,
a następnie wybierzesz Koduj w UTF-8 (bez BOM).
3. Nagłówek.
Jeżeli Twój kod znajduję się w szkielecie dokumentu HTML, upewnij się że zawiera on meta-tag:
| 1 | <meta http-equiv="Content-type" content="text/html; charset=utf-8"> |
W przypadku samego kodu PHP, dodaj na samym początku:
| 1 | header('Content-Type: text/html; charset=utf-8'); |
4. Zapytanie MySQL. Jeśli Twoje dane pobierane są z bazy danych, to właśnie w niej może tkwić problem. Aby to naprawić, dodaj to zaraz po połączeniu się z bazą danych:
| 1 | mysql_query("SET NAMES utf8"); |
I to by było na tyle. Pozdrawiam Jakub Cieślak.
Instalacja wirtualnego serwera na systemie Ubuntu, jest trudniejsza niż w przypadku pospolitego Windows’a. Należy jednak pamiętać, że Linux o wiele lepiej spełni zadanie wirtualnej maszyny z wielu oczywistych przyczyn. A więc zaczynajmy: 1. Zaczynamy od upewniania się, czy nasze oprogramowanie jest w pełni aktualne:
| 1 | sudo apt-get update |
2. Następnie instalujemy fundament naszego serwera, czyli Apache:
| 1 | sudo apt-get install apache2 |
3. Teraz PHP:
| 1 | sudo apt-get install php5 |
Opcjonalnie, możemy jeszcze teraz doinstalować najważniejsze biblioteki PHP:
| 1234 | sudo apt-get install php-pear sudo apt-get install php5-xsl sudo apt-get install php5-gd sudo apt-get install php5-ming |
4. Baza danych MySQL:
| 1 | sudo apt-get install mysql-server |
Aby serwer MySQL był w pełni zintegrowany z PHP, musimy dołączyć jeszcze odpowiednie komponenty:
| 12 | sudo apt-get install libapache2-mod-auth-mysql sudo apt-get install php5-mysql |
5. Dla ułatwienia naszej pracy, warto doinstalować jeszcze phpMyAdmn. Wklejamy do konsoli:
| 1 | sudo apt-get install phpmyadmin |
I postępujemy zgodnie ze wskazówkami instalatora. Następnie wpisujemy komendę:
| 1 | sudo gedit /etc/apache2/apache2.conf |
Otworzy nam się pewien plik, na koniec którego doklejamy poniższą linijkę:
| 1 | Include /etc/phpmyadmin/apache.conf |
Zapisz i zamknij plik. Gratulację! Od teraz, masz w pełni działający serwer!
Załóżmy, że skonfigurowaliśmy Apache pod SSL i nasz przykładowy serwis działa pod adresem https://tajne.moja-domena.pl. Jak przekierować na HTTPS użytkownika, który próbuje połączyć się z naszą stroną za pomocą nieszyfrowanego protokołu HTTP?
Poniżej kilka sposobów rozwiązania:
Używamy dyrektywy Redirect z modułu mod_alias wg wzorca:
Redirect [status] URL-path URL
czyli w httpd.conf wpisujemy:
<VirtualHost moja-domena.pl:80> ServerName tajne.moja-domena.pl Redirect permanent / https://tajne.moja-domena.pl/ </VirtualHost>
Szczegóły w dokumentacji Apache
Kanał ATOM
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
RewriteEngine on
RewriteCond %{SERVER_PORT} ^80$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
Podczas próby uruchomienia aplikacji opartej o framework Kohana3.2 na lokalnym Apache’u przywitał mnie Internal Server Error z informacją w logu:
.htaccess: order not allowed here
W pliku .htaccess był wpis:
# Protect hidden files from being viewed <Files .*> Order Deny,Allow Deny From All </Files>
Aby umożliwić korzystanie z dyrektywy Files w pliku .htaccess trzeba w konfiguracji Apache’a pozwolić mu na to przez:
AllowOverride Limit
Po restarcie serwera WWW znów powitał mnie błąd 500 z informacją w logu:
.htaccess: SetEnv not allowed here
W pliku .htaccess była próba ustawienia środowiska:
SetEnv development
I tutaj również nadrzędne AllowOverride None nie pozwalało użyć tej dyrektywy w pliku .htaccess.
Rozwiązaniem jest dopisanie do konfiguracji:
AllowOverride FileInfo
Ostatecznie sekcja Directory może wyglądać tak:
<Directory "/sciezka/do/katalogu/www/"> Options -Indexes FollowSymLinks AllowOverride Limit FileInfo Order allow,deny Allow from all </Directory>
Teraz trochę o logwatch’u. Jest to program, który dostarcza mi codziennie rano logi z serwera WWW do czytania przy porannej herbacie. Domyślnie logwatch skanuje wszystkie logi Apache wg zapisu w pliku konfiguracyjnym /usr/share/logwatch/default.conf/logfiles/http.conf:
LogFile = httpd/*access_log LogFile = apache/*access.log.1 LogFile = apache/*access.log LogFile = apache2/*access.log.1 LogFile = apache2/*access.log LogFile = apache2/*access_log LogFile = apache-ssl/*access.log.1 LogFile = apache-ssl/*access.log
Aby rozszerzyć sprawdzanie logów o inne pliki należy utworzyć plik /etc/logwatch/conf/logfiles/http.conf
i umieścić w nim namiary na konkretne pliki, np.
# konfiguracja dla niestandardowych plików LogFile = /var/log/apache2/test/access.log LogFile = /home/hekima/log/test2/access.log LogFile = /home/hekima/log/test3/access.log
Żeby szybko przetestować zmiany wystarczy odpalić:
sudo logwatch --mailto=moj@e-mail.pl