Nogle gange er det de små ting, som for eksempel et stort J. Et J, der blot hænger for enden af en sætning i en e-mail. Er det en slåfejl? Er det en signatur, og hvorfor underskriver afsenderen sig blot som J?
Et par mails senere går det op for én, at J'et er en smiley, og at afsenderen bruger Outlook. Men hvorfor går det galt for smileyer i Outlook, når nu alle andre former for kommunikation ser ud til at kunne kommunikere alt fra den basale smiley til auberginer uden vanskeligheder (ok, med visse vanskeligheder - den tager vi en anden dag)?
Svaret ligger tilbage i tiden, og ligesom med problemer med danske tegn og blinkende hjerter i spam-mappen ligger svaret i tegnsæt.
I internettets barndom fungerede emoticons på to måder: Enten skrev man dem med de forhåndenværende specialtegn, så vi havde smileys som :) >) :0 og så videre at arbejde med. Eller også installerede man malware på sin pc for at kunne sende sjove, nye smileyer med MSN Messenger.
Visse af chatprogrammerne fik med tiden indbygget nogle standard-smileyer, men når man skulle kommunikere via e-mail, så var det tilbage til ASCII-alderen med kolon og parentes slut.
I 2007 lancerede Microsoft så Outlook 2007, og så begyndte det store J at dukke op i mails, hvor der burde have været :) eller versionen med næse :-).
Årsagen var, at Microsoft gik bort fra at anvende Internet Explorer til rendering af HTML i Outlook-klienten og i stedet brugte Word. Man havde tidligere haft mulighed for at vælge at benytte Word til at forfatte e-mails, men i Office 2007 fik alle programmerne, inklusive Outlook, den samme stavekontrol og tilhørende autokorrektur som Word.
I Word var det allerede i Word 97 en såkaldt feature for brugerne, at programmet automatisk ændrede eksempelvis (c) til et copyright-symbol og :) til et smiley-face. Ja, det var den samme Word-version, der introducerede Office-Assistenten Clippy.
Word var skabt til at skabe Word-dokumenter i Word-format til Windows-pc'er eller dokumenter på papir. Derfor var det en simpel løsning, der gjorde Word 97 i stand til at bruge et smiley-face i stedet for :). Svaret var skrifttypen Wingdings.
Det var sådan set ikke Microsofts opfindelse at gøre det på denne måde. Allerede inden Autokorrektur blev lanceret, havde Word-brugere indsat specialtegn i deres tekster ved hjælp af skrifttyper som Symbol og Wingdings.
Problemet var blot, at skrifttyper ikke er universelle, og slet ikke Wingdings-skrifttypen, som Word 2007 brugte til at finde smileyer.
Så når man i Outlook 2007 skrev :) blev det af Words Autokorrektur ændret til et smileyface i Wingdings-skrifttypen. Det ville også have været fint, hvis modtagerens e-mailklient forstod, at der midt i teksten pludselig stod et tegn fra en anden skrifttype.
Nu har Word aldrig været kendt for at være den bedste HTML-editor, ligesom mange internetveteraner vil rynke på næsen af HTML-formaterede e-mails, så den kombination betyder, at bortset fra Outlook er der ikke mange e-mailklienter, der forstår Outlooks pludselige skrifttypeskift midt i en mail. Og selv hvis de gør, er det ikke sikkert, at Wingdings er tilgængelig på computeren. Den følger nemlig normalt med Windows og Office.
Derfor bliver smileyen aldrig vist med skrifttypen Wingdings, så HTML-fortolkeren i modtagerens e-mailklient viser i stedet tegnet med den samme tegnkode, men i en anden skrifttype. Og den samme tegnkode som smileyen er i vestlige skrifttyper et J.
Men hvorfor brugte Microsoft ikke bare Unicode, hvor der er masser af emoticons og emojier? Listen af emojier i Unicode er så omfattende, at der endda er en emoji for både en kamel og en dromedar. Og måske kommer der snart en kebab-emoji.
Årets ord 2015 ifølge Oxford Dictionary var endda en emoji fra Unicode-sættet. Men selvom det i dag virker helt naturligt at sende beskeder til sine kollegaer om, at 'chefen er en aubergine', så er emojier i Unicode noget, der først blev introduceret i Unicode 6.0 i 2010.
Så nu kender du årsagen. Hvad kan du gøre for at undgå forvirrende J'er i dine mails? Hvis du er afsender, så skal du ind i indstillingerne for Autokorrektur under skrivning i Outlook og fjerne den regel, hvor :) erstattes med en Wingdings-smiley.
Hvis du er modtager, så ... er der ikke rigtigt noget, du kan gøre. Du kunne skifte til Outlook, men det er måske ikke den mest gennemtænkte business case, hvis den kun består af et irriterende stort J.
:)
for forklaringen.
Kunne man så også forklare outlook-brugere, at de ikke bør invitere til møder via e-mail fra outlooks kalender til ikke-outlook brugere? Jeg har flere gange prøvet at modtage den slags (optræder som en blank e-mail i Thunderbird) og er så nødt til at spørge hvad afsenderen havde i tankerne.
Jeg har oplevet flere programmer fejle på sjove måder når de så unicode emojier, selvom det ellers tilsyneladende virkede fint med Unicode og utf-8.
Emoji høre til den del af Unicode der hedder Supplementary Multilingual Plane og rigtig mange steder er der kun understøttelse for Basic Multilingual Plane, der reelt dækker alle levende sprog.
For eksempel vil en mysql-database hvor character-set er sat til 'utf-8' ikke kunne gemme emojis, da den kun understøtter BMP. Skal man understøtte emojis skal man bruge tegnsættet 'utf8mb4'. Jeg har oplevet flere Drupal- og Wordpress-sites med dette problem og et par forskellige webmails.
Det problem oplever jeg nu ikke i thunderbird med lightning kalenderen integeret. Der bliver invitationer vist og kan accepteres og sættes i kalenderen - tilsvarende med invitationer fra google calendar.
Sidder og smågriner. Får J'er fra én bestemt afsender. Troede det var en kult-ting med at sende skæve smil...
Det er ikke første gang, at Microsoft har valgt sin egen standard for tegnsæt, selv om der findes "rigtige" standarder. Et eksempel er indkodningen af æ, ø, å og diverse andre ikke-engelske bogstaver. Den internationale standard hed i 1985 ISO 8859 (med suffix "-1" for vesteuropæiske tegn), men Microsoft valgte af bruge modifikationer af "Code Page 437" tegnsættet (f.eks. "Code Page 850" for Vesteuropa) i stedet for at gå over til ISO-8859 standarden. Det betød, at tekster lavet på MS-DOS og Windows have andre tegn i stedet for Æ, Ø og Å, når de blev vist på f.eks. Unix eller andre systemer, der brugte 8859-standarden. Først med UTF-8 ser det ud til, at "almindelig" tekst kan flyttes mellem Windows og andre systemer uden de store problemer (udover linjeskiftstegn).
Jeg har tit undret mig over det J, jeg konsekvent får i bunden af alle mails fra min far. Havde fanget at det var en smiley, men troede egentlig det var fordi han besvarede mine mail gennem sin Iphone :)
Tak for forklaring, det var hyggelig læsning!
Der er tilsvarende problemer med flag-emoji'er på FB. Hvis en iOS-bruger benytter dem kan de ikke ses på Android og Windows - der bliver blot vist ISO 3166-2-koden for landet i stedet, f.eks. DK.
Der er også nogle få andre emoji'er der ikke virker på tværs af OS'er i FB, her viser FB på Windows blot hvad jeg går ud fra er Unicode codepoint i stedet, f.eks. 01f3fb. Det virker på Android.
Word autokorrigerer gåseøjne til nogle skæve modeller, der ser pænere ud på skrift: ”gåseøjne”. Når der kopieres fra Word til anden tekstbehandling kan det gå galt; men her gik det godt. Ellers har jeg set mærkelige koder på websider, i aviser o.l. Det gælder også bindestreger, der bliver til lange bindestreger.
Det er ikke så nemt at forklare, at teksten fra Word ikke bare kan kopieres...
Ved I hvad der så burde være vist, hvis jeg på Facebook ser noget der for mig ligner
DKDKDK
skrevet med en lidt mindre og tykkere skrifttype, måske kyrillisk?
Hvis jeg forsøger at paste dem ind her, kan jeg sagtens, men når jeg klikker gem, får jeg beskeden:
"Websitet stødte på en uventet fejl. Prøv venligst igen senere. "
Jeg gætter det måske er en art af tre smileyer, hjerter eller lignende?
Se Finns indlæg.
Det er det næste problem, som jeg vil kigge på (og hvad jeg hentyder til i begyndelsen af artiklen).
Min antagelse er, at DK må stå i stedet for et dansk flag i emoji-form, da jeg også har set eksempelvis SE, og det ud fra sammenhængen vil give mening med et flag. Men præcis, hvorfor det går galt, og hvordan det er kommet så vidt, det må blive i næste kapitel af tegnsætssagaen. J
For HTML-mails er problemet er ikke relateret til, om Wingdings er installeret på maskinen, eller om mailprogrammet skal "forstå" skift til Wingdings. Det er faktisk i strid med HTML-standarden at vise en Wingdings-smiley i dette tilfælde. Så Outlooks opførsel er ikke alene uhensigtsmæssig men decideret i strid med standarden (surprise).
Problemet er rapporteret i et utal af dubletter til Thunderbird. Flg. citat er fra en af dubletterne, der beskriver det således:
"if you use CSS including font-family: Wingdings, you get the correct behavior, a J from another font since Wingdings doesn't have a glyph for a J, just a symbol in the same place where most fonts have a J"
Nu skalman ikke rette smed for bager. Det var ikke Microsoft, mem IBM Danmarks Bruno Christensen, der var ansvarlig for markedsføringen af IBMs PC i 1981 og altså også blev ansvarlig for indplaceringen af æ,ø og å i det danske tegnsæt på IBM's PC og dermed i PC-DOS/MS-DOS og senere Windows.
Han "indrømmede" det selv på et møde med den danske IT branche på Nymøllevej ved introduktionen.
Han var blevet bedt om at placere de danske tegn og ikke-tekniker som han var, vidste han ikke at der fandtes en standard.
Så han placerede dem i det amerikanske tegnsæt hvor der var nogle "gnyffer" han ikke mente blev brugt. Foran mig sad bl.a. Anders Hejlsberg og Flemming Østergård (nej ikke ham fra Parken) fra Polydata og brokkede sig rimeligt højlydt over at æ,ø og å ikke var indplaceret binært korrekt så sorteringer blev mere indviklede (ja ja - det var dengang).
Så codepage 850 skyldes Bruno Christensen fra IBM Danmark. :-)
Code page 437 indeholder æ og å, men ikke ø, så derfor blev code page 865 oprettet til dansk og norsk, hvor cent og yen blev til ø og Ø.
850 var mere gennemarbejdet i forhold til at repræsentere vesteuropæiske sprog, idet bogstaver med accenter erstattede tegn til at lave firkanter; men de binære værdier for æ, ø og å var de samme som i 865.
Godt det er en saga blot...
Først med UTF-8 ser det ud til, at "almindelig" tekst kan flyttes mellem Windows og andre systemer uden de store problemer (udover linjeskiftstegn).
Tjaeh, jo, bop..... bortset fra at "almindelig tekst" på Windows i lang tid har været bastarden "Ansi tekst", som vist nok er næsten det samme som CP-1250, i "Vesteuropa", etc... etc... så festen er langt fra forbi endnu. Og få mig slet ikke startet om ting som BOM....
ja så er det ellers bare at gå igang med gode forklaringer og nydelig gennemgang af historien bag flag, emoji og UTF.
https://www.youtube.com/watch?v=sTzp76JXsoY
Raymond Chen skrev ogsaa om det for en slat aar tilbage, http://blogs.msdn.com/b/oldnewthing/archive/2006/05/23/604741.aspx
Jeg modtager tit en firkant fra min smartphone+ejende vennekreds. Det har jeg så senere fundet ud af er en smiley. Ja ja, jeg skal have en ny telefon lige om snart.
PS: Vidste i iøvrigt at japanerne har et ord for, når text encoding fucker op, og man får det her sære krimskrams af mystiske tegn? De kalder det "mojibake". Men de er også selv ude om at de har været så langsomme til at opdage glæderne ved utf-8, så de har en hel stribe af eksotiske ninja-encoding'er som forhåbentlig snart dør en kort og smertefuld død.
Der er tilsvarende problemer med flag-emoji'er på FB. Hvis en iOS-bruger benytter dem kan de ikke ses på Android og Windows - der bliver blot vist ISO 3166-2-koden for landet i stedet, f.eks. DK.
Så det vil sige at når en eller anden på facebook skriver DKDK så er det bare fordi de bruger IOS og har indsat et dansk flag ?
Har faktisk undret mig over hvad det der DKDK betød, men dog ikke nok til at jeg har gidet bruge tid på at efterforske det :)
@Deichmann - det er præcis, som jeg husker det - IBM var meget fremme i skoen for at få defineret codepages, der dækkede de europæiske lande. På det tidspunkt kunne MS stort set kun se US og derfor 437. Både 850 og 865 og en række andre blev lanceret af IBM først. Det var vist også drevet af, at OS/2 var ret meget fremme i DK i business segmentet...
ja så er det ellers bare at gå igang med gode forklaringer og nydelig gennemgang af historien bag flag, emoji og UTF.
Tom Scotts videoer om emnet kan kun anbefales.
Derudover er det interessant at se, at udviklingen på mobilfronten på flere områder overhaler desktop-fronten - fx med understøttelse af mere komplicerede unicode-sammensætninger:
Ud over at bruge to code points til flag er der fx også hudfarve på emojis (hvor det giver mening), hvor man efter en emoji tilføjer en emoji-modifier for at angive hudfarve, baseret på en dermatologisk standard. Og så er der selvfølgelig de noget mere spændende tilfælde, hvor man gør brug af et Zero Width Joiner-codepoint til at kombinere forskellige emojis til en enkelt glyf.
Firefox på en almindelig Windows 10 lader ikke til at have den store understøttelse her. For hudfarve bruger den blot fallback ved at vise hudfarven som en farvet firkant efter emojien, men for landeflag viser den blot bogstaverne noget mindre, hvilket rigtig nok i første omgang leder tankerne over på andre tegnsæt som fx kyrillisk, men reelt er der blot tale om en dårlig repræsentation; officielt skal der være prikker rundt om hvert bogstav, som videoen også nævner.
Jeg har ikke testet så meget med den del, men det kunne være interessant at høre, om andre kombinationer af browsere og traditionelle styresystemer/grafiske brugergrænseflader har bedre understøttelse - eller om udviklerne af disse betragter det som noget, som kun er interessant for mobilbrugere. Det ville dog være lidt trist.
"if you use CSS including font-family: Wingdings, you get the correct behavior, a J from another font since Wingdings doesn't have a glyph for a J, just a symbol in the same place where most fonts have a J"
Nu mener jeg jo, at meget gik galt, da man gik over til, at alt skulle laves med CSS og span-tags, men jeg er også HTML-konservativ.
Men jeg forstår simpelthen ikke argumentet i den sidste kommentar, som du citerer (men måske er det min CSS-viden, der er outdatet). For begge varianter (font face, font-family) burde vel tage tegnet svarende til J fra den pågældende skrifttype? Det lyder i den sidste kommentar som om HTML-koden burde fortolkes således, at der skal stå et J, og fordi der ikke er et J i Wingdings, så skal der bruges en anden skrifttype?
I så fald kan jeg godt forstå, at fejlen er opstået - og stadig findes - for det virker ikke intuitivt på mig, men som sagt er min viden om HTML nyere end 3.x temmelig rusten (med HTML 4 blev webdesign alt for meget arbejde og for lidt sjov).
Sjovt nok stødte min nørdemand på dette problem: En kundes (meget grimme) webpage, var pludselig på japansk/dansk. Men jeg havde heldigvis lige læst på wikipedia om "emoji bake"- som handler om oversættelsen af tegn.
Og når det går galt!
Siden var lavet i win xp, og at blive generet gennem win 8- og oversat til Linux, gjorde ikke noget godt! Min nørdemand troede den var hacket (har vi oplevet), men jeg kunne berolige ham med, at det sandsynligvis var "emoji bake": Tegnsætsuforenlighed (Uff kan man ikke sige dette kortere?)
Fejlen var nu let at rette! (Men siden er stadig grim, ligner noget, der er faldet ud af 90-erne. Og det er en prof kunde, men hjemmesider til kun 2500 kr... Ja ja! Så vil de ikke sælge..)
Mvh
Tine- der læser meget og støder på sære ting. Emopji bake udtales som emoji baykake.
Mv
For begge varianter (font face, font-family) burde vel tage tegnet svarende til J fra den pågældende skrifttype?
Jeg har ikke større indsigt i emnet, udover at jeg har stor tiltro til Mozilla-udviklernes konklusioner i sager som denne.
Som jeg forstår problemstillingen (dette er blot et ikke særlig kvalificeret gæt), så er hvert tegn i en font kendetegnet ikke alene ved et offset i fontfilen men også noget yderligere metadata, der beskriver tegnets Unicode-værdi. Forskellige programmer kan så håndtere tekst enten som en liste af offset-værdier eller en liste af Unicode-værdier. I en almindelig font er der sammenfald mellem offset og Unicode-værdi (i hvert fald for de første tegn i filen), så de to metoder vil give samme resultat. Men i en symbolfont som Wingdings, hvor tegnene mapper til høje Unicode-værdier (hvis de da overhovedet har en Unicode-repræsentation), giver de to metoder forskelligt resultat.
Well, som sagt er det blot min løse fornemmelse.
Version2 er en del af Jobfinder - Danmarks største job- og karrieresite for ingeniører og it-professionelle.
