2011-11-08 11 views
8

Mam bloga (oparty na wordpress). I spróbuj sprawdzić w walidatorze w3c jedną z moich stron. Pierwszym błędem jest:Błąd sprawdzania poprawności HTML: Znaki inne niż spacje znalezione przed DOCTYPE

Line 1, Column 1: Non-space characters found without seeing a doctype first. Expected <!DOCTYPE html>. 
<!DOCTYPE html><!-- HTML 5 --> 

Również DebugBar (http://www.my-debugbar.com/wiki/IETester/HomePage) zgadza się i pokazują dwa niewidoczne znaki przed <! kiedy otworzyć tę samą stronę z " HTML Sprawdź "zakładkę wewnątrz tego narzędzia. ALE!!

  1. Ta linia kodu HTML pochodzą z pliku header.php w moim WordPress.
  2. Pobieram ten plik z mojego hostera na mój lokalny dysk twardy.
  3. Pierwsza linia header.php jest <!DOCTYPE html><!-- HTML 5 -->
  4. Kiedy otwieram header.php w RJ TextEd (tak zaawansowany edytor tekstu), to znaczy: kodowanie prądu header.php jest UFT-8 bez (!) BOM.
  5. Po otwarciu pliku header.php w przeglądarce HEX widzę, że bajt 0 i 1 to 3c, 21 - czyli dokładnie <!.

A więc, pod każdym względem, dlaczego & skąd otrzymuję te "dziwne symbole"?

+0

Do czasu czytania punktów 4 i 5, myślałem, że odpowiedź była dość prosta. To jest interesujące. –

Odpowiedz

17

Znalazłem przyczynę problemu. Ogólna zasada to:

If any(absolutely any!) file that take part in construction of the code of final HTML-page(the one to be sended to client) has encoding with BOM - final HTML-page WILL BE UTF-8-BOM. That is: you whole site should NOT contain even 1 file with BOM.

W moim przypadku mam łącznie pliki 1.3K, które tworzą moją stronę. Tylko 4 plików został BOMed:

  • wp-config.php (w katalogu głównym miejscu)
  • jquery.query.js (w to folder)
  • Cyr-do-lat.php (w plug w folderze)
  • footer.php (w katalogu głównego tematu)

i został zmuszony do ponownego zapisać każdy i wszystkie z tych 4 plików jako „UFT-8 bez BOM”, aby pozbyć się „Non -Sprawdź poprawność znaków obszaru. Kiedy to zrobiłem (ponownie zapisuję pliki) - błąd zniknął.

+1

Dziękuję, ten błąd doprowadzał mnie do szału! –

+0

Dziękuję. Poza błędem sprawdzania poprawności otrzymywałem ogromną pustą przestrzeń tuż nad moim menu nawigacyjnym witryny WordPress, co naprawdę zmusiło mnie do walki przez kilka dni, próbując określić, co było przyczyną pustego miejsca ... Potem zmieniłem kodowanie w Smultron.app na Maca i usunąłem opcję BOM UTF-8, ponownie przesłałem pliki mojego motywu i zostało to rozwiązane !! –

Powiązane problemy