ARCHIV

Ahoj, potřeboval bych vytvořit dokument XML v php - kliknutím na xml.php aby se zobrazil xml dokument.

Mám tento kód:

<?php
header("Content-Type: text/xml");
echo "<?xml version=\"1.0\" encoding=\"UTF-8\" ?> \n";




echo ("<obce>\n");

echo ("\t<obec>\n");
echo ("\t\t<psc>\n");
echo ("\t\t\t PSC \n");
echo ("\t\t</psc>\n");
echo ("\t\t<nazev>\n");
echo ("\t\t\t OBEC \n");
echo ("\t\t</nazev>\n");
echo ("\t</obec>\n");

echo ("</obce>\n");




?>

Ale vypíše mi to:

Chyba parsování XML: Na začátku externí entity chybí procesní instrukce xml
Adresa: http://127.0.0.1/xml.php
Číslo řádku 3, sloupec 1:<?xml version="1.0" encoding="UTF-8" ?>
^

Nevíte, prosím, kde dělám chybu - chci takto jednoduše vypsal xml. Díky :-)

Kouknete se, co presne je vystupem toho skriptu. To chybove hlaseni vypada, jako ze pochazi od prohlizece, ktery ten vystup nepovazuje za platne XML. "Externi entita" je XMLstina pro "soubor ktery obsahuje nejaky kus XML dokumentu", v typickem pripade cely dokument.

Sice nepravdepodobne ale presto voditko by mohlo byt to cislo radku: 3. Co je na tech dvou radcich pred tim? (me chapani XML je takove, ze i pokud jsou prazdne, tak by to mohlo vadit)

Tak to mi tedy vysvetelete, jak s generovanim XML souvisi ty Cache-Control, a proc o tom vystupu prohlizeci tvrdite, ze je to priloha s nazvem koncicim na .xls. (a hlavne, jak se to s vyjimkou techto irelevantnich detailu od puvodniho kodu lisi)

Nuž, beriem späť že by generovanie malo byť nasledovné. Nie, nemusí a postačí ako je to v pôvodnom dotaze.

Cache-Control tam používam preto, lebo sa mi hlavne pri IE6 stalo, že pri opakovanom dotaze sa zobrazili predošlé dáta. Až po následnom refreshe alebo vymazaní dočasných súborov, boli aktuálne dáta. Neviem či je to správne, ale pri takomto použití som už žiadne také problémy nemal.

Súbor xls som použil len na ukážku. Dosť často generujem dáta do šablóny excelu, uloženej ako XML. Takto sa klientovi zobrazia dáta priamo v exceli a môže s nimi ihneď následne pracovať. Samozrejme, ak chce niekto iba čistý xml súbor, môže to vynechať.

Čo sa týka Vášho predošlého príspevku, asi máte pravdu s tým prázdnym riadkom na začiatku. Pokiaľ je na začiatku súboru pred '<?xml version="1.0" encoding="UTF-8"?>' akýkoľvek prázdny riadok, vráti to uvedenú chybu. Platí to aj vtedy ak je to php súbor a pred '<?php' je tiež prázdny riadok.

Jeste me napadla druha vec, ono je take mozne ze ten prohlizec ma v te chybove hlasce prohozene cislo sloupce a radku (coz si matne pamatuji, ze kdysi Gecko delalo) a neni to o tom ze tam je prazdny radek, ale o tom, ze tam nejaky uzasny editor jehoz autori zase jednou pochopili utf-8 vklada BOM.

S tým UTF neviem. Vyskúšal som urobiť napríklad rovnaký súbor v UTF-8 formáte aj vo WINDOWS-1250. Použil som Dreamweaver, PSPad aj UltraEdit. A výsledok s chybou rovnaký.

No ja to myslel tak, ze i pokud tam ten prazdny radek neni, tak nektere uzasne editory (treba notepad z ledasktere verze windows) maji tendenci vkladat na zacatek utf-8 souboru sekvenci 0xef 0xbb 0xbf, ktera by mohla vadit.

A pohled do specifikace rika, ze wellformed XML 1.1 musi zacinat sekvenci '<?xml version="1.1"' (dusledek produkci 1, 22, 23 a 24), v pripade XML 1.0 neni XML deklarace povinna, ale pokud je uvedena tak stejne musi byt ihned na zacatku souboru, jinak soubor zacina volitelnym prazdnym mistem (ovsem pouze ascii, tj. U+0009, U+000a, U+000d nebo U+0020) za nimz nasleduje '<', ktere uvozuje komentar, procesni instrukci ci korenovy element (1, 22, 23, 24, 27 + definice zminenych prvku, ktera neni tak zajimava).

Dusledek tedy je, ze prazdne radky vadi pouze tehdy, jsou-li nasledovany XML deklaraci. Zato 0xef 0xbb 0xbf coz je utf-8 pro U+FEFF vadi vzdy, protoze ten znak sice je vicemene mezera, nicmene nikoli z pohledu XML, kde je povazovan za textova data, ktera se pochopitelne mimo element vyskytovat nesmi.

Jeste je mozna potreba zduraznit, ze pokud U+FEFF na zacatku je, tak pokud to zobrazite jako text, pravdepodobne tam stejne nic neuvidite, maximalne se na zacatku prvniho radku bude kurzor chovat "zvlastne", ale pravdepodobne ani to ne. Je potreba se do souboru podivat necim, co unicode nerozumi (idealne treba hexdump -C soubor.php | head).