Roger:
Rent generellt, kan man inte göra så att man får specificera vilken kodning man postar i? Om FORM-taggen specificerar ENCTYPE-attributet,
<form name="proof" method=post action="proof.pl" enctype="application/utf-8"> kommer inte min webbläsare att posta i UTF-8? (Eller har jag fel?)
Ja, jag tror att du har fel i detaljerna men rätt i principerna. (Principen tolkar jag som att "Runeberg kan och bör hantera att ta emot text i många olika teckenkodningar. Så länge servern kan konvertera dem till Unicode så funkar det att lagra dem entydigt. Vi bör också hantera att skicka data i så många kodningar som möjligt - ju fler kodningar vi stöder, ju fler kan läsa våra texter.")
De tekniska detaljerna, så vitt jag förstår dem, skiljer sig lite från vad du skrev: När servern skickar ut formuläret så kan den ange i attributet accept-charset vilka sätt den hanterar att man kodar text. Datat skickas tillbaks från webbläsaren till servern med en av två metoder, get eller post. Get kan vi bortse från i det här fallet. När datat skickas med post-metoden så kodas det i ett meddelande enligt formatet multipart/form-data (det finns inget som heter application/utf-8).
I ett Multipart/form-data-meddelande så kommer varje del från en inmatningskontroll (som rutan där man skriver korr-text) på formuläret. För varje del anges dess mime-datatyp. För rutan med korr-text så är mime-typen text/plain. Text/plain tillåter en paramter charset som anger hur texten är kodad. Webb-läsaren skall välja någon av de kodningar som räknas upp i attributet accept-charset.
Exempel på sådana text-kodningar är utf-8, utf-16, ascii, iso 8859/1, och windows-1252, men det finns en uppsjö flera och det går att uppfinna nya kodningar. Antalet teroetiskt möjliga kodningar är oändligt. Gemensamt för dem är att de anger hur man översätter text-datats sekvens av bytes till en sekvens av unicode-tecken.
Om proof.pl-scriptet kan hantera olika encodings spelar det väl ingen roll vilken encoding man arbetar i?
Så länge proof.pl kan tolka just den encoding som jag jobbar med, så spelar det ingen roll. Om jag hittar på en egen encoding, låt oss kalla den utf-Christer, publicera en specifikation för den och får utf-Christer registrerat som en charset hos IANA, så är den en officiell encoding. Men fram tills dess att någon programmerar om proof.pl till att hantera utf-Christer så funkar det inte att skicka data i det formatet.
När det arbetet väl programmeringen för att hantera utf-Christer är gjord, så kan form-taggen ta med utf-Christer i accept-charset och då vet webb-läsare med stöd för den kodningen att de kan returnera datat i detta format.
Mycket om hur form-elementet fungerar står på sidan http://www.w3.org/TR/html401/interact/forms.html men för att ha alla detaljer så måste man läsa dokument som html-specifikationen hänvisar till (och i många fall till de dokument som ersatt dokumenten som html-specifikationen hänvisar till).
Christer Romson