Kan någon antingen peka på dokumentation eller förklara ett par saker för mej? Jag vet så pass mycket om UTF-8 att Wikipediaartikeln inte säger mej så mycket.
1. Hur är migrering till UTF-8 tänkt att gå till, för en sån som mej som kört latin-1 sen jag köpte min första dator (Amiga 500) kring 1990?
Jag har sett Debian försöka installera sej i UTF-8, men inte låtit den göra det. Tydligen ska den erbjuda sig att leta igenom filsystemen efter textfiler i andra kodningar och konvertera dom, och om nåt sånt krävs blir jag mycket tveksam, för min dator är inte en isolerad ö -- den byter ständigt otypat data med en omgivning som kör Latin-1 och antagligen alltid kommer att göra det.
2. Vad påverkas av att ha UTF-8 som del av $LC_CTYPE, egentligen? read(2) och write(2) kommer ju att fortsätta hantera oktetter. Är det <wctype.h> från C99 som denna localen jobbar mot, eller vad?
Eller mer generellt, hur programmerar man i POSIX och C för att hantera in- och utdata i UTF-8 utan att samtidigt fucka upp hanteringen av 8859-1?
3. Skrev inte nån av legenderna från tidig Unix (Kernighan? Pike? Henry Spencer?) en artikel om hur UTF-8 är inkompatibel med Unix designregel "allt är en textfil"? Jag kan svära på att jag läst den, men hittar den inte nu. Och det kan knappast vara nån ur Plan 9-gänget eftersom UTF-8 var deras idé.
Jag frågar här eftersom jag lever i Unixvärlden, och för att jag misstänker att Unix hanterar detta på ett enhetligt sätt, medan Micrsoft kör vidare med sina sextonbitarstecken eller vad dom nu hittat på.
Och om jag verkar negativ så är det för att jag är negativ ;-) Inte mot UTF-8 som en kodning för transport av data på exv Usenet, utan när det kommer in otypat i min traditionella 8859-1-värld.
> Kan någon antingen peka på dokumentation eller förklara ett par saker > för mej? Jag vet så pass mycket om UTF-8 att Wikipediaartikeln inte > säger mej så mycket.
> 1. Hur är migrering till UTF-8 tänkt att gå till, för en sån som mej > som kört latin-1 sen jag köpte min första dator (Amiga 500) kring > 1990?
> Jag har sett Debian försöka installera sej i UTF-8, men inte låtit > den göra det. Tydligen ska den erbjuda sig att leta igenom > filsystemen efter textfiler i andra kodningar och konvertera dom, > och om nåt sånt krävs blir jag mycket tveksam, för min dator är > inte en isolerad ö -- den byter ständigt otypat data med en > omgivning som kör Latin-1 och antagligen alltid kommer att göra > det.
Förstår inte riktigt vart du vill komma här. Konvertering mellan teckenkodning kräver naturligtvis alltid konvertering mellan teckentabeller. Det finns visserligen många finurliga sätt man med varierande grad av säkerhet kan läsa igenom en textfil och avgöra vad det är för teckentabell texten är kodad med, men det finns alltid en inbyggd osäkerhet i sådana verktyg och det är ju alltid det som ska använda texten som måste tolka detta rätt...
Alltså, även om det finns verktyg för att konvertera alla dina befintliga textfiler så måste du ha någon rutin för att hantera situationerna att ta emot och skicka filer och konvertera rätt. I de flesta praktiska sammanhang (t ex mail, news etc) anges teckenkodningen i överföringen och det är sedan upp till dig hur du vill spara filerna, om du vill konvertera till någon annan teckenkodning eller inte.
> 2. Vad påverkas av att ha UTF-8 som del av $LC_CTYPE, egentligen? > read(2) och write(2) kommer ju att fortsätta hantera oktetter.
Nu har du hoppat ner långt under nivån där programmen ska känna till vad teckenkodning är. Systemfunktioner som read() och write() ska i alla sammanhang enbart betraktas som binära funktioner och inget annat. T ex har du en variabel som innehåller en textsträng kodad med Latin-1 kommer write() att skriva texten med Latin-1 i filen och är texten kodad med UTF-8 kommer write() att skriva texten med UTF-8 till filen. Konverteringen mellan teckentabeller görs en nivå ovanför, minst.
> Är det <wctype.h> från C99 som denna localen jobbar mot, eller vad?
> Eller mer generellt, hur programmerar man i POSIX och C för att hantera > in- och utdata i UTF-8 utan att samtidigt fucka upp hanteringen av > 8859-1?
Det gör du alltså inte, helt enkelt. På den nivån (undantaget saker som filnamn och liknande) finns inte begreppet teckentabell/teckenkodning. Det där måste du lösa ovanför anropen till systemfunktioerna. Se till att få texten kodad i den teckentabell du vill ha i den strängvariabeln du ska spara till filen. Nu är jag väldigt dålig på just Linux men jag antar att det finns snygga lättanvända funktioner för konvertering mellan teckentabeller där också som i de flesta andra operativsystem.
> 3. Skrev inte nån av legenderna från tidig Unix (Kernighan? Pike? > Henry Spencer?) en artikel om hur UTF-8 är inkompatibel med Unix > designregel "allt är en textfil"? Jag kan svära på att jag läst den, > men hittar den inte nu. Och det kan knappast vara nån ur > Plan 9-gänget eftersom UTF-8 var deras idé.
Det är möjligt, men vad skulle argumentationen gå ut på i så fall? Hantering av filer som inte innehåller ren ASCII-text är ju inte direkt nytt i Unix-världen heller... Kan det ha varit det principiellt knepiga med att tillåta teckenkodningar där inte alla tecken representeras av lika många bitar?
> Jag frågar här eftersom jag lever i Unixvärlden, och för att jag > misstänker att Unix hanterar detta på ett enhetligt sätt, medan > Micrsoft kör vidare med sina sextonbitarstecken eller vad dom nu > hittat på.
Nu skulle jag kunna korsa till s.d.datorkring och börja tjafsa men jag låter bli det... ;-)
Det där med 16-bitarstecken är ju knappast mindre enhetligt än något annat, snarare tvärtom, dessutom är det inget som Microsoft har hittat på. Det är ju 16-bitarstecknen som är riktig Unicode-standard. UTF-7 och UTF-8 är visserligen också standard men egentligen bara uppfinningar för att undvika onödigt slöseri med utrymme och det är väl egentligen enbart utrymmet och inget annat alls som skulle kunna vara argument mot att använda 16-bitars Unicode i alla sammanhang.
Fördelen Microsoft har med att ha designat operativsystemskärnan så att den enbart pratar 16-bitars Unicode är ju att man slipper teckentabellsbekymmer på den nivån även i sammanhang där kärnan måste tolka textsträngar som just text och inte bara ren binär data, t ex i filnamn och liknande. Det är också bra mycket enklare (och mer enhetligt skulle jag vilja säga) programmeringsmässigt när man vet med 100% säkerhet att alla tecken är 16 bitar och aldrig kan vara något annat, oavsett om det är bokstaven 'a' eller något kinesiskt tecken.
Det är två olika vägar som har valts och man kan nog knappast säga att Unix-världen har ett mer "enhetligt" sätt att hantera detta än Windows-världen. Spontant får jag nog säga att Windows-världens hantering är mer "enhetlig" i så fall, men det är naturligtvis en definitionsfråga och mycket tycke och smak och inget annat.
> Och om jag verkar negativ så är det för att jag är negativ ;-) Inte > mot UTF-8 som en kodning för transport av data på exv Usenet, utan > när det kommer in otypat i min traditionella 8859-1-värld.
Det kan man ju förstå. Teckenkodning inför en ny dimension av saker att ta hänsyn till, speciellt i programmeringssammanhang.
On Mon, 07 May 2007 12:09:19 GMT, Olof Lagerkvist <n...@email.address> wrote: > Jorgen Grahn wrote:
>> Hej,
>> Kan någon antingen peka på dokumentation eller förklara ett par saker >> för mej? Jag vet så pass mycket om UTF-8 att Wikipediaartikeln inte >> säger mej så mycket.
>> 1. Hur är migrering till UTF-8 tänkt att gå till, för en sån som mej >> som kört latin-1 sen jag köpte min första dator (Amiga 500) kring >> 1990?
>> Jag har sett Debian försöka installera sej i UTF-8, men inte låtit >> den göra det. Tydligen ska den erbjuda sig att leta igenom >> filsystemen efter textfiler i andra kodningar och konvertera dom, >> och om nåt sånt krävs blir jag mycket tveksam, för min dator är >> inte en isolerad ö -- den byter ständigt otypat data med en >> omgivning som kör Latin-1 och antagligen alltid kommer att göra >> det. > Förstår inte riktigt vart du vill komma här. Konvertering mellan > teckenkodning kräver naturligtvis alltid konvertering mellan > teckentabeller. ... > Alltså, även om det finns verktyg för att konvertera alla dina > befintliga textfiler så måste du ha någon rutin för att hantera > situationerna att ta emot och skicka filer och konvertera rätt. I de > flesta praktiska sammanhang (t ex mail, news etc) anges teckenkodningen > i överföringen och det är sedan upp till dig hur du vill spara filerna, > om du vill konvertera till någon annan teckenkodning eller inte.
Nja, "de flesta praktiska sammanhang" är för mej och antagligen de flesta att data som jag sparar otypat (dvs inte låter ligga kvar i ett MIME-mail utan sparar till textfil) kommer otypat. FTP, scp, rsync, HTTP från nåt ställe som inte vet var det är för encoding på filen, textfil i en tarboll ...
I dag är dessa filer (ovetenskaplig känsla) antingen ASCII eller iso-8859-1. Debians release notes är i UTF-8 för att kunna stava alla utvecklares namn rätt.
Så jag kanske egentligen frågar: "hur överlever man som early adopter av UTF-8 i en värld som pratar Latin-1?".
>> 2. Vad påverkas av att ha UTF-8 som del av $LC_CTYPE, egentligen? >> read(2) och write(2) kommer ju att fortsätta hantera oktetter.
> Nu har du hoppat ner långt under nivån där programmen ska känna till vad > teckenkodning är.
Och samtidigt konstaterat att de nivåerna inte känner till vad teckenkodning är. Det var bara bakgrundsmaterial.
Så jag undrar fortfarande var UTF-8 som del av $LC_CTYPE slår. Jag inser att det gör isalpha(int c) & co odefinierade eftersom de antar att c är unsigned char eller EOF, men sen då?
> Konverteringen mellan teckentabeller görs en nivå ovanför, minst.
>> Är det <wctype.h> från C99 som denna localen jobbar mot, eller vad?
>> Eller mer generellt, hur programmerar man i POSIX och C för att hantera >> in- och utdata i UTF-8 utan att samtidigt fucka upp hanteringen av >> 8859-1?
> Det gör du alltså inte, helt enkelt. På den nivån (undantaget saker som > filnamn och liknande) finns inte begreppet teckentabell/teckenkodning. > Det där måste du lösa ovanför anropen till systemfunktioerna. Se till > att få texten kodad i den teckentabell du vill ha i den strängvariabeln > du ska spara till filen. Nu är jag väldigt dålig på just Linux men jag > antar att det finns snygga lättanvända funktioner för konvertering > mellan teckentabeller där också som i de flesta andra operativsystem. >> 3. Skrev inte nån av legenderna från tidig Unix (Kernighan? Pike? >> Henry Spencer?) en artikel om hur UTF-8 är inkompatibel med Unix >> designregel "allt är en textfil"? Jag kan svära på att jag läst den, >> men hittar den inte nu. Och det kan knappast vara nån ur >> Plan 9-gänget eftersom UTF-8 var deras idé.
> Det är möjligt, men vad skulle argumentationen gå ut på i så fall? > Hantering av filer som inte innehåller ren ASCII-text är ju inte direkt > nytt i Unix-världen heller... Kan det ha varit det principiellt knepiga > med att tillåta teckenkodningar där inte alla tecken representeras av > lika många bitar?
Nåt sånt -- jag minns inte detaljerna. Jag kanske minns helt fel, för den delen.
>> Jag frågar här eftersom jag lever i Unixvärlden, och för att jag >> misstänker att Unix hanterar detta på ett enhetligt sätt, medan >> Micrsoft kör vidare med sina sextonbitarstecken eller vad dom nu >> hittat på.
> Nu skulle jag kunna korsa till s.d.datorkring och börja tjafsa men jag > låter bli det... ;-)
> Det där med 16-bitarstecken är ju knappast mindre enhetligt än något > annat, snarare tvärtom, dessutom är det inget som Microsoft har hittat > på.
Du behöver inte bli frestad att tjafsa, för jag angrep inte MS -- jag bara konstaterade att jag tror Windows hanterar detta annorlunda, och att det är Unixvärlden jag är intresserad av.
> Det är ju 16-bitarstecknen som är riktig Unicode-standard. UTF-7 och > UTF-8 är visserligen också standard men egentligen bara uppfinningar för > att undvika onödigt slöseri med utrymme och det är väl egentligen enbart > utrymmet och inget annat alls som skulle kunna vara argument mot att > använda 16-bitars Unicode i alla sammanhang.
Det är väl också så att UTF-8 kan uttrycka 32-bitarstecken? Jag vill helst inte rota i detta, men har märkt att somliga har mycket negativ attityd till 16-bitars-kodningar.
...
>> Och om jag verkar negativ så är det för att jag är negativ ;-) Inte >> mot UTF-8 som en kodning för transport av data på exv Usenet, utan >> när det kommer in otypat i min traditionella 8859-1-värld.
> Det kan man ju förstå. Teckenkodning inför en ny dimension av saker att > ta hänsyn till, speciellt i programmeringssammanhang.
En hel del att ta hänsyn till som normalanvändare också, känns det som (I alla fall i Unix, där gränsen programmerare--användare är avsiktligt suddig.)
On Mon, 7 May 2007 14:34:51 +0000 (UTC), Charlie R <spam_spam_s...@chroot.yi.org> wrote: > 6 May 2007 06:50:53 GMT, Jorgen Grahn ba:
>> 1. Hur är migrering till UTF-8 tänkt att gå till, för en sån som mej >> som kört latin-1 sen jag köpte min första dator (Amiga 500) kring >> 1990?
> Vad är anledningen med en sådan operation? Behöver du få > tillgång till fler tecken än de som finns i Latin-1?
Tja, några av dom hade varit trevliga att ha, det får jag erkänna ...
> Om inte, är det inte mer praktiskt att behålla Latin-1 > som intern representation och konvertera till/från UTF-8 > vid export/import av textfiler?
Jo, och det är den strategin jag valt också. Men jag frågar eftersom olika Linuxdistributioner (senast Debian Etch) gått över till UTF-8 som default locale. De borde knappast gjort det för att göra livet surt för folk?
> Men jag frågar eftersom > olika Linuxdistributioner (senast Debian Etch) gått över till UTF-8 > som default locale. De borde knappast gjort det för att göra livet > surt för folk?
Inte surt kanske, men mer komplicerat och därmed intressantare:
"Warum sollte man etwas einfach machen, wenn man es so wunderbar kompliziert machen kann"?
On 2007-05-07, Charlie R <spam_spam_s...@chroot.yi.org> wrote:
> 6 May 2007 06:50:53 GMT, Jorgen Grahn ba:
>> 1. Hur är migrering till UTF-8 tänkt att gå till, för en sån som mej >> som kört latin-1 sen jag köpte min första dator (Amiga 500) kring >> 1990?
> Vad är anledningen med en sådan operation? Behöver du få > tillgång till fler tecken än de som finns i Latin-1?
Ett själ ... när man kör rsync från en osx data för att synca filer från en 8859-1 data så pajar rsync ur. Kollade på koden t.o.m och det såg olätt ut. Det var mitt själ att byta till UTF-8 på mina datorer.
On Mon, 21 May 2007 17:22:01 GMT, Claes Wikstrom wrote: > när man kör rsync från en osx data för att synca filer från en 8859-1 > data så pajar rsync ur.
Det finns en patch till rsync som lägger till stöd för iconv så att filnamn kan konverteras mellan olika teckenkodningar vid synkning:
On Mon, 21 May 2007 17:22:01 GMT, Claes Wikstrom <kla...@hyber.org> wrote:
...
>> Vad är anledningen [att migrera till UTF-8]? Behöver du få >> tillgång till fler tecken än de som finns i Latin-1?
> Ett själ ... när man kör rsync från en osx data för att synca filer > från en 8859-1 data så pajar rsync ur. Kollade på koden t.o.m och > det såg olätt ut. Det var mitt själ att byta > till UTF-8 på mina datorer.
Det kan vara ett skäl att byta, men man för ju samtidigt smittan vidare på så vis. Du har nu två burkar som "pajar ur" i stället för en. Innan UTF-8 kom in i bilden hade du ingen.[1]
Och om du har ett program som skapar filer utan att respektera localen -- eller om du eller någon annan byter till Latin-1 ett ögonblick -- så pajar det ur igen.
Jaja. Jag har i alla fall lärt mej att migreringen till UTF-8 kommer att bli ungefär så smärtsam som jag var rädd för. Man får hoppas att det är universellt nog för all framtid så det inte behöver upprepas.
/Jörgen
[1] Om du inte bytte udda namngivna filer med kineser, ryssar eller centraleuropeer. Men det hände säkert rätt sällan.
> 1. Hur är migrering till UTF-8 tänkt att gå till, för en sån som mej > som kört latin-1 sen jag köpte min första dator (Amiga 500) kring > 1990?
Så vitt jag vet finns det inte någon officiell plan för hur detta ska gå till.
> 2. Vad påverkas av att ha UTF-8 som del av $LC_CTYPE, egentligen? > read(2) och write(2) kommer ju att fortsätta hantera oktetter. > Är det <wctype.h> från C99 som denna localen jobbar mot, eller vad?
Just det, det är funktionerna i wchar.h som beter sig olika beroende på värdet av LC_CTYPE. Funktioner som är definerade på bytes och inte på wchar_t eller wint_t påverkas inte av LC_CTYPE.
> Eller mer generellt, hur programmerar man i POSIX och C för att hantera > in- och utdata i UTF-8 utan att samtidigt fucka upp hanteringen av > 8859-1?
Det beror på vad för bearbetning av data ens program ska göra. För många tillämpningar går det utmärkt att behandla UTF-8 som enbart en ström av bytes, precis som ISO-8859-1. För tillämpningar där man måste göra operationer på enskilda bokstäver eller skrivtecken är det en bra idé att använda funktionerna i wchar.h som då kommer att tolka indata olika beroende på LC_CTYPE. För tillämpningar där man måste konvertera mellan flera olika teckenkodningar är funktionerna i iconv.h till bra hjälp.
On Mon, 07 May 2007 12:09:19 GMT, Olof Lagerkvist wrote: > Det är ju 16-bitarstecknen som är riktig Unicode-standard.
Nej, det är en missuppfattning. Unicode-standarden definerar faktiskt bara vilket tal som ska representera ett visst tecken, men ger sedan valfrihet i hur detta tal ska kodas i en dator. UTF-8 är alltså lika mykcet riktig Unicode som de andra rekommenderade kodningarna.
16 bitar är tillräckligt för att representera varje tecken inom den delmängd av Unicode som kallas BMP (basic multilingual plane), men för att kunna representera vartenda tecken som definerats i Unicode så behöver man fler bitar. Se här för en kort introduktion:
> Det är också bra mycket enklare (och mer enhetligt skulle jag vilja > säga) programmeringsmässigt när man vet med 100% säkerhet att alla > tecken är 16 bitar och aldrig kan vara något annat, oavsett om det är > bokstaven 'a' eller något kinesiskt tecken.
Det är bara sant för tecken inom BMP, övriga tecken kommer i Windows att representeras med två 16-bitarstecken efter varandra. Se här för en kort introduktion:
> Nja, "de flesta praktiska sammanhang" är för mej och antagligen de > flesta att data som jag sparar otypat (dvs inte låter ligga kvar i ett > MIME-mail utan sparar till textfil) kommer otypat. FTP, scp, rsync, HTTP > från nåt ställe som inte vet var det är för encoding på filen, textfil > i en tarboll ...
> I dag är dessa filer (ovetenskaplig känsla) antingen ASCII eller > iso-8859-1.
Globalt sett så är nog de flesta sådana här filer idag antingen ASCII, ISO-8859-1, Shift-JIS eller GB2312.
Eftersom det inte är möjligt att med fullständig säkerhet automatiskt identifiera och skilja mellan dessa teckenkodningar så är tanken att man över tid ska manuellt konvertera alla filer i äldre kodningar till UTF-8 i dessa sammanhang och på så vis lösa problemet.
On Sun, 27 May 2007 10:53:46 +0000 (UTC), Fredrik Roubert <roub...@df.lth.se> wrote: > On 6 May 2007 06:50:53 GMT, Jorgen Grahn wrote: ... >> 2. Vad påverkas av att ha UTF-8 som del av $LC_CTYPE, egentligen? >> read(2) och write(2) kommer ju att fortsätta hantera oktetter. >> Är det <wctype.h> från C99 som denna localen jobbar mot, eller vad?
> Just det, det är funktionerna i wchar.h som beter sig olika beroende på > värdet av LC_CTYPE. Funktioner som är definerade på bytes och inte på > wchar_t eller wint_t påverkas inte av LC_CTYPE.
... om LC_CTYPE blandar in UTF-8, alltså.
>> Eller mer generellt, hur programmerar man i POSIX och C för att hantera >> in- och utdata i UTF-8 utan att samtidigt fucka upp hanteringen av >> 8859-1?
> Det beror på vad för bearbetning av data ens program ska göra. För många > tillämpningar går det utmärkt att behandla UTF-8 som enbart en ström av > bytes, precis som ISO-8859-1. För tillämpningar där man måste göra > operationer på enskilda bokstäver eller skrivtecken är det en bra idé > att använda funktionerna i wchar.h som då kommer att tolka indata olika > beroende på LC_CTYPE. För tillämpningar där man måste konvertera mellan > flera olika teckenkodningar är funktionerna i iconv.h till bra hjälp.
Precis den sammanfattningen jag letade efter. Tack!
