utf-8 8859-1 osv osv

jeg går udfra at escapeAddr() er en af de mange functioner der ligger i toppen du bare ikke har vist.
os "gamle" kender efterhånden OLeBole's Function mail_utf8(), (http://www.eksperten.dk/spm/961816 #3) men håber stadig han skriver en guide vi kan henvise til :)

>Nogle sider ser således ud:
dvs det er ikke alle sider.

includerer de nogle andre php filer ??, er disse incodet som UTF8?? (det skal de være)

dine externe js filer er de UTF8 incodet ??
ellers skal der tilføjes et charset, eks
<script src="/js/functions.js" type="text/javascript" charset="ISO-8859-1"></script>
<script src="/js/validate.js" type="text/javascript" charset="UTF-8"></script>

dine CSS filer skal også være UTF8 incodet

hvis du anvender db skal dine data sendes i UTF8

Kort sagt UTF8 hele vejen rundt, så burde det virker

Der er forskel på utf-8 & utf-16.

<ole>

#2: Præcis - så derfor er der ingen i tråden, der besværer sig med utf-16 i denne forbindelse  =)

@greenie: For det første skal du nok vælge en realistisk DocType. Du bruger en XHTML 1.0 Strict DTD, men sender dokumentet som HTML. Den DocType, du postulerer i koden, kræver dokumentet bliver sendt med en speciel MIME-type, så det hænger ikke sammen.

Med mindre du bruger XML i dokumentet, har du ikke noget at bruge XHTML til - heller ikke i alm. webdokumenter. XHTML er uden sammenligning det mest misforståede, som nogensinde har ramt WWW. Alle undersøgelser, jeg har lavet og set, viser, at langt under 1% af samtlige dokumenter, som udgiver sig for XHTML, overholder standarden og kan parses af en XML-parser (som er den eneste årsag til at bruge XHTML)!  *o)

Hvad er dokumenterne gemt som (utf-8 eller ANSI)? Jeg spørger ikke om, hvad du tror, de er gemt som ... tjek det, please  =)

Hvis der er tale om indhold fra en database, hvilket tegnsæt er databasen så sat op til at bruge - og ikke mindst: Hvilke kollationer bruges?

Hvad er de dokumenter, som leverer data til en evt. DB gemt som?

Er der på et tidspunkt skiftet tegnsæt og/eller kollationer på tabeller i en evt. DB - og er du opmærksom på, at allerede eksisterende indhold ikke derved ændres?

/mvh
</bole>

Prøv og kom med hele koden.

#4: Det handler ikke om koden. Det er et spørgsmål om encoding af mailens indhold

#5 > Det handler nok også om decoding af mailens indhold.

Præcis! Men temmelig usandsynligt om koden  *o)

#7 > Er det usandsynligt at emailen skal dekoden eller hvad mener du ?

Jeg undkylder det 'Præcis', jeg skrev #7. Det skyldes, jeg læste forkert og misforstod, hvad du skrev. Nu, hvor jeg har læst, hvad du faktisk skrev, får jeg ingen mening ud af det.

Eftersom jeg var med til at lave ovenstående, kan jeg godt lige forklare, hvad der gik galt. Tidligere benyttede spørgeren ISO-8859 i meta'en, og filerne var ikke gemt i format UTF-8. Den enkelte fil (mailform.php) var til gengæld gemt i format UTF-8 (Uden BOM) med det formål at kunne harmonere med (oleboles) mailfunktion. De data, der sendes fra ISO-8859 filen skulle altså gennemtvinges en UTF-8 encoding - og det gjorde jeg med hhv. utf8_encode og decode. Indholdet blev altså renset om man så må sige, hvilket gik hen og fungerede ganske fint.

Spørgeren har efterfølgende ændret meta til UTF-8, men filerne var endnu ikke blevet gemt i format UTF-8. Derfor blev der skabt splid mellem tegnsætningen og de funktionerne, som nu er unødvendige. Problemet lå altså i indholdet (det data, der skulle behandles).