Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: "ďťż" Na początku skryptu?
Forum PHP.pl > Inne > Hydepark
Wieviór
Używałem notatnika, teraz przestawiłem się na Scintillę. I używając obydwu programów miałem następujący problem, Używałem sesji i wywalało mi znany błąd "Headers Already Sent". Przesyłam ten plik do kumpla i okazuje się, że u niego pokazuje się na początku skryptu linijka:
Kod
ďťż


U nie tego zupełnie nie widać. Czy ktoś kiedyś się z czymś takim spotkał? Może to jakiś wirus? sad.gif
orson
witam ...

sprawa z kodowaniem ... przejscie z iso na utf lub z utf na iso w scite albo w notatniku [ten z xp chyba dziala w utf ale nie jestem pewnien] .. zaden wirus ... usun te 3 znaki i po problemie ...

pozdrawiam
Wieviór
No ale jak mam je usunąć skoro ja ich nie widzę biggrin.gif
bela
Zobacz w innym edytorze dry.gif
rogrog
z tymi znakami jest taki problem:

- u niego skrypt się przestaje wykonywać
- u mnie się wykonuje, ale wypisuje te trzy znaczki na początku
- w SciTe ani w Notatniku nic nie widać na początku. Problem ustąpił po przekopiowaniu całej zawartości do nowego pliku.

wygląda jakby jakiś nieznany syf na początku się pojawiał... tylko pytanie skąd ?
ARJ
odpowiedź jest prosta. plik został zapisany w utf, a w pliku jest dodane kodowanie iso. i z tąd pojawiają się te znaczki.
rozwiązania
  • zmienic kodowanie meta z iso na utf
  • zapisać plik edytorem w iso
hombrerro
Czesc

Mialem ostatnio ten sam problem. Zmienialem kodowanie calych serwisow z ISO na UTF 8. Poslugiwalem sie grzegrzółką do zmiany kodowania a rzeczone znaczki ze wszystkich przekodowanych stron usunalem za pomoca Mass Text Replacer ktory dostepny jest w wersji demo ale dzialajacej.
Wieviór
Sprawdziłem w dwóch innych edytorach. I rzeczywiście widać w nich te znaczki, no i dobra usuwam je i zapisuje, niestety wtedy nie działa mi już kodowanie utf i znów otwierając plik jestem przesrany bo są krzaczki.
W head tak mam:
  1. <meta http-equiv="Content-Type" content="text/html; charset=utf-8">


No i co z tego bo otwierając ten plik w innym edytorze pokazują mi się krzaczki, tzn. może te edytory nie obsługują UTF. To ktoś zna jakiś co obsługuje UTF, nie nazywa się Scintilla i jest gdzieś za friko?

A może ktoś poleci mi używanie innego kodowania, które spokojnie współpracuje z bazą danych i działa wszędzie normalnie? tongue.gif
yavaho
Cytat(Wieviór @ 2005-03-10 21:10:47)
Używałem sesji i wywalało mi znany błąd "Headers Already Sent".

Mialem to samo jak robilem strone z kodowaniem utf-8
Strone robielm w notataniku pozniej uzywalem programu do konwersji znakow (Gżegżółka XP). Gdy strony nie zostaly jeszcze przekonwertowane to wszystko bylo OK, ale jak perzekonwertowalem na standard utf-8 to od razu wywalalo mi bledy dotyczace header.

Jezeli masz jedna strone index do ktorej includujesz pozostale strony to wlasnie tylko index napisz sobie w notatniku. Utworz nowy plik i do niego wklej zawartosc z poprzedniego. Pozostale mozesz robic w innych edytorach.
Chodzi o to abyś nie uzywal swojego edytora do plikow w ktorych jest polecenie session_start(); - chyba ze znajdziesz inny edytor, w ktorym nie ma tego bledu.

Albo sprawdz jeszcze jedno: Uzyj buforowania wyjscia. Na poczatku pliku daj ob_start(); a na koncu ob_end_flush(); - ja tego nie testowalem, ale moze to wyeliminowac twoj problem.
SongoQ
Te dziwne znaczki na poczatku to BOM, czyli 3 bajty (0xEF 0xBB 0xBF) narzucone przez UTF-8.

Zauwazylem ze jesli zapisujemy w UTF-8 to na niektorych serwerach jest ok, a na niektorych sie popstostu nie parsuje lub pokazuja sie te znaczki na początku.
Jak zapiszemy w unicode to php wariuje zamiast pokazywac wynik to pokazuje source. Troche smieszna sytuacja.

Jest mozliwosc usuniecia tego tak jak @orson mowil, ale to jest nie prawidłowe poniewaz to jest wymagane przez UTF-8. To jest takie obejscie na sile. Plik w tym standardzie wymaga tych 3 bajtow, a jesli usuniemy to tak jakby plik byl bez naglowka.
Bielo
przed chwila walczylem z tym problemem i okazalo sie ze po zmianie default charset na serwerze na utf-8 wszystko jest ok. tylko nie wiem co zrobic jak sie dziala na cudzum serwerze
SongoQ
Poprawne kodowanie w pliku. Zauwazylem ze wiele edytorow zamiast zapisywac UTF-8 tak jak powinno, czyli na tylu bajtach ile jest wymaganych to zawsze zapisuje na 2.
DeyV
Edit+, PSPad, Zend studio, Dreamweaver MX 2004 - te edytory na pewno poprawnie radzą sobie z kodowaniem UTF-8 Mało tego - często lepiej obsługują te kodowanie, niż ISO-2
yavaho
Ja zauwazylem ze notatnik w WinXP tez niezle sobie radzi z UTF-8 ale pod jednym warunkiem:
Tworzymy czysty plik tekstowy. Wklejamy do niego jeden ze znaków kodowany w UTF-8 odpowiadający polskim czcionkom:
ą = Ä…
ś = Ĺ›
ź = ĹĽ
Zapisujemy plik. Potem otwieramy go ponownie i możemy już normalnie pisać w windowsie. Notepad automatycznie prawidłowo rozpoznaje kodowanie UTF-8 dla tego pliku.

Niestety nie da sie tego zrobic dla iso-8859-2
SongoQ
Tylko ze notatnik zawsze zapisuje BOM, jak by byla mozliwosc wylaczenia to by byl naprawde dobry.
sztosz
Jako że się przeżucilem na UTF-8 ostatnio i te krzczki mnie irytowały...

Dla tych co chcą zrozumieć winksmiley.jpg http://www.unicode.org/faq/utf_bom.html
Wieviór
Odnawiam super stary temat, który sam zresztą założyłem.

Wiem, że jest sporo osób, które używały Scite, ale przestały ze względu na problem z UTF-8. Ja wciąż używam Scite i mam rozwiązanie tego problemu.

Tworzyszysz stronę w Scite przy kodowaniu UTF-8, potem otwierasz inny edytor "EditPlus" np otwierasz ten plik, nic nie zmieniając zapisujesz. I tyle smile.gif

Pozdrawiam.
SongoQ
Po co takie kombinacje. Dobry edytor ktory nie zostawia BOM i juz.
Pucy
Ehhh, ale robie jak pisaliscie, wszystko na wszystkie spsoby i nic! Jezeli na stronie koduje w UTF-8 to pliki tez powinny byc zapisane w utf-8, tak? A co z przegladarkami? Np FF wywala mi na poczatku znak tabulacji i nie moge zmieniac juz naglowka, strasznie to wnerwiajace.
Wieviór
Cytat(SongoQ @ 8.08.2006, 13:45 ) *
Po co takie kombinacje. Dobry edytor ktory nie zostawia BOM i juz.


Bo ja np. bardzo lubię Scite'a :roll2:
Riklaunim
Crimson Editor ma 2 opcje odnośnie tego: "UTF-8 with BOM" i bez BOM
Pucy
W ogole jaka bzudra, przez caly czas wyskakwiwalo mi przed odpaleniem modelu widoku tabulacja przed definicjami strony. Skopoiwanie starszego pliku i zastapienie jego tresci usunelo ten problem. Wie ktos dlaczego?
nobarte
Pliki stron kodujemy UTF-8. W nagłówku strony umieszczamy także kodowanie UTF-8. W plikach .php kodowanych UTF-8 mogą się zdarzyć krzaki w polskich znakach. Na jednych serwerach taki problem występuje, na innych nie. W rozwiązaniu tego problemu może pomóc umieszczenie w plikach .php poniższy kod jako pierwszy wpis na danej stronie:
<? header("Content-Type: text/html; charset=utf-8"); ?>

Wystarczy, że umieścimy powyższy kod na głównej stronie przetwarzającej wszystkie inne.

--
Pozdrawiam,
nobarte
mls
SciTe ma opcję zapisu w formacie "UTF-8 cookie", gdzie znacznik BOM nie jest zapisywany...
polishprogrammer
problem ewidentnie prawdziwy

jest jeszcze jeden PRZYKRY aspekt calej sprawy

zarowno FF2 oraz IE6 (a moze rowniez inne - nie sprawdzalem) dostaja szajby kiedy w źródle strony pojawiaja się właśnie te "niewidoczne" znaczki.......

na pierwszy ogień idzie złe wygenerowanie źródła (VIDE: FF+webdeveloper toolbar > view generated source):
w moim przypadku tag BODY powedrowal przed HEAD :)
co mialo oczywiscie swoje implikacje ...... (bledy w wygladzie, bledy JS w MSIE w poprawnych skryptach!)

rowniez kod bynajmniej sie nie waliduje (valdiator.w3.org) ale to akurat najmniejszy problem :)

co ciekawe w moim przypadku felerne "zle znaki" UTF8/BOM znalazly sie w pliku frameworka odpowiedzialnym za sprawy bazodanowe....... dziwne bo oczywiscie pierwsze podejrzenia padaja na widok i jakies inkludowane elementy jak np. stopka html

najlepszym rozwiazaniem okazalo sie otwarcie pliku w edytorze HEX........ BOM widac bylo jak na dloni (z moglem znalezc rzadnego edytora tekstowego dla Linuksa z obsluga BOM dlatego posluzylem sie wspomnianym Hex editorem)

pozdrawiam. adam zygadlewicz
SongoQ
Wiekszosc "dobrych" edytorow radzi sobie z BOM i go poporostu nie zapisuje. Pod linuxa wystarczy mcedit
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.