Programmering: Derfor er der forskel på store og små bogstaver

Illustration: Wikipedia/Toxophilus
Vi starter lige i antikkens Rom, før vi kan forklare, hvorfor der er forskel på at skrive Javascript og JavaScript.

Denne artikel begynder med et stort D. Men hvorfor gør den egentlig det? Når det kommer til stykket, repræsenterer sammensætningen af bogstaverne lyde, som opfattes som ord, og her er der ingen forskel på store og små bogstaver. Alligevel gør vi meget ud af regler for, hvor der skal bruges d eller D.

Det begyndte med en læser, som klagede over, at jeg skrev Javascript i stedet for JavaScript. Det førte til, at jeg ville skrive noget om CamelCase og trælse stavemåder i it-branchens firma- og produktnavne. Men så faldt jeg i et researchhul, og det følgende er min fortælling nede fra hullet.

Store bogstaver ville ikke have givet mening for en borger i antikkens Rom. Medmindre det skulle forstås så bogstaveligt som den fysiske størrelse på bogstaverne, for det ville give fin mening, da 2.000 år gamle inskriptioner på romerske bygningsværker er temmelig store bogstaver. Og disse store bogstavers udformning svarer til det, vi i dag betegner som store bogstaver.

ROM: STORE BOGSTAVER

Romerne havde ikke slået Caps Lock til. De skrev bare på den eneste måde de kendte. Altså bortset fra, at når de skrev i hånden, så det noget anderledes ud - i et omfang, så begrebet kragetæer, eller i hvert fald det sproglige billede af en fugl, der fører pennen, kan spores tilbage til romertiden - men det var ikke sådan, at der var en stor og en lille udgave af det samme bogstav.

Altså forstået på den måde, at der i den samme tekst optræder to varianter af det samme bogstav. Som eksempelvis et stort P og et lille p.

Lige netop dét bogstav er ét af dem, der antyder, at oprindelsen af store og små bogstaver hænger mere sammen med noget æstetisk, snarere end at kunne skelne tydeligt mellem en stor og en lille udgave. Formen af P og p er næsten identisk, og den væsentligste forskel er, at det lille p går under linjen, mens det store P går over linjen. Linjen her forstået som det område, der er afgrænset af over- og underkanten af bogstaverne i et ord som 'sensommer'.

Normalt har store bogstaver som i det romerske alfabet alle samme højde, som i 'SENSOMMER', om end den mest berømte udgave af det romerske eller latinske alfabet havde et Q, som gik under linjen.

Nyt kapitel

Store bogstaver, der skilte sig ud fra resten, dukkede op i bøger fra cirka år 600, hvor de store bogstaver igen var meget bogstaveligt større end resten, da de ofte var dekorerede og nærmest illustrationer til teksten. Det var en tradition, som fortsatte selv efter Gutenberg var begyndt at trykke bibler. Forskellen fra 600-tallet til 1400-tallet var, at i manuskripterne fra 600-tallet var de store bogstaver stadig blot store udgaver af de normale bogstaver.

Men i Gutenbergs bibel bliver store bogstaver brugt på en moderne måde, hvor de store bogstaver som eksempelvis B er forskellig fra et lille b. Samtidig er der i løbet af middelalderen opstået egentlig retskrivning, for Gutenberg bruger de store bogstaver som stort begyndelsesbogstav efter punktum.

Det ses også i eksempelvis Jyske Lov fra 1241. Her er det kun ved nye kapitler eller underkapitler, som får et stort begyndelsesbogstav, så der bruges ikke store bogstaver efter punktum. Det ændrer sig altså i slutningen af middelalderen med udviklingen af retskrivning.

Dermed er der en vis betydningsmæssig forskel mellem de store og små bogstaver. De er gået fra at være ren dekoration til at være noget, som bruges til at hjælpe læseren, nøjagtigt lige som punktum og mellemrum gjorde det. Ja, selv mellemrum har ikke altid været en del af skriftsprogene.

Nu nærmer vi os, hvorfor romerne og Gutenberg er relevante i datalogien, men først skal vi lige klare os gennem pest og kolera i 1700- og 1800-tallet. Det er nemlig i denne periode, at de store og små bogstaver får særlig betydning.

Ting med stort i Tyskland

I Tyskland - og i Danmark som sprogligt var meget under indflydelse af tysk sprog på dette tidspunkt - begyndte man at skrive ikke blot egennavne, men alle navneord med stort begyndelsesbogstav. Det forudsatte, at man allerede var i stand til at tale om grammatiske ordklasser.

Tyskerne begyndte også - i modsætning til eksempelvis englænderne - at sammenskrive ord. Og ja, Danmark gjorde det samme. Og reglen for sammensatte navneord blev 'Navneord' og ikke 'NavneOrd'.

Da Ada Lovelace skrev sit første computerprogram brugte englænderne også stort begyndelsesbogstav i navneord, men Ada Lovelaces kode var mest i matematisk notation, så vi ved ikke, om Ada var til CamelCase eller foretrak rene versaler ligesom i de første programmeringssprog, der dukkede op cirka 100 år efter hendes død.

Sprog som FORTRAN brugte udelukkende store bogstaver. Eller helt præcist brugte tidlige computere blot 6 bit til tegnsættet og havde derfor kun plads til enten store eller små bogstaver - og det mest almindelige var at bruge store bogstaver. Senere sprog brugte store bogstaver til alle nøgleord, og derfra gik det stærkt med stilvalg i programmering.

Jeg har tidligere skrevet om tabulator vs. mellemrum, men det er blot at kradse i overfladen af en byld ved navn 'style guides'.

Sprog, der ikke blev oversat af en compiler, var begrænset af, at koden helst ikke måtte fylde for meget. Der var begrænsninger på længden af nøgleord og variabelnavne. Dengang, en computer hed en datamat og en app hed programmel, var det altså mere passende at kalde 'JavaScript' for 'JS'.

Maskinen læser forskellige tegn

Men der opstod også en meget mere væsentlig forskel. På tryk var H og h mest en æstetisk forskel, og ud fra sammenhængen tager man sjældent fejl af Hans og hans. Men på computeren er H og h to forskellige tegn.

Det er trivielt at lade computeren være ligeglad, men det blev snart en fordel at have flere forskellige tegn til rådighed - også det at have store og små bogstaver. Eksempelvis til kodeord. I lang tid kunne et kodeord maksimalt være på otte tegn, og for at øge entropien, altså det mulige antal kombinationer, så var det oplagt at skelne mellem tegnene for et stort P og et lille p, så 'Password' og 'password' var to forskellige kodeord.

Dermed var kimen også lagt til den måske mest almindelige supporthenvendelse om loginproblemer.

I udviklingen af programmeringssprogene blev der også truffet et vigtigt valg. Mellemrum var ikke blot lidt større afstand mellem grupper af bogstaver for at gøre det lettere at skelne mellem enkelte ord. Mellemrum blev adskillelsen mellem nøgleord i koden. Et nøgleord, variabelnavn eller metodenavn kan ikke spænde over et mellemrum.

For en tysker eller dansker er det helt trivielt at læse et ord som 'kirsebærtærte'. Men for den engelsktalende er 'cherry pie' i to ord, så hvis man som engelsktalende objektorienteret programmør skal bage en ny kirsebærtærte så fungerer 'new cherrypie' ikke rigtigt, og programmeringssproget forstår ikke 'new cherry pie'.

string eller String?

De store og små bogstaver fik også særlig betydning i mange programmeringssprog. En 'Kirsebærtærte' med stort K signalerer eksempelvis, at der er tale om en klasse i mange objektorienterede sprog. Og så opstod balladen. For nu stod vi en situation, hvor store bogstaver fik en særlig betydning, og samtidig var der en teknisk forskel mellem G og g.

Ligesom typografen skulle finde det lille t i én skuffe og det store T i anden for at opsætte avisteksten, så er de to tegn også forskellige koder for computeren. Når den læser ordet 'Type', så er det en sekvens af tegnkoder. Ændrer man det til 'type', så er det en anden sekvens af tegnkoder. Og ligesom at udskifte et ciffer i et telefonnummer, så kan den anden tegnsekvens ende med at pege på noget helt andet end planlagt.

På den måde kan man opleve, at der i et programmeringssprog er forskel på at skrive 'String' og 'string'. Her er konventionen, at det ene henviser til klassen ved navn 'String', som kan indeholde nogle metoder og egenskaber, der kan manipulere et objekt. Tilsvarende er 'string' en mere primitiv type, som blot rummer en sekvens af tegn, der tilsammen udgør en tekststreng.

Men store og små bogstaver i samme alfabet, også kaldet 'bicameral', giver visse komplikationer, også uden for programmering. På dansk har vi eksempelvis 'I' og 'i' eller 'De' og 'de', hvor de store bogstaver ændrer betydningen og brugen af et ord.

Georgisk programmering med små bogstaver

Sådan behøver det ikke være. Der findes alfabeter, som er rent 'majuscule' eller 'unicase', hvor alle bogstaver er store bogstaver. Men der findes også enkelte alfabeter, der udelukkende består af små bogstaver - her forstået som at ikke alle bogstaver er lige høje, og nogle bogstaver går under linjen. Eksempelvis georgisk skrift.

Så hvis programmering var opfundet i Georgien, ville der kun være 'string'. Endnu mere anderledes havde det været, hvis programmering var opstået i eksempelvis Kina, hvor alfabetet - eller rettere skriftsystemet - består af tegn, som dækker stavelser eller sammensætninger af stavelser, og hvor der hverken er store eller små bogstaver. Forskellen er så stor, at det er muligt at være ordblind på dansk, men ikke kinesisk. Til gengæld er der op mod 5.000 forskellige tegn, så entropien for et kodeord på kinesisk ville være betydeligt større for et kodeord på otte tegn.

Hvordan hænger det så sammen med CamelCase? Jo, for det første har vi i de fleste vestlige sprog forskel på store og små bogstaver. For det andet har mellemrum en særlig funktion i mange programmeringssprog. Og endelig læser computeren de store og små bogstaver som forskellige tegn.

Derfor får man en fejl, hvis man skriver 'Camelcase' ét sted i sit program og 'CamelCase' andre steder. Og man får en anden fejl, hvis man skriver 'Camel Case'.

Læsehjælp

For programmøren har de store bogstaver en særlig funktion, ligesom de fik da de blev brugt ved begyndelsen af et nyt kapitel i et manuskript eller til at vise, at eksempelvis et kongenavn var noget særligt i teksten. Dels kan store bogstaver signalere, at noget er en klasse - det svarer til kongenavnet. Men det kan også være en læsehjælp, ligesom det store bogstav efter et punktum.

I kildekode ser man derfor konventioner som 'getCake' eller 'GetCake', hvilket kan variere mellem de forskellige programmeringssprog. Her bruges de store bogstaver til at vise, at ordet er sammensat og gøre det lettere at identificere de dele, det er sammensat af. Det er også muligt for læseren at skelne mellem 'OnDemand' og 'OndeMand'.

Men hvad så med 'Javascript' og 'JavaScript'? Det er en kombination af to ting. Rettelig ville den normale engelske skrivemåde være 'Java Script', og så ville der ikke være nogen tvivl. Men måske inspireret fra programmeringssproget selv, så blev ordet sat sammen. Det er ikke enestående, og i dag er der mange varemærker og firmanavne, som er sammenskrevne ord.

På dansk ville sproget måske være født som 'Javaskript' (som i 'manuskript') i ét ord og med stort begyndelsesbogstav. Den store udfordring er så, hvad man gør, når et ord importeres til dansk?

Dansk retskrivning siger, at generelt kan navne på steder, personer og firmaer bryde med de almindelige regler for eksempelvis brug af store bogstaver. Det er også derfor, at alle der hedder 'Kierkegaard' ikke skal skrive det som 'Kirkegård'.

Dermed er vi fremme ved, at JavaScript hedder JavaScript på engelsk, fordi der er forskel på store og små bogstaver, og fordi mellemrum ganske vist er normalt på engelsk, men ikke går i programmering, samt at vi efter dansk retskrivning burde skrive Javascript, men at det er accepteret at skrive JavaScript, fordi det er sådan, afsenderen ønsker det stavet.

Tilbage i Rom ville diskussionen ikke have givet mening, for der kodede de bare i IAVASCRIPT (de havde ikke J som selvstændigt bogstav, så måske havde dét i stedet været balladen for VERSION II).

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (24)
Thomas Nielsen

...som jeg synes det er værd at bemærke er, at syntaks, retstavning og andet gøjl som ikke er decideret regelpåvirket (læs: bruges i en fortolker eller andet) alene defineres ved sin anvendelse mellem mennesker. Bare fordi det står på tryk et sted, at sådan er det, er det jo ikke givet at koncencus er således, men blot et eksempel på at en med en holdning har skrevet det ned og altså ikke nødvendigvis har ret. Eet menneske kan ikke have ret når det gælder sprog - kun mennesker som kommunikerer sammen kan påberåbe sig en vis vægt (siger jeg, ene mand).

Jan Heisterberg

Spændende, underholdende læsning, MEN det havde været rart med mere stringens og nøjagtighed i teksten - den taber ved at være lige på, men aligevel ved siden af.

Det er jo indlysende, at skal en computer skelne mellem P og p, så må de nødvendigvis repræsenteres (gemmes) forskelligt - altså som Peter og pan, ikke som Peterpan.
Det er tilsvarende indlysende, at en række af de nævnte regler (længde af passwords, brug af mixed case, brug af tal, brug/ikke-brug af blankt tegn) er syntaksregler opfundet til lejligheden og måske af nød. I dag er disse regler stort set forsvundet og erstattet med krav om mangfoldighed og større længde (end 4/8 tegn).

Der savnes et afsnit om den teknologiske baggrund, som især handler om de begrænsninger der har hersket igennem tiderne.
Der var engang et it-tegnsystem som hed EBCDIC med 256 tegn, svarende til 8 bit. Her var en del tegn reserveret til "kontrol" og resten til tal-tegn og bogstav-tegn. (https://en.wikipedia.org/wiki/EBCDIC)De store bogstaver i udskrifterne var en teknologisk/økonomisk begrænsning i datidens printere (linieskrivere med en bogstavkæde).
Desværre blev systemet opfundet af analfabeter, næsten, som kun kendte det korte, engelske, alfabet. Derfor kom f.eks. fransk, dansk, svensk, norsk til kort: de særlige tegn var bare ikke med. Så kunne man snyde systemet på skærme og på printere ved at lade eet tegn (bitkombination) betyde forskelligt når det blev vist eller printet. F.eks.: $ og Å eller æ og ä.
Heldigvis fik det med PC-æraen en ende, idet der blev lavet en ny standardisering (code pages). Og derefter kan vi alle på en standard PC og standard printer skrive både engelske bogstaver og nationale tegn som üæøåÜÆØÅäöéèô og mange flere. Også andre sprog fik løsninger - nogle måtte benytte 32 bits (double byte) for at få tegn nok.
Så et PC-tastatur (og den bagvedliggende fortolkning) knyttes til et sprog (engelsk, fransk, dansk, svensk, tysk, ....) MEN med snedige kombinationstryk kan man skrive de andre sprog.
P.S.: Den bedste forklaring for en engelsk-talende nær-analfabet om betydningen af nationale tegn og accenter kan vises ved de fire ord (fransk): cote, côte, côté og cotè - som betyder fire forskellige ting.

Magnus Jørgensen
class Estimat(object):  
    def __init__(self):  
        object.__init__(self)  
        self._personligt_estimat = 0  
   
    @property  
    def personligt_estimat(self):  
        return self._personligt_estimat  
   
    @personligt_estimat.setter  
    def personligt_estimat(self, nyt_estimat):  
        self._personligt_estimat = nyt_estimat  
   
   
class PersonligVurderingsPropagator(object):  
    def __init__(self, selvens_selv):  
        object.__init__(self)  
        self._selvens_selv = selvens_selv  
   
    def værdset_anden_person(self, anden_person):  
        self._selvens_selv.find_person_estimat(anden_person)  
   
   
class Person(object):  
    def __init__(self, navn):  
        object.__init__(self)  
        self._navn = navn  
        self._PersonligVurderingsPropagator = PersonligVurderingsPropagator(self)  
        self._estimat_af_andre_personer = {}  
   
    @property  
    def navn(self):  
        return self._navn  
   
    def find_person_estimat(self, person):  
        if person in self._estimat_af_andre_personer:  
            return self._estimat_af_andre_personer[person]  
        else:  
            nyt_extimat = Estimat()  
            self._estimat_af_andre_personer[person] = nyt_extimat  
            return nyt_extimat  
   
    def udtal_om_andre_personer(self):  
        for person_estimat_bundt in self._estimat_af_andre_personer.items():  
            person = person_estimat_bundt[0]  
            estimat = person_estimat_bundt[1]  
            print("%s er nu %d i mit estimat." % (person.navn, estimat.personligt_estimat))  
   
jesper = Person("Jesper Stein Sandal")  
mig = Person("Magnus Møller Jørgensen")  
   
estimat = mig.find_person_estimat(jesper)  
estimat.personligt_estimat += 10  
   
mig.udtal_om_andre_personer()
Michael Aggerholm

Er det der C#?

Undskyld mig men jeg tror aldrig jeg har set så meget boilerplate kode i mit liv. Hvordan kan så meget kode gøre så lidt?

Det var da heldigt at du slap for persisteringen, ellers var elevatoren i min scrollbar her på siden blevet reduceret til et par pixels i højden.

Torben Mogensen Blogger

Det romerske Q gik ikke alene under basislinjen, det strakte sig også ind under det efterfølgende V (som altid følger Q i latin, ligesom Q altid følges af U på moderne engelsk). Så det har nok egentlig været en QV ligatur, ligesom Æ på latin er en AE ligatur. Q havde dog ofte også hale, når det stod alene, f.eks. i forkortelsen S P Q R.

FORTRAN og COBOL var ganske rigtigt oprindeligt defineret til kun at bruge store bogstaver, da Baudot tegnsættet, som blev brugt af telex-maskiner, kun havde havde store bogstaver. Det havde heller ikke tegn for < og >, hvilket er grunden til at man i FORTRAN brugte .LT. i stedet for <.

Anderledes var det med ALGOL 60, der definerede sit eget tegnsæt med både store og små bogstaver og en del matematiske symboler. Endvidere foreskrev ALGOL 60-rapporten, at nøgleord (som blev skrevet med småt) skulle fremhæves enten med fed skrift eller understregning, så de kunne adskilles fra variabelnavne. Faktisk definerer rapporten nøgleord som enkeltsymboler, der ikke har relation til de bogstaver, de er bygget af. Men da designerne var klar over begrænsningerne i hardware, tillod de erstatninger for manglende tegn. De standardiserede ikke dette, så forskellige oversættere brugte forskellige erstatninger. I starten var det almindeligt, at der blev brugt store bogstaver overalt, inklusive for nøgleord. Derfor var det almindeligt, at man selv på computere med større tegnsæt ikke skelnede mellem store og små bogstaver -- hverken i variabelnavne eller nøgleord.

Senere sprog såsom MODULA brugte versaler til nøgleord og minuskler til variabelnavne, igen for at skelne. I moderne sprog er det ikke almindeligt at adskille nøgleord og variabelnavne syntaktisk, men nøgleord er i reglen skrevet kun med småt. I nogle sprog er der konventioner om brug af store bogstaver til f.eks. klasser og små til variabler, men det er i reglen ikke påtvunget. I nogle sprog er begyndelsesbogstavets størrelse dog afgørende -- i Haskell begynder f.eks. funktions- og variabelnavne med småt, mens konstruktor- og typenavne er med stort.

Der har endda været sprog, hvor farven af bogstaverne har betydning: https://en.wikipedia.org/wiki/ColorForth

Ditlev Petersen

Ikke fordi det er vigtigt, men fordi jeg trænger til at blære mig lidt.
Ud over at kalde store bogstaver for upper case og små for lower case, så findes der betegnelserne majuskler om de store bogstaver og minuskler om de små bogstaver. Et alfabet udelukkende med små bogstaver betegnes en minuskelskrift, f.eks. de karolingiske minuskler, der af samtiden ikke blev opfattet som noget specielt - ud over at det var en standardskrift, der var let at læse, men som gav ophav til vore dages små bogstaver. Store bogstaver kan også kaldes versaler. Det skyldtes en norm fra poesi, hvor de første bogstav i hver verselinje blev skrevet med en versal, resten af linjen blev skrevet med kursive minuskler. Ofte var der et mellemrum mellem den indledende versal og resten af lnjen. Af og til ser man stadig versaler brugt i poesi på en måde, der ikke svarer til ortodoks ortografi (dejligt udtryk jeg fandt på der).

Ditlev Petersen
Ditlev Petersen

Kom lige til at tænke på det her Tweet omkring upper og lower case, da jeg læste artiklen :-)

https://twitter.com/mrmrs_/status/866067646357352448


Det er langt fra alle sættekasser, der er delt i to adskilte kasser. Jeg har aldrig undersøgt det systematisk, men her i landet brugte (bruger) man sættekasser med både versaler og minuskler i samme kasse, dog således at versalerne ligger i øverste halvdel. Kasserne bliver større og tungere på den måde (alt andet lige). Jeg tror, de tyske lande gjorde ligeså, mens England sikkert har gjort som i Staterne.

Nikolaj Brinch Jørgensen

Spændende, underholdende læsning, MEN det havde været rart med mere stringens og nøjagtighed i teksten - den taber ved at være lige på, men aligevel ved siden af.

Det er jo indlysende, at skal en computer skelne mellem P og p, så må de nødvendigvis repræsenteres (gemmes) forskelligt - altså som Peter og pan, ikke som Peterpan.
Det er tilsvarende indlysende, at en række af de nævnte regler (længde af passwords, brug af mixed case, brug af tal, brug/ikke-brug af blankt tegn) er syntaksregler opfundet til lejligheden og måske af nød. I dag er disse regler stort set forsvundet og erstattet med krav om mangfoldighed og større længde (end 4/8 tegn).

Der savnes et afsnit om den teknologiske baggrund, som især handler om de begrænsninger der har hersket igennem tiderne.
Der var engang et it-tegnsystem som hed EBCDIC med 256 tegn, svarende til 8 bit. Her var en del tegn reserveret til "kontrol" og resten til tal-tegn og bogstav-tegn. (https://en.wikipedia.org/wiki/EBCDIC)De store bogstaver i udskrifterne var en teknologisk/økonomisk begrænsning i datidens printere (linieskrivere med en bogstavkæde).
Desværre blev systemet opfundet af analfabeter, næsten, som kun kendte det korte, engelske, alfabet. Derfor kom f.eks. fransk, dansk, svensk, norsk til kort: de særlige tegn var bare ikke med. Så kunne man snyde systemet på skærme og på printere ved at lade eet tegn (bitkombination) betyde forskelligt når det blev vist eller printet. F.eks.: $ og Å eller æ og ä.
Heldigvis fik det med PC-æraen en ende, idet der blev lavet en ny standardisering (code pages). Og derefter kan vi alle på en standard PC og standard printer skrive både engelske bogstaver og nationale tegn som üæøåÜÆØÅäöéèô og mange flere. Også andre sprog fik løsninger - nogle måtte benytte 32 bits (double byte) for at få tegn nok.
Så et PC-tastatur (og den bagvedliggende fortolkning) knyttes til et sprog (engelsk, fransk, dansk, svensk, tysk, ....) MEN med snedige kombinationstryk kan man skrive de andre sprog.
P.S.: Den bedste forklaring for en engelsk-talende nær-analfabet om betydningen af nationale tegn og accenter kan vises ved de fire ord (fransk): cote, côte, côté og cotè - som betyder fire forskellige ting.


Det er meget godt forsøgt, men EBCDIC findes stadigt, og har mange codepages (ligesom ASCII).
Jeg vil mene at ASCII som var samtidigt (begge 1963) var begrænsningen (det kommer før EBCDIC), da det var 7 bits.
EBCDIC er ikke en standard men IBM proprietært (BCD er ikke en standard), i modsætning til ASCII.
En del printere og andre devices benyttede ikke fulde 8 bits tegnsæt, men helt ned til 6 bit, hvilket yderligere begrænsede benyttelsen af specialtegn og små bogstaver.

Faglighed: 32 bits er 4 bytes (ikke double bytes - 1 byte == 8 bits) => https://en.wikipedia.org/wiki/DBCS

Torben Mogensen Blogger

Mens vi nu er ved store og små bogstaver, så er den traditionen for alfabetisk orden (ordbogsorden eller leksikografisk orden), at store og små bogstaver alfabetiseres ens bortset fra, at to ord, der er helt ens på nær kapitalisering, alfabetiseres sådan at det store bogstav kommer først. F.eks. kommer Hans før hans, men Hansen efter hans.

På computere er det naturlige at sortere efter tegnenes numeriske koder. Dermed kommer Zoo før abe, hvis man bruger ASCII eller deraf afledede tegnsæt (såsom ISO 8859-1 eller UTF8). Man kan mindske problemet ved at indkode alfabetet i rækkefølgen AaBbCc osv, men man får stadig Hansen efter hans. Så alfabetisk sortering kræver i reglen, at man først konvertere store bogstaver til små (eller omvendt), sorterer primært efter dette og sekundært efter den normale indkodning. Dermed er det kun ord, der er ens på nær kapitalisering, hvor kapitaliseringen betyder noget.

Men det virker kun for engelske ord uden accenter osv. Nationalspecifikke og accenterede bogstaver findes i de fleste indkodninger helt andre steder end de latinske bogstaver, og der er ofte forskellige regler for alfabetisering i forskellige lande. I Danmark sorteres aa i reglen som å (sådan at Aalborg kommer efter ål), og i England sorteres æ som ae, da det her er en ligatur (på linje med det franske œ) og ikke et adskilt bogstav.

Så alfabetisk sortering er alt andet end ligetil, og kræver nationalspecifikke funktioner.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder