270 likes | 725 Views
Diakritiske tegn. Utfordringer ved bruk av diakritiske tegn i offentlige registre Morten Brekk Leder IT-Infrastruktur Brønnøysundregistrene mailto:morten.brekk@brreg.no 14.03.2005. Avgrensinger.
E N D
Diakritiske tegn Utfordringer ved bruk av diakritiske tegn i offentlige registre Morten Brekk Leder IT-Infrastruktur Brønnøysundregistrene mailto:morten.brekk@brreg.no 14.03.2005
Avgrensinger • Belyser utfordringer ved bruk av diakritiske tegn i offentlige registre og databaser, hvor gjenbruk og spredning av dataene i elektronisk form kan forventes. ------------------- • Belyser IKKE problemstillinger knyttet til bruk av diakritiske tegn i forbindelse med (statisk)informasjon eller i lokale registre/databaser uten elektronisk gjenbruk/spredning
Lovmessige føringer. • Adresser • Plikt til å bruke samiske stedsnavn, slik de er innført i stedsnavnregisteret (lov 18. mai 1990 nr 11 om stadnamn ) • Stedsnavnregisteret er underlagt Statens kartverk. Det er Norsk Eiendomsinformasjon som formidler opplysningene. • Samiske stedsnavn kan være: • Kun på samisk eller • Både på samisk og på norsk
Lovmessige føringer (forts.) • Personnavn • Plikt til å bruke samisk personnavn (fornavn, mellomnavn, etternavn) slik de fremgår av Folkeregisteret (lov av 7. juni 2002 nr 19 om personnavn) • Det avgis ikke tegn utenfor ISO8859-1 fra Folkeregisterets enedistributør (fra juli 2005), EDB Infobank pr. dato.
Lovmessige føringer (forts.) • Enhetens navn / foretaksnavn • Lov av 21. juni 1985 nr 79 om enerett til foretaksnavn og andre forretningskjennetegn mv. (foretaksnavneloven). • Enkeltpersonforetak skal inneholde innehaverens etternavn. Om navnet er samisk fremgår av Folkeregisteret, jf forrige side. • Kan være på samisk. Grense: foretaksnavn må som minimum bestå av en sammenstilling av tre bokstaver fra det norske alfabet. • Gjelder også for enheter som er registrert i Enhetsregisteret uten å være registrert i Foretaksregisteret.
Lovmessige føringer (forts.) • Kunngjøringer • Lov av 12. juni 1987 nr 56 om Sametinget og andre samiske rettsforhold (sameloven) § 3-2 annet ledd: kunngjøringer fra offentlige organ som særlig retter seg mot befolkningen i de samiske kommunene, skal skje både på samisk og norsk. • Kreditorvarsler (eks: fusjon, oppløsning, kapitalnedsettelse) som gjelder foretak med forretningssted i en av de samiske kommunene blir oversatt til samisk av de aktuelle lokalavisene i de samiske kommunene. • Andre typer kunngjøringer foretas kun på norsk
Praktiske hensyn • Ved ettspråklige samiske stedsnavn eller personnavn med samisk skrivemåte må følgende være sikret: • Saksbehandlere som registrerer eller avgir slike opplysninger må være i stand til å håndtere disse. • Tilknyttede registre og samarbeidende etater må være i stand til å håndtere slike opplysninger. Her kommer også Altinn-samarbeidet inn i bildet. • Kunder som etterspør opplysninger fra Brønnøysundregistrene eller andre offentlige registre må være i stand til å forstå/håndtere samiske adresseopplysninger. • Negative konsekvenser, dersom disse forutsetningene ikke er oppfylt, kan berøre den samiske befolkningen. • Tiltak for å ta i bruk nye tegn/tegnsett bør derfor ikke iverksettes før disse praktiske hensyn er ivaretatt.
Standard 8-bits tegnsett • Ingen sammenfallende 8-bits tegnsett for alle norske og samiske tegn ref: http://www.eki.ee/letter/ • Norsk er støttet av • ISO 8859-1, ISO 8859-9, ISO 8859-14, ISO 8859-15 • Samisk (Nordsamisk) er støttet av • ISO 8859-4, ISO 8859-10 • Ander Latin-baserte språk krever ? • ISO 8859-? • Hva med andre språk - personnavn fra andre alfabet ? • (Mulighet for å bruke CODEPAGE SAMI_WIN eller SAMI_MAC som dekker både norske og samiske tegn. Dette er ikke standardiserte tegnsett, og vil derfor by på problemer i samhandling med andre.)
Kan ISO 10646:2003 være en løsning? • ISO 10646 også kalt UNICODE beskriver totalt 1 110 064 tegn/tegnposisjoner. • Alle kjente skrifttegn + mye mer. • ISO 10646:2003 er standarden som beskriver tegnene • UNICODE (gjeldende versjon 4.0.1) beskriver en del tilleggfunksjonalitet, blant annet hvordan denne mengden tegn skal representeres digitalt. • UNICODE 4.1 er forventet å være klar i løpet av mars 2005
Unicode tegnfordeling 0-10FFFF16 Statement: Version 4.0 of Unicode Standard is code-for-code identical to ISO/IEC10646:2003 Alle tabeller ”lånt” fra Unicode Standard 4.0 vev-sider
UNICODE = Nye utfordringer • Man må velge representasjonsform – UTF (Unicode Tranformation Format) • UTF-8 – 8 bits representasjon hvor et tegn representeres med 1, 2, 3, eller 4 oktetter (bytes). • UTF-16 – 16 bits representasjon hvor et tegn representeres med en eller to grupper av 16 bits (2 bytes). • UTF-32 – 32 bits representasjon. Alle tegn beskrives med 32 bits (4 bytes). • UTF-16 og UTF-32 har to former hver: BE (Big-Endian) eller LE (Little-Endian) • Det finnes i tillegg EBCDIC-former av de overnevnte.
UTF-kodeformer BOM: Byte Order Mark angis først i dokumentet eller i en datautveksling
UTF-8 • A-Z og nummer med 1 byte • Alle diakritiske (latinske) tegn med 2 bytes, også Æ, Ø og Å • En del andre symbol, f.eks. € og™ krever 3 bytes • Tegn som krever 4 byte er neppe av betydning
UTF-8 fordeler • Kompakt lagring og transport av tekst • Kan håndteres som et 8-bits tegnsett (i programmeringsspråk) når man ser bort fra sortering og søk etter enkelttegn • Default representasjonsmåte i XML og stor utbredelse. • Håndteres av mange operativsystemer, databasesystemer og programmeringsspråk. • Tegnene 00-7F16 (ASCII-tegnene) er uendret – stor fordel for programmeringsspråk.
UTF-8 ulemper • Variabel lengde – feltlengden i databaser og programmer må økes og vil være større enn visningsfeltet. ( Årø – 3 tegn i visningsfeltet, 5 i databasen.) • Sorteringsrutiner må endres • Søk etter enkeltegn, i programmer, må erstattes med søk etter sekvenser av bytes.
UTF-16 • Alle diakritiske (latinske) tegn samt de fleste andre tegn som det er behov for å bruke er innenfor 16 bits representasjon. • Tegn som krever 2 x 16bits er neppe av betydning
UTF-16 fordeler • Relativt stor utbredelse • En del operativsystemer og databasesystemer har støtte for deler av UTF-16 (som de noe unøyaktig kaller støtte for Unicode) • De tegn som er aktuell å benytte vil finnes blant 16-bits tegnene og man kan anta at man har fast tegnlengde.
UTF-16 ulemper • Lagringsbehovet fordobles i forhold til 8-bits tegnsett som ISO 8859-1 • Millioner av programlinjer som forutsetter 8-bits tegnsett må skrives om. • Programkoden vil øke i omfang • Liten erfaring hos utviklere (i allefall ved Brønnøysundregistrene)
UTF-32 • Fordeler • Ensartet representasjon av alle tegn • Ulemper • 4-dobling av lagringsbehovet • Lite utbredd • Liten eller ingen støtte i operativsystem, databaser og programmeringsspråk.
Andre utfordringer med Unicode • Skrivere støtter kun samlinger av 8-bits tegnsett. Tekster må derfor pre-prosseseres før de skrives ut dersom de må ha tegn fra flere sett. • Tastaturløsninger er mangelfulle • Mange programmer i vanlig bruk støtter bare 8-bits tegnsett eller mindre deler av Unicode. • Skrifttyper med støtte for Unicode er lite utbredd.
Andre utfordringer med Unicode (forts.) • Data må lastes ut av databaser, konverteres, databasesystemene må rekonfigurerees og dataene lastes inn igjen. • Millioner av programmeringslinjer må endres og testes. • En del ny funksjonalitet må lages – blant annet endring i utskriftsystemer, • Hvordan skal de diakritiske tegnene være alfabetisk sortert - nye sorteringsrutiner må utvikles. • Hvordan skal brukere søke etter data – nye søkesystem må utvikles.
Datautveksling Kartverket (GAB) Brønnøysundregistrene Folkeregisteret Navn og addresse Stedsnavn Foretaksnavn Min Side Altinn Publikum næringsliv kommuner, fylker, etater
Datautveksling • Folkeregisteret, Kartverket og Brønnøysundregistrene – som ”eiere” av personnavn, stedsnavn og foretaksnavn - bør samkjøre sin overgang til en annen form å representere tegnene på. Dette for å kunne håndtere de diakritiske tegnene som er/vil være i bruk.
Datautveksling (forts.) • I en overgangsperiode – trolig langvarig – må disse etatene være i stand til å avgi data med minst 2 forskjellige representasjonsmåter. F.eks. UTF-8 og ISO 8859-1. • Det vil være uklokt å kreve at alle mottakere av data fra disse etatene skal håndtere nye tegnsett fra ”dag en”
Datautveksling (forts.) • Det må finnes standardiserte rutiner for oversettelse av tegn når disse ikke finnes i mottakene tegnsett. Dersom man ikke oversetter tegene når man konverterer fra f.eks. UTF-8 til ISO 8859-1 vil tegnene forsvinne eller gi feil i programkoden. • Kárášjohkakan bli til Krjohka (ikke helt korrekt da “á” finnes i ISO 8859-1 • Hva betyr et ord med oversatte tegn? ”Karasjohka” – har dette negative konsekvenser.
Hva med brukerne Er brukerne rustet til å håndtere diakritiske tegn de ikke kjenner, f.eks. mot Altinn og Min Side eller ellers i kontakt med det offentlige? Hvilke konsekvenser vil det få å ikke benytte rett tegn?
Konklusjon • Det er et omfattende arbeide vi står ovenfor. • Mangel på standardisering kan bli et problem. • Det må tas hensyn til brukerne av offentlige tjenester. • Det vil ta tid og koste (mange) penger. • Det kan/vil gå ut over andre oppgaver. • Samarbeide mellom ”dataeierne” må til. En arbeidsgruppe hvor disse er med bør opprettes.