Roger Persson skrev:

1. På de sidor som inte stödjer Unicode ännu, eller rent generellt, kan man inte göra så att man får specificera vilken kodning man postar i?

Teoretiskt sett skulle detta kanske kunna fungera, men vi kommer inte att göra så, eftersom vi vill begränsa oss till så få standards som möjligt. Så snabbt vi kan, ska vi gå över till Unicode över hela linjen. (Någon erfaren JavaScript-programmerare får gärna hjälpa till att felsöka de "röda bokstäverna", som jag inte får att fungera i MSIE.)

Just nu tjatar folk på mig att fortsätta med inscanningen av den danska uppslagsboken Salmonsens konversationsleksikon, men jag vill ha ordning på Unicode-rutinerna först så att alla specialtecken kan komma med från och med nästa band.

Under tiden går det bra för vem von helst att prova lite OCR. Idag finns ännu fler nyinscannade böcker att OCR-tolka än igår. Dessa har tillkommit (se "Recently published works"):

* "Tomtegubben eller Stockholms barnkalender", 1866 * "Nornan. Svensk kalender", 1891 * "Hjeltekonungen. Historisk roman från 30-åriga kriget", 1906 * "Upphemtad Dukagång", 1893 * "Natur och arbetsliv i svenska bygder", 1908-1910

Följande två är i fraktur:

* "Een kort beskriffning vppå trenne resor och peregrinationer", 1667 * "Hågkomster från Hembygden och Skolan", 1830

2005-03-16 kl. 11.25 skrev Roger Persson:

De "röda bokstäverna" eller "teckenpaletten" kommer nog fungera dåligt i vissa Webbläsare. För någon generell metod att bestämma textmarkörens position i JavaScript där tecknen ska infogas, verkar inte finnas, annat än till en begränsad andel webbläsare.

Till den glädje det för någon måhända hava kan:

Som jag tidigare rapporterat lyckas jag — med lite tjyvknep — placera ett och annat "rött tecken" i korret. Jag kan också få in det i e-brev (jag använder MAIL) på cirklistan, men vid distributionen, som jag ju närfapå på direkten själv får, så har mitt fina "röda tecken" omvandlats till "surrogat-tecken". Det tolkar jag som att det inte är min dator eller mitt program det hänger på — det såg ju bra ut när jag skickade det. Utan det är någonstans i postmästarens process som Unicode filtreras bort. Därför har troligen ingen av cirkmottagarna sett mitt fina "röda tecken", utan något annat — eller i värsta fall ett tomrum eller inte ens det. Förlåt i så fall, hoppas budskapet kunde tolkas ändå.

Jag noterar denna postegenskap utan yrkande och kommer t v att avhålla mig från "röda bokstäver" vid fortsatt korrespondens.

Ibland har jag behövt något tecken utöver "de röda", och då har jag prövad korr-sidans länk 'more…' och hamnar då på en Wiki Unicode-sida (English version). Där har jag använt kopiera-klistra-metoden, vilket lyckats för vissa tecken, men inte för andra. Begränsningen tycks ligga i vad jag händelsevis har någon stans var som helst bland det flertal fonter som råkar finnas i min dator. De mest märkliga källor spåras, även icke-latinska alfabet med "begränsad latinsk utökning". Men vissa spårar ändå ur i änden.

Jag är nu osäker huruvida ett korr med ett sådan "halvrött tecken", som både ser snuggt ut på min korrsida, och ser lika bra när jag kollar det färdiga revideret med direktinhämtning från Runeberg (obs, med tömt cache-minne, som annars kan luras med gammal skåpmat); kommer det att fastna på önskat sätt hos Runeberg och komma riktigt med vid HTML-läggningen?

Om någon vill kolla, kan jag på begäran leta reda på någon färdig-korrad Geodet-sida med relevant exempel.

En möjlighet kunde ju vara att man har ett eget fönster som teckenpalett. D.v.s. en kopiera-klistra in buffer (typ "cut and paste if needed.")

Jag har redan tidigare gjort något liknande, d v s på en separat TEMP-sida på skrivbordet mellanlagra några aktuella, men svårgripbara tecken f v b runebergs-korret. Hittills har jag gjort om detta från gång till gång, men det är ju inte särskilt praktiskt. Jag har funderat på att göra det lite mer permanent som special-palett, men ännu inte jobbat närmare på det. Rationell hantering av detta problem underlättar korrekturläsandet åtskillgt, och innebär framförallt snabbare resultat.

Det finns kanske anledning att i sinom tid återkomma till frågan om bästa metod.

B L Wahlman bo.lennart.wahlman@wah.se

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

Hej,

On Sat, 19 Mar 2005 14:09:59 +0100, Roger Persson rogper@bredband.net wrote:

[...]

Jag tittade igenom min dokumentation till BSD Unix (Mac OS X) och såg att stödet för att kontrollera textkodningar är väldigt dåligt. Så jag gjorde ett litet "DOS-program" som konverterar textfiler till önskad textkodning. En körning ser t.ex. ut så här

naturoch/gotland> reencode -encode:macintosh:iso-8859-1 ocr/ 0001.txt ändrad från macintosh till iso-8859-1 0002.txt ändrad från macintosh till iso-8859-1 ... 314 filer ändrade. naturoch/gotland>

Hursomhelst, just nu funkar det bara till Mac OS och knappt utanför min dator eftersom det var ett snabbhack. Men jag kollade mig runt lite och det finns nog möjlighet att göra detta enkla verktyg oberoende av OS, om det skulle behövas.

Det finns redan ett program som kan konvertera mellan en uppsjö av olika textkodningar: http://directory.fsf.org/recode.html

Finns i de flesta Linux-distar och borde utan problem gå att kompilera på MacOS X.