Polskie znaki w NetBeans dzięki UTF-8

Kilka miesięcy temu pisałem o kodowaniu plików XHTML w UTF-8. Niestety popularne narzędzia takie jak Netbeans ciągle mają problem z tym standardem kodowania. Jeżeli tworzymy nowy projekt i ustawiamy jego kodowanie na UTF-8 wszystko jest dobrze. Problemy zaczynają się później...

Modyfikacja pojedynczych plików porozrzucanych po dysku

NetBeans nie jest zwyczajnym edytorem, ale środowiskiem IDE i to powoduje, że edycja pojedynczych plików porozrzucanych po dysku jest o wiele bardziej kłopotliwa niż w prostych edytorach. Jeśli chcemy edytować pojedynczy plik PHP to mamy 2 wyjścia: stworzenie nowego projektu PHP (oczywiście w tym konkretnym przypadku) w folderze z tym plikiem lub przygotowanie sobie folderu na pliki tymczasowe. Pierwsze rozwiązanie jest mało eleganckie i powoduje tworzenie się nowego folderu z danymi NetBeans. Tworzymy sobie folder np. d:/tymczasowe i tam kopiujemy pojedyncze pliki, których mamy zamiar używać. W NetBeans tworzymy nowy projekt PHP i jako lokalizację podajemy wcześniej utworzony katalog. Jako kodowanie projektu ustawiamy UTF-8. Oczywiście ignorujemy ostrzeżenia o tym, że folder zawiera już pliki. Teraz możemy otwierać wszystkie pliki z tego folderu bez żadnych kłopotów z kodowaniem.

Problemy z BOM

BOM, który może przydać się dopiero w UTF-16 jest całkowicie zbędny w UTF-8, ale niektóre edytory takie jak Notatnik z Windows xp usilnie dodają go do plików zapisywanych przez siebie. Powoduje to problemy w interpretacji plików PHP przez serwer, co najczęściej można zauważyć przy braku obsługi sesji. Gdy tylko mamy taką możliwość zapisujmy pliki bez BOMu. Ewentualnie przed pracą w NetBeans możemy użyć programu Notepad++, który pozwala na konwersję kodowania do większości standardów.

Polskie znaki w JavaScript

NetBeans skutecznie pomaga w tworzeniu aplikacji opartych o JS - dopełnia kod, sprawdza poprawność, proponuje lepsze rozwiązania podczas pisania, dba również o przenośność kodu. I tak właśnie dla polskich znaków diakrytycznych owe IDE proponuje ich zamianę na encje. Niestety nie są to encje takie jak w HTML, ale kody szesnastkowe znaków. Trochę może to zaciemniać kod, ale lepiej robić tak niż mieć później kłopoty na innych konfiguracjach systemowych.

Nie tylko Polacy mają kłopot z ogonkami

Chciałbym na koniec pocieszyć, że nie tylko w naszym kraju jest kłopot z znakami diakrytycznymi. Większość państw europejskich ma swoje "ogonki" więc nie ma co się dołować... Lepiej jest tylko w państwach anglojęzycznych, natomiast dużo, dużo gorzej na bliskim i dalekim wschodzie.

I znów Microsoft dał popalić...

UTF-8 miało być lekiem na wszystko, ale dzięki nadgorliwości Microsoftu i dodawaniu w Notatniku informacji o BOM wyszło niestety jak zwykle.