Podstrony
- telcocafe
- [PHP+MySQL] Problem z połączeniem mysqli('localhost', 'xxx', 'xxx', 'xxx'
- [PHP i MySQL] jak pobrac liczbe rezultatow Jak pobrac liczbe rezultatow???
- [MYSQL] ustawienia polskich znaków brak polskich znakow
- [PHP] Licznik pobrań tekstowy licznik pobran, bez MySQL
- Baza Danych mysql Zewnętrzna baza danych gdzie??
- [PHP+MySQL] Zapisanie pojedynczego wiersza Zapisanie pojedynczego wiersza z bazy
- No jak!!! Jak skonfigurować PHP do pracy z MySQL 4
- [php i mysql]problem ze skryptem :/ Unknown column 'asdf' in 'where clause'
- [mysql, php] Krzaki w php
- Pszukiwania bazy MYSQL Szukam bazy
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- forum-gsm.htw.pl
telcocafe
Postanowiłem przejść na UTF. Nie wiem, czy to do końca dobra decyzja (polskie znaki zajmują 2 bajty). Jak skonwertować treść w bazie danych z kodowania ISO-8859-2 na UTF-8?Dozwolone metody:
- funkcja w serwerze MySQL
- ryzykowny import i eksport danych w PhpMyAdmin
- czy pozostaje jeszcze bardziej rezykowny sposób: iconv (gdy dostępny) lub własna funkcja?
Postanowiłem przejść na UTF. Nie wiem, czy to do końca dobra decyzja (polskie znaki zajmują 2 bajty).
Och jej, aż tyle miejsca! ;) Ja używam od bardzo dawna.
Jak skonwertować treść w bazie danych z kodowania ISO-8859-2 na UTF-8?
Możesz zrobić zrzut, przekodować plik i wrzucić do bazy o kodowaniu UTF-8 ;) Jak masz wersję rozwojową skryptu to jakiś ton danych nie masz... Wystarczy zmienić kodowanie tabel oraz kodowanie w HTMLu na UTF-8 i gotowe. Coś do przekodowania na szybko przy edycji kodu to iconvem można.
I pamiętaj że stringi UTF-8 to nie stringi nie-UTF-8 i trzeba gdzieniegdzie stosować nieco inne funkcje :) Poza tym Python+Django rulez :P
I pamiętaj że stringi UTF-8 to nie stringi nie-UTF-8 i trzeba gdzieniegdzie stosować nieco inne funkcje Czyli czekają mnie jeszcze dodatkowe utrudnienia? Które funkcje mogą sprawiać problemy i dlaczego? Podobno są trudności z: strlen(), substr()... Z mb_string nie będę korzystał - rozszerzenie nie jest domyślnie uruchomione.
Użytkownik Ferrari edytował ten post 16 czerwiec 2008, 13:21
Zawsze i wszędzie używam UTF-8 i nie spotkałem się z trudnościami z tak podstawowymi funkcjami jak strlen() czy substr().
Zawsze i wszędzie używam UTF-8 i nie spotkałem się z trudnościami z tak podstawowymi funkcjami jak strlen() czy substr().
To chyba nie ciąłeś polskich znaków. Wytnij jeden znak z ą, a zobaczysz na czym ten problem polega.
Co do mb_*, to na każdym serwerze, na jakim pracowałem, były włączone owe funkcje.
Rzeczywiście strlen() liczy ilość bajtów zamiast ilości znaków. W 1. kolejności posypie się kompilator szablonów. UTF-8 jest znany od dawna, zaś PHP 5 został wydany w 2004 roku. Dlaczego nie pojawiła się pełna obsługa UTF-8?
Chyba na razie wstrzymam się ze zmianami. Ostatecznością jest przejście na mb_string(), lecz zmiany mogą trochę potrwać (nie wszystko da się wykryć i zamienić za pomocą V-Grep). W PHP6 będzie już obsługiwał UTF-8 - mb_* staną się zbędne.
Zakres znaków ISO-8859-2 jest dość wąski (brakuje np. dolnego cudzysłowu) - to przemawia za przejściem na UTF-8. Może lepiej zaczekać do wydania PHP 6? ;)
Użytkownik Ferrari edytował ten post 16 czerwiec 2008, 19:32
I będziesz miał ten sam problem - wciąż za mało serwerów z obsługą PHP 6.
A kompilator szablonów nie powinien się posypać. Nie ma czemu.
I do czego Ci V-Grep? Do konwersji izolatka => utf-8 są programy, które pozwalają na grupową konwersję plików...
// Edytowano
@niżej:
Na yoyo mb_* działa, bo mój CMS używa tych funkcji.
Użytkownik andrzej_aa edytował ten post 16 czerwiec 2008, 20:55
PHP 6 z zakorzenieniem się może mieć kłopoty. Starsze skrypty na pewno nie ruszą na tej wersji.
Do czego V-Grep? Choćby do masowej zamiany str* na mb_*. Nie wiem, co robić. Przeprowadzę jeszcze trochę testów dot. mb_string() - muszę zbadać ich wydajność i sprawdzić, czy rozszerzenie jest włączane przez większość adminów. Macie konta na jakichkolwiek darmowych hostingach? Zgłoście się na PW - po meczu podrzucę skrypt do odpalenia. :)
Myślę, że większość serwerów będzie obsługiwać zarówno php6 jak i php5, przełączane w panelu lub przez .htaccess (spotkałem się z tym przy okazji php4/php5)
Nie wiem, co robić. Przeprowadzę jeszcze trochę testów dot. mb_string() - muszę zbadać ich wydajność
A kiedy wreszcie nauczysz się tworzyć aplikacje internetowe? Ci mogę powiedzieć że ASCII będzie "najszybsze".
Jeżeli chcesz być programistą a nie script kiddie, który wyleci z każdej poważnej roboty musisz nauczyć się tworzyć aplikacje www, a nie dywagować co jest na serwerach, czego nie ma, co jest szybsze, co wolniejsze - w przypadku tworzenia funkcjonalnej strony www takie dywagacje nie mają miejsca bo nie ma na to czasu, ani nie jest to do niczego potrzebne. Zaleta UTF-8 jest taka że jest miej problemów gdy interfejs może być tłumaczony na inne języki, oraz większą zgodność z różnymi dodatkami, które z natury obsługują UTFa ze względu na jego szerokie spektrum znaków. Przy generowaniu PDFów, systemach wyszukiwarek (sphinx dla MySQL, czy też np. xapian, Lucene) latin2 może być nawet nieobsługiwany, natomiast UTF-8 będzie podstawą.
PHP 6 w porównaniu do PHP 5 nie będzie rewolucją, a jedynie ewolucją. Oczywiście tam gdzie teraz PHP5 nie ma lub jest byle jak PHP6 nie wejdzie bo badziewie PHP3/4-safe_mode klientów przestanie działać ;) Nie staraj się tworzyć funkcjonalności patrząc czy coś jest na darmowych serwerach, czy nie - tak to ograniczysz się do poziomu osCommerce :P taka wada PHP.