Diskussion:UTF-8

message: 194.47.144.5 har bytt ut standard ISO 8859-1 minus sign mot Unicode U+2010 i denna artikel och några andra (UTF,UTF-32, Plancks konstant, ISO/IEC 10646). Liknande byten av ISO 8859-1 slash mot Unicode U+2013.
Då dessa tecken fortfarande i de flesta webläsare endast visualiseras som en "ruta" tycker jag att det tills vidare är bättre att behålla de gamla tecknen.  Sten André 29 januari 2004 kl.12.29 (CET)
Med vilka webbläsare fungerar det inte?  Hur länge ska Wikipedia vänta med att använda det som är dagens etablerade teckenuppsättning?  Tills alla webbläsare i hela världen fungerar felfritt?
 ― 194.47.144.5, den 29 januari 2004 kl.12.45 (CET)
Jag kör just nu MS Explorer i Windows 2000. Jag har bara sett dessa och liknande tecken fungera i MS Explorer under Windows XP. Jag har även försökt uppdatera till senaste version av Explorer men det verkar snarare ha med Windows-version än med Explorer-version att göra. Vi har haft liknande diskusioner om t.ex. ∧ och ∨ i vissa artiklar som fungerar utmärkt i mina webläsare men tydligen inte i Windows 98. Riktlinjerna tills vidare tycker jag ska vara att undvika tecken utanför ISO 8859-1 så länge. Dessutom är html-en i de svenska wikipedia-sidorna märkta med "charset=iso-8859-1". Det är lite tråkigt eftersom det finns många användbara tecken i Unicode.Sten André 29 januari 2004 kl.13.05 (CET)
Jag kan ju meddela att tecknen fungerar utmärkt för mig (annars hade jag ju inte skrivit in dem), och jag kör Mozilla 1.6 under Debian GNU/Linux 3.0 (stable).
Om svenska Wikipedia skickar dum charset-märkning så är det dags att fixa detta i stället för att låtsas som att det är en naturlag.
 ― 194.47.144.5, den 29 januari 2004 kl.13.40 (MET)
Jag håller med om att det vore bättre att även svenska wikipedian hade charset=utf-8 liksom en del av de andra (t.ex. den japanska naturligtvis). Jag vet inte vad som är orsaken till att så inte är fallet. Kanske E23 vet?Sten André 29 januari 2004 kl.16.03 (CET)
replies: text: Övergången till UTF8 kräver en ganska kostsam konvertering om jag har förstått saken rätt, men jag ska se om det inte går att genomföra. Det är i vilket fall planerat att hela wikipedia ska köra enbart UTF8 tids nog. Även om jag håller med om att vi bör använda moderna kodningar, så är det ändå viktigare att wikikoden är läsbar för icke-tekniker. Tills vi har en wikiuppmärkning som vi kan använda istället för ― vill jag starkt avråda från användandet. // E23 29 januari 2004 kl.16.21 (CET)
Visst, visst, planer är bra, men när?  Man kan inte dra ut på det i all evighet; det kommer aldrig att funka helt perfekt för alla förrän det redan är föråldrat!  Unicode funkar för en klar majoritet nu, idag, och det är dags att de som kör föråldrade saker får incitament att uppgradera.  Jag säger: konvertera nu och gör jobbet nu; det är redan litet nog. Och Wikipedia har mycket att vinna; det är en av trots allt ganska få ställen som vekligen behöver visa mera udda tecken.
(Själv skriver jag inte ―, jag skriver in tecknet direkt.  Det är Wikipedia som konverterar tecknet till det formatet.  Skulle jag vilja skriva på den formen så skulle jag åtminstone skriva ― – Unicode-tabeller brukar lista tecknen med hexadecimala siffror, vilket gör 2015 lättare att hitta än 8213 för den som skulle råka läsa HTML-koden.)
 ― 194.47.144.5 29 januari 2004 kl.18.42 (CET)
Jag tror inte dessa unikod-tecken är en del av HTML4-standarden ens! Liknande tankestreck (em-dash) — (—) eller generellt bindestreck (en-dash, hyphen) – (–)), eller minusteckn (-), skulle väl kunna användas för detta ändamål? Eller som Romannose brukar säga: keep life simple (d.v.s. gör det enklaste). // rogper 29 januari 2004 kl.19.28 (CET)

text: Unicode-tecken ska visas korrekt om teckenkodningen är markerad som UTF-8 och har ingenting att göra med HTML.  Sedan att ― tolkas som ett Unicodetecken även om teckenkodningen är angiven som iso-8859-1 är mera pragmatism av webbläsarna.  Dessutom så är bindestreck inte samma sak som ’–’.  Jag kan bara referera till Kapitel 6 i Unicode 4.0.

text: ― 194.47.144.5 30 januari 2004 kl.13.37 (CET)
Jag har nu kollat hemma på min XP-dator med senaste versionen av Explorer. De tecken som 194.47.144.5 vill ha visas inte korrekt där heller. Därmed är det nog inte riktigt sannt att dessa tecken fungerar för en majoritet, nu idag. Dessutom skulle jag gärna vilja veta vad som var det ursprungliga syftet med ändringen. Den typografiska skillnaden mellan dessa tecken måste vara minimal, även om man har fonter i sin dator som kan visa dem. Och det spelar nog ingen roll om vi skulle konvertera svenska wikipedian till UTF-8, webläsarna måsta klara av att visa tecknen. Grundproblemet är ju att fonterna inte är uppdaterade med alla Unicode tecken.Sten André 29 januari 2004 kl.19.41 (CET)

text: Inte ens på Mac OS 9 fungerar det, och Apple är en av skaparna bakom Unicode... :-) (Men Mac OS X fungerar utmärkt med Unicode). Om så önskas kan man, tror jag, definera egna tecken-referens-namn (typ &abc;), högst upp före första <HTML>-märket, om man så vill... t.ex. <!ENTITY utf8_bindestreck    CDATA "-" -->, och sedan skriva "UTF&utf8_bindestreck;8". (för vissa webbläsare ersätts "-" med ― genom PHP-kod). (Men jag håller med 194.47.144.5 att wikin borde vara så modern som möjligt—i värsta fall får unikod-tecken renderas till en bild som sätts in i webbsidan...) // rogper 29 januari 2004 kl.19.48 (CET)

text: Jag testade just på Internet Explorer under Windows XP, båda fullt uppdaterade.  Det enda som inte fungerade av de tecken jag hade skrivit in på de sidor jag ändrat var ”‐” (U+2010 HYPHEN).  Och blanda inte ihop Unicode och HTML; skumma saker som entiteter i HTML är det säkert knepigt att få webbläsare att stödja, men en teckenkodning är en teckenkodning och när väl en webbläsare får charset=utf-8 så är det ju inte så mycket tvivel om hur tecknen sedan ska visas.

text: ― 194.47.144.5 30 januari 2004 kl.13.37 (CET)
replies: text: :Tyvärr är inget enkelt här i världen. Generellt är character references av typen &#xNNNN; eller &#NNNN en del av HTML 4.0 men få webläsare klarar alla Unicode-tecken. Min webläsare klarar utmärkt – – och – d.v.s alla sätt att koda "en dash" men inte ‐ eller ‐ d.v.s. "hyphen" !!! De tecken som har ett standardiserat HTML-namn som – är i allmänhet mindre problematiska än de som saknar sådant.Men min fråga kvarstår, varför man skulle vilja använda dessa tecken istället för vanlig ASCII "hyphen-minus", eftersom de skiljer sig minimalt, om något över huvud taget, typografiskt från varandra.Sten André 30 januari 2004 kl.12.51 (CET)

text: Jag tycker att vi ska undvika att blanda ihop HTML och Unicode här; det är två olika saker.  Man kan ha en "text/plain; charset=utf-8" och man kan ha "text/html; charset=us-ascii", det ena är bara Unicode och det andra är bara HTML utan spår av Unicode.

text: Sedan att jag vill använda Unicodetecken i stället för ”-”, ”"” och ”'” är för att Unicodetecknen är helt enkelt  tydligare.  När man skriver ”-”, är det bindestreck, tankestreck, minus eller citatstreck man menar?  Det finns alternativ i Unicode som är otvedydiga om vad man menar.  Man skulle lika gärna kunna fråga ”Varför skriver man en HTML-lista med  och  när man lika gärna kan skriva en punktlista i ASCII med asterisker som skrivmaskinister gjort i alla tider?”

text: ― 194.47.144.5 30 januari 2004 kl.13.37 (CET)
replies: text: : HTML-specen säger också att man kan använda inbäddade bilder istället för teckenreferenserna. Skapa dina egna bilder, typ: minussign.png, hyphen.png, endash.png, emdash.png och använd dem som du vill. Alternativet vore ju att använda latex, men just nu verkar det inte fungerar fullt för de fyra alternativen (-, --, --- och minustecken $-$) // rogper 1 februari 2004 kl.21.58 (CET)

message: För avsnittet om Kompatibilitet finns två förslag till formulering, som tolkar problematiken olika:
# Problem har minskat allt eftersom texter allt mer sällan tolkas som Latin-1. Syftet med Unicode är att det inte ska behöva införas ytterligare standarder och därför borde dessa problem försvinna.
# Problem har minskat allt eftersom programvara uppdateras. Syftet med Unicode är att det inte ska behöva införas ytterligare standarder och därför borde dessa problem inte dyka upp mer.
Min uppfattning är att så gott som all programvara redan stöder UTF-8. Standarden slog väl igenom för ungefär tio år sedan, så undantaget torde närmast vara dinosauriesystem och programvara som knappast alls underhålls. Att programvara uppdateras borde alltså inte påverka problematiken i någon större omfattning.
Däremot finns det fortfarande mängder av texter skrivna som Latin-1. Standarden för HTML säger att text skall antas vara kodad i Latin-1, om inte annat anges. Webbservrar vet sällan vilken kodningen är (att analysera texten kräver extra resurser), så uppgiften om kodning kan vara mer eller mindre slumpmässig, i synnerhet om webbservern upprätthålls skilt från innehållet. Många e-postprogram gör också slarviga antaganden om kodningen.
Jag tycker alltså att den senare formuleringen ger en felaktig bild av verkligheten. Uppdatering av programvara hjälper, om uppdateringen handlar om att bättre anpassa sig till den faktiska kodningen. Om köparen inte ställer krav på detta kommer uppdateringen snarare att handla om att ändra antagandet, så att all text tolkas som UTF-8 istället för som Latin-1. Istället för "knÃ¤ckebrÃ¶d av rÃ¥g" får vi då "kn?kebr? av r?" eller liknande (i de fall texten fatiskt var Latin-1).
--LPfi 13 januari 2011 kl. 08.42 (CET)
replies: text: Problemet som avses är att text kodad i UTF-8 inte känns igen av programvaror. Din skrivning "Problem har minskat allt eftersom texter allt mer sällan tolkas som Latin-1" tolkar jag som "problemet har minskat allt eftersom problemet har minskat". Orsaken till att detta problem har minskat är att programvaror (i första hand webläsare och epostprogram, för dessa kommer i kontakt med filer utifrån) uppdaterats. Idag är detta problem mer sällsynt, eftersom, som du skriver, de flesta har uppdaterat sina webläsare och epostprogram. Mitt textförslag är en historieskrivning, orsaken till att problemet har minskat, och inte ett påstående att det är ett stort problem nu. Jag förstår inte sista stycket. Om man har ett program som inte är uppdaterat för att läsa UTF-8 kan det omöjligt tolka något annat som UTF-8 eftersom programmet inte vet vad det är.--BIL 13 januari 2011 kl. 20.47 (CET)
replies: text: : Uppdatering av programvaror handlar sällan om att programvaran skulle bli bättre på att "känna igen" Latin-1 eller UTF-8. Jag har för mig att få programvaror gör en textanalys innan de väljer vad de skall visa texten som. Därför kvarstår det du säger att är problemet efter uppdateringen.

text: : Vad som hänt är dels att programvara fått gott stöd för UTF-8 (vilket jag alltså gissar att hände för flera år sedan) och att de ställts in att tolka text som UTF-8, då inget annat anges (när de förut i de fallen tolkade texten som Latin-1). Det är detta som gjort att problemet inte längre syns. Och visst: då man ställer in program att tolka text som UTF-8 försvinner problemet att text inte tolkas som UTF-8.

text: : Det sista stycket handlar om program som klarar både Latin-1 och UTF-8, men för tio år sedan i första hand tolkade text som Latin-1 och nu i första hand som UTF-8. Jag uppfattar alltså att det inte är ett problem som nu lösts genom av bättre programvara utan att problemet försvunnit för att texter allt mer skrivs i en viss kodning, UTF-8. De "uppdaterade" programmen klarar fortfarande inte att lista ut hur texten är kodad utan visar lika mycket skräp som förr, i de fall texten inte är skriven i den kodning de primärt förväntat sig.

text: : Vad gäller historieskrivningen så har du delvis rätt. Program som inte stödde UTF-8 var ett problem då pionjärerna började använda kodningen. Men problemen har funnits kvar långt efter att de flesta program de facto hade stödet och det är den tiden jag tänkte på (till exempel jag har fortfarande Latin-1 som primär kodning på den här datorn, så det är inte frågan om ren historia).

text: : --LPfi 25 januari 2011 kl. 09.52 (CET)
thread_title:  Tolkning som UTF-8 eller Latin-1