I ne samo to
Postojao bi još jedan gadan problem koji treba da se reši a to je istovremeno korišćenje latinice i ćirilice u okviru jedne stranice.
Naime, najčešće rešenje za ispravno prosleđivanje podataka u MySQL bazu je eksplicitno pozivanje par komandi u php-u koje treba da naznače serveru da će se u par sledećih redova koristiti određeni enkoding. Svi koji su ovo već radili znaju da bazi treba proslediti "set names cp1250" i "set collation_connection=cp1250_bin" primera radi za Windows-1250 charset.
Problem nastaje u trenutku kada je recimo potrebno da se pisanje ili čitanje "prešalta" na latinicu odnosno ćirilicu. To bi bukvalno značilo da bi skript za svaku promenu latinice i ćirilice morao da menja u bazi kolaciju što se nikad, ponavljam, nikad ne radi
Znači, teorijski korišćenje ćirilice i latinice (99,99% korisnika na forumu ipak koristi latinicu) bi moglo da se izvede ali po ceni ogromnog povećanja vremena čekanja na skidanje stranice.
UTF kao što sam rekao još uvek ima velikih nedostataka za sve jezike koji nisu "anglo-saksonskog" tipa. Zbog toga, većina administratora i dalje pribegava korišćenju Windows-1250 encodinga koji povereno radi iako je loša praksa. Da ne govorim o tome da kod nas ima provajdera koji neznaju kako da obezbede pravilno podešavanje kolacije što se inače radi u samom Appachu a ne MySQL-u
O ISO-8859-2 neću ni da govorim jer uglavnom pravi veće probleme nego UTF
Odužih...