Problemy z polskimi znakami

[pTX]

Witam,

 

Nareszcie udało mi się znaleźć odpowiednie forum po WHT na którym sporo się udzielałem.

Po 13 latach wracam do reaktywacji moich dawnych stronek. Po zakupie hostingu, domeny wszystko wgrałem na serwer i niestety nie mam polskich znaków na żadnej stronie/forum.

Kodowanie znaków jest na UTF i wszystko powinno być w porządku. Niestety strony działają jedynie na PHP 5.5 i niżej (na 5.5 mam na przykład polskie znaki w treści a znów w menu nie ma, a na 5.4 nie mam w treści - newsach itd. a mam w menu strony).

 

Do tego potrzebował bym trochę informacji bo w google ciężko coś sensownego znaleźć - chciałbym przystosować swoje strony pod najnowsze PHP (są to raczej proste stronki, bez jakiś rozbudowanych CMSów). Ewentualnie kogoś kto by za mnie to zrobił wraz z kilkoma małymi poprawkami bo strona na niektórych podstronach się rozjeżdża.

 

Niestety 13 lat przerwy od stron, hostingów itd. robi swoje - sporo rzeczy zapomniałem i sporo się pozmieniało.

 

Z góry dziękuję za pomoc.

[l3szcz]

Cześć, to zazwyczaj ustawienia serwera lub bazy (głównie z kodowaniem znaków).
To raczej nic trudnego tylko trzeba by było zrobić zmiany w kodzie zapewne.

[pTX]

Właśnie w tym problem, że prawie każde moje dawne forum czy strona nie ma polskich znaków a kodowanie wydaje mi się, że jest poprawne. Dodatkowo tak jak pisałem wyżej zmieniając wersje PHP na serwerze (stare bo 5.2-5.5 na wyższych strony już nie działają). Te polskie znaki w treści się pojawiają a już krzaczki są w menu strony i na odwrót w zależności od wersji PHP. A znów na forach jest bez zmian - niezależnie od wersji PHP brakuje polskich znaków. 
 

Pisząc to: „

Ewentualnie kogoś kto by za mnie to zrobił wraz z kilkoma małymi poprawkami bo strona na niektórych podstronach się rozjeżdża.„

W pierwszym moim poście - miałem oczywiście na myśli odpłatnie. 

[l3szcz]

Okej, napisz.

[Sponsi]

Sekunda z AI, może tu coś znajdziesz. IMO i tak tak, czy siak, musisz to wszystko zaktualizować do 8.x minimum (chyba teraz minimum to 8.2, rekomendowane 8.4):

 

Yes, there are significant differences in how character sets and national characters are handled between these eras, primarily driven by a massive overhaul introduced in PHP 5.6. [1]

(Note: There is no official "PHP 5.7" release, as development jumped straight from 5.6 to PHP 7.0. The changes detailed below apply to PHP 5.6 and all subsequent versions). [1]

---

Key Differences at a Glance

Feature / Behavior	PHP < 5.5	PHP 5.6+ (and later)
Default default_charset	Empty or ISO-8859-1	UTF-8
htmlspecialchars() Default	ISO-8859-1 (varies by sub-version)	UTF-8
htmlentities() Default	ISO-8859-1	UTF-8
HTTP Content-Type Header	Sent without charset unless forced	Sent automatically as text/html; charset=UTF-8
Extension Encodings	Separate configuration options needed	Consolidated under default_charset

---

Detailed Breakdown of the Changes

1. The Global Shift to UTF-8

In PHP versions older than 5.5, PHP was mostly agnostic to encodings by default, or assumed Western European ISO-8859-1 (Latin-1). Starting in PHP 5.6, UTF-8 became the universal internal default. [1, 2, 3, 4]

2. Automatic HTTP Headers

Starting with PHP 5.6, if you do not explicitly set an HTTP content-type header, PHP will automatically inject Content-Type: text/html; charset=UTF-8. In older versions, it simply sent text/html, leaving the browser to guess the encoding or fall back to its own localized defaults. [1]

3. Behavioral Changes in String Functions

Functions like htmlspecialchars() and htmlentities() rely heavily on the default character set: [1, 2]

• In older PHP versions: If you passed national characters (like ä, ñ, ś, or я) to these functions without specifying an explicit encoding argument, they assumed Latin-1. [1, 2]
• In newer PHP versions: They assume UTF-8. If your legacy code passes an older single-byte string (like a Windows-1250 or ISO-8859-2 string) to these functions, they will return an empty string or garbled data because the input is invalid UTF-8. [1]

4. Streamlining Multi-byte Extensions

Previously, dealing with multi-byte national characters required managing separate, conflicting configuration rules across various tools. In 5.6+, the following deprecated, module-specific php.ini directives were consolidated under the unified default_charset: [1, 2]

• iconv.input_encoding, iconv.internal_encoding, and iconv.output_encoding
• mbstring.http_input, mbstring.http_output, and mbstring.internal_encoding [1]

Impact on Databases

If you are upgrading legacy code, remember that older PHP-to-MySQL environments often relied implicitly on latin1 connections. Moving forward, you must explicitly tell database extensions like PDO or mysqli to use UTF-8 (preferably utf8mb4 to fully support modern Unicode): [1, 2, 3, 4, 5]

php

// Example for PDO
$pdo = new PDO("mysql:host=$host;dbname=$db;charset=utf8mb4", $user, $pass);

Używaj kodu z rozwagą.

 

Are you planning to upgrade an old legacy system, or are you encountering garbled text/blank outputs after an environment switch? Let me know your exact scenario so I can provide targeted migration fixes!

 

[Kapitan_Bomba]

@Sponsi gdzie byłeś jak Cię nie było?

[psz]

https://dontpastetheai.com/pl

[Sponsi]

21 godzin temu, Kapitan_Bomba napisał(a):

@Sponsi gdzie byłeś jak Cię nie było?

Rodzina / praca / nie było pracy / życie / dupa / kwas / podróże / itd. ; )

1 godzinę temu, psz napisał(a):

https://dontpastetheai.com/pl

 

OK, kasujcie, niech sobie sam szuka kolega pomocy.