ContentType+encoding webserver negeren?

[-=bas=-]

Ik wil op een webpagina wat Japanse tekst tonen.
Mbv een meta tag probeer ik de encoding op shift_jis te zetten maar dit wordt genegeerd door zowel IE als Firefox.
Als ik met Firebug kijk dan lijkt het erop dat de webserver (standaard bij m'n internetabbo) al een ContentType string mee stuurt en daarin de encoding op een of andere ISO formaat zet.

Is het mogelijk om de ContentType string die de server standaard verstuurd te laten negeren en de meta tag in de file te laten gebruiken door de browser?

[BtM909]

Volgens mij wordt die meta tag genegeerd, vanwege (let op volledig uit m'n blote koppie, dus kan er naast zitten ) het feit dat de browser vanaf het begin al de characters moet begrijpen om uberhaupt totaan de meta tag te komen

Kan je het niet met een server-side language setten? Bijv. met PHP?

[mithras]

Er wordt ook al met het document een Content-Type header gestuurd. Deze header gaat altijd voor op de <meta> tag in je html document. Je zal een .htaccess moeten plaatsen (in het geval van Apache) om de header goed te sturen.

Misschien dat je, als je php gebruikt, ook in php de header kan sturen, maar het meest veilige is in principe via een .htaccess het te regelen. Nog even opgezocht, ik stel mijn sites altijd in utf8 op. Dan staat (oa) dit in de .htaccess:

AddDefaultCharset utf8

[ Voor 14% gewijzigd door mithras op 13-01-2009 10:36 ]

[-=bas=-]

Thanks voor de antwoorden.
Ik zal m'n ISP eens vragen of het mogelijk is om een eigen .htaccess in op m'n webruimte neer te zetten.

[Verwijderd]

-=bas=- schreef op dinsdag 13 januari 2009 @ 11:19:
Thanks voor de antwoorden.
Ik zal m'n ISP eens vragen of het mogelijk is om een eigen .htaccess in op m'n webruimte neer te zetten.

Kan eventueel ook gewoon door in PHP

PHP:

header ( "Content-Type: text/html; charset=shift_jis");

als eerste header te zetten

[_Thanatos_]

Misschien handiger om utf-8 te gebruiken. Ik kan me voorstellen dat menig HTML editor zich verslikt in shift_jis, omdat het gewoon ANSI is. Dat betekent dat als je editor het als iso-8859-15 (latin-9, west-europees) interpreteert, dat het abacadabra wordt

Bij utf-8 kan er geen misverstand ontstaan welke tekens er bedoeld worden, omdat het in feite unicode is (dat encoded wordt naar ANSI). Nadeel: bij alléén japanse tekens wordt het een beetje veel data. Maar je hebt ook nog je html-tags. En je editor moet het ondersteunen (al is de support voor utf-8 breder dan voor andere "vreemde" charsets, heb ik het idee).

Just my 2 cents. Doe ermee wat je wil

[ Voor 3% gewijzigd door _Thanatos_ op 19-01-2009 15:27 ]

[.oisyn]

_Thanatos_: volgens mij verwar je ANSI met ASCII, waarbij de eerste een organisatie is en de tweede een tekenset dat door de eerste beheerd wordt . Echter, Windows spreekt vaak over "ANSI", waarmee de Windows ANSI codepages bedoelt worden (de meest gangbare is CP1252, compatible met latin-1), maar die zijn nooit door ANSI gestandaardiseerd.

Bovendien is ASCII maar 7 bits (128 tekens), alles daarboven valt niet onder het standaard ASCII tekenset. Het is wel zo dat UTF-8 en Shift JIS (enigszins, met uitzondering van 2 tekens) backwards compatible zijn met ASCII. Dat wil zeggen, als je standaard ASCII interpreteert als UTF-8 of Shift JIS dan gaat er niets mis, en andersom als een UTF-8 of Shift JIS tekst uit alleen maar de standaard ASCII tekens bestaan dan is dat gewoon een ASCII bestand.

Maar bottom line is dat er aan een file op disk vrij weinig te zien is in wat voor charset hij is opgeslagen. Applicaties als Windows Notepad zetten er een BOM in voor unicode files (UTF-8 en UTF-16), maar voor UTF-8 is dat in feite onzinnig (er zijn geen ambiguïteiten in de byte order in UTF-8) en niet standaard, waardoor zo'n BOM weer problemen kan geven in andere applicaties. Maar zelfs bij normale gaat dat af en toe fout. Open maar eens een notepad, en typ daarin de tekst "Bush hid the facts". Sla het op, en open het bestand dan opnieuw. Feest

[ Voor 13% gewijzigd door .oisyn op 19-01-2009 16:41 ]