Danske tegn i variabels værdi virker ikke

Den eksterne fil skal have samme tegnsæt som resten af siden (dvs. selve teksten skal have det tegnsæt, ikke at du skal kalde header() fra den anden fil).

http://php.net/iconv

Har prøvet at kigge lidt på den funktion, men kan ikke rigtig se mig ud af hvad jeg skal benytte for at erklærer char typen i min eksterne PHP fil?

Er det rigtigt forstået at det er en "komponent" der skal installeres på serveren?

Den skulle gerne bare være der. Dermed kan du konvertere fra, hvad der kunne være iso-8859-1 i din eksterne fil, til utf-8, som du bruger på siden.

OK, hvordan skal jeg så gøre dette?

Min eksterne fil ser således ud:

<?php

£errorMsg1 = "Teks med øæå";

?>

Du bruger vel bare eksemplet på http://de2.php.net/manual/da/function.iconv.php

Øh, siger du include til den eksterne fil?

...for i så tilfælde skal du bare gemme dine eksterne filer med UTF-8. Hvis man rimeligvis kan, skal man bare bruge det samme tegnsæt i hele sit system.

OK! Jeg laver en require på min eksterne php fil inden der sker noget som helst andet i min hovedfil.

Har prøvet at indsætte
iconv_set_encoding("output_encoding", "ISO-8859-1");

i min eksterne fil, men det hjælper ikke!

Nej, det hjælper ingenting på forskellige tegnsæt i forskellige include-filer. Prøv bare 05/10-2007 15:48:13

Jeg forstod det som at du hentede en tekst et andet sted fra, hvor teksten var i "forkert" tegnsæt og denne tekst skulle konverteres, fordi du ikke kunne få den på anden måde.

OK, fik det til at virke med:

iconv("ISO-8859-1", "UTF-8", "Du har ikke gennemført step 1");

Men er der ikke en anden måde hvorpå man definere at alt tekst i den eksterne php fil skal tolkes som UTF-8?

Jo, 05/10-2007 15:48:13

Ja, men hvordan skal jeg helt konkret skrive koden?

Du skal ikke skrive den anderledes, du skal bare gemme filen som UTF-8

Er stadig ikke med! Hvad mener du med at jeg skal gemme den som UTF-8? Jeg har jo ikke andet i den end:

<?php

£errorMsg1 = "Teks med øæå";

?>

Den editor, i hvilken du skriver i filen, skal gemme filen som UTF-8.

Jeg bruger Dreamweaver, og jeg kan umiddelbart ikke finde nogle steder hvor man kan gemme filen som UTF-8

Jeg kender ingenting til dreamweaver. Men selv sølle Notepad i Windows ka' ;)

Tip: Kig dig omkring efter ordene "character set" eller "encoding". Det er muligt det gemmer under nogle preferences eller properties.

(Nej, jeg ved heller ikke hvor det måtte befinde sig - holder mig til Vim)

<ole>

Desværre synes DW for lam til at beskæftige sig med slige 'detaljer'!

Jeg har en DW installeret (omend jeg aldrig bruger den) og har lige fulgt anvisningerne og sat den op til at spytte utf-8 dokumenter ud. Den skriver ganske rigtigt også utf-8 som charset i Content-Type meta'en i nye dokumenter - men når jeg efterfølgende åbner et såkaldt 'utf-8' dokument i Notepad og vil gemme det påny, viser det sig at være et ANSI (iso-8859-1) dokument  :o|

skwizie >> Åben dine dokumenter i Notepad og gem dem så igen som utf-8  :)

/mvh
</bole>

Det kan jeg så ikke tilråde. Notepad tilføjer en UTF-8 BOM, som PHP ikke kender til - så den bliver skrevet ud i forbindelse med en include, hvilket kan forstyrre eks. header()-kald.

Gør du det, er du faktisk nødt til at fjerne det manuelt med en editor der IKKE kan Unicode. Af den grund vil jeg foreslå du finder en lille teksteditor der ikke placerer den - Notepad++ skulle udelade det, men jeg har ikke afprøvet den: http://notepad-plus.sourceforge.net/uk/site.htm

Ja, det er forresten korrekt. Af uransagelige årsager, har man valgt at se stort på denne bug, der vist blev introduceret i PHP 5.0.5 - og først bliver rettet i version 6.0  :(

Om det er et udslag af, at PHP er skrevet i et lille, semiafsondret skandinavisk land, ved jeg ikke, men den arrogante ignoreren af dette problem synes yderst uhensigtsmæssig. Utf-8 hører uløseligt sammen med en globaliseret verden, Web 2.0, XML, AJAX, m.m. - og BOM-informationerne er en kæmpe fordel at have i filerne.

- tjaahhh ...  :o|

- en mulighed er at downgrade til PHP 5.0.3 og så vente med at upgrade til version 6.0 engang kommer ... omend det er ynkeligt, man skal gribe til den slags for at løse så enkelt problem

BOM er ikke reelt en del af UTF-8 standarden, og det eneste det fortæller er at det er en UTF-8 fil - noget som jeg vil mene at Unicode-kompatible programmer altid bør gå ud fra indtil de finder ud af andet, da det tillader ikke-Unicode-programmer at behandle dataene så normalt som muligt - en UTF-8 fil uden nogen form for specialtegn vil være 100% identisk med en ANSI udgave af samme når BOM ikke er til stede.

Man kan så godt argumentere for at det er spild af resourcer potentielt at skulle afkode filen to gange, men det giver til gengæld den gevinst at man ikke genererer gamle programmer ved et uheld.

Ja, jeg bruger ikke selv Notepad uden at være tvunget til det, men den sætter jo de tre berømte tegn foran. Dem kunne man så måske fjerne med DW ... Nej, konklusionen er vel at produkter, hvis navne indeholder "W" ikke dur. Dreamweaver, Windows, Whiskey, ... ok, det er nok ikke en perfekt regel alligevel. Men http://editplus.com/ har ikke de tre tegn foran, når man gemmer som UTF-8 

Z:\>more <z.txt
´&#9559;&#9488;heja&#9500;©&#9500;Ñ

Z:\>more <zz.txt
hjea&#9500;ª&#9500;©&#9500;Ñ

z er fra notepad/vista, zz er fra editplus/vista

ekspertens tegn-konverteringer kunne måske også bruges som sjovt indslag ;)

pidgeot >> Jeg er helt klar over, BOM ikke er del af Unicode, men det er nu engang ikke hensigtsmæssigt, at man ikke længere kan bruge 80% af de tilgængelige (web)editors til PHP, hvis man vil skrive tidsvarende kode.

erikjacobsen -> læg et svar

Jeg samler slet ikke på point, tak.

Lukker så :)