SQL utf-8 eller utf-16?

[Gjest Slettet+9871234]

For tiden jobber jeg med PostgeSQL. Særlig er jeg opptatt av å bruke riktige datatyper. Dette gjelder blant annet når man jobber med internasjonale bokstaver, herunder norske, hvor jeg har forstått at det er sikrere å bruke nvarchar fremfor varchar som datatype selv om førstnevnte tar 2 byter og sistnevnet 1 byte. Med dagens store disker betyr ikke det så mye lenger.

 

Mens jeg har jobbet med datatyper i SQL kom jeg over denne siden om MS SQL server: http://msdn.microsof...y/ms143726.aspx

 

SQL Server provides data types such as nchar and nvarchar to store Unicode data. These data types encode text in a format called UTF-16. The Unicode Consortium allocates each character a unique codepoint, which is a value in the range 0x0000 to 0x10FFFF. The most frequently used characters have codepoint values that will fit into a 16-bit word in memory and on disk, but characters with codepoint values larger than 0xFFFF require two consecutive 16-bit words. These characters are called supplementary characters, and the two consecutive 16-bit words are called surrogate pairs.

 

Det er nytt for meg at der finnes et utf-16 format så jeg undersøkte litt ved å utføre følgende søk:

 

sql utf 16

 

og fikk mange treff. Så mine spørsmål er:

1. Brukes utf-16 fortrinnsvis av Microsoft?
   
2. Er det er fremtidig format?
   
3. Er det noen som bruker dette formatet?
   
4. Holder det å bruke utf-8 når man jobber med internasjonale (multilingual) siter?
   

Endret 13. mai 2013 av Slettet+9871234

[terjeelde]

For tiden jobber jeg med PostgeSQL. Særlig er jeg opptatt av å bruke riktige datatyper. Dette gjelder blant annet når man jobber med internasjonale bokstaver, herunder norske, hvor jeg har forstått at det er sikrere å bruke nvarchar fremfor varchar som datatype selv om førstnevnte tar 2 byter og sistnevnet 1 byte. Med dagens store disker betyr ikke det så mye lenger.

 

Long story, short version;

 

 

Om du ikke primært bruker tegn som trenger mer enn en byte i UTF-8 (f.eks kinesisk), så ville jeg foretrukket å bruke UTF-8 i databasen. Merk at med f.eks PostgreSQL, så kan du velge hvordan du vil prate med databasen uavhengig av hvordan ting er lagret i databasen, f.eks:

 

SET CLIENT_ENCODING TO 'utf-8';

 

Du kan også gjøre dette til default for en bruker, f.eks:

 

ALTER USER mumlefoo SET CLIENT_ENCODING TO 'utf-8';

 

Da vil bruker alltid kunne snakke UTF-8 med databasen, om brukeren ikke velger noe annet.

 

UTF-8 støtter det du tregner av tegn, og det er slik sett ikke noe problem å bruke det. Som du sier er disk billig, men på den annen side spiser man RAM også, og det får man aldri nok av.

 

UTF-8 holder til internasjonale multilingual siter, og det er stort sett liten grunn til å bruke noe annet. Vel så viktig er det å holde tunga rett i munnen på at det er UTF-8 som snakkes hele veien, og at det ikke "sniker seg inn" noe annet, f.eks ved browsere som er forvirret og sier de sender UTF-8, mens de sender noe annet, osv.

 

Det er mange som bruker UTF-16, uten at jeg noen gang helt har funnet ut hvorfor, jeg ser ingen god grunn til å bruke det.

 

For vestlig alfabet bruker man mer plass, men får ikke f.eks fordelene ved at man bruker konstant antall byte pr. tegn, siden både UTF-8 og UTF-16 bruker flere enn "vanlig" ved behov. Da ender man med å ha de samme ulempene som UTF-8, uten å få noen fordeler, men bruke dobbelt så stor plass.

 

Så lenge du bruker Unicode (UTF8, UTF16, UTF32, UCS-2. UCS-4 osv), så er du "trygg" når det gjelder å kunne representere internasjonale tegn, og biblioteket eller språket du bruker bør håndtere alle de møysommelige detaljene for deg på en betryggende måte.

 

Terje

[tomsi42]

Hvordan påvirker UTF-8 tiden databasen trenger å sortere data i forhold til UTF-16? Det kan vel også ha litt å si?

[terjeelde]

Med primært vestlig alfabet, så sleper man rundt på dobbelt så mye data om man bruker utf-16, sammenlignet med utf-8. Det kan fort ha en negativ innvirknig på sorteringshastighet, spesielt om det betyr man får mindre i minne, og må hente mer fra disk.

 

Det er mulig noen databaser vil kunne ha fordeler av utf-16, jeg kjenner ikke f.eks ms-sql like godt som jeg kjenner postgresql.

 

Problemet med minne vil nok gjelde der også. Det er kanskje ikke så farlig om man vet man har nok minne, men hvis man ser etter trygt standardvalg, så ville jeg likevel valgt utf-8. Rett og slett fordi evt. fordel på sorteringshastighet sansynligvis vil være prosenter, mens kostnaden av å måtte hente fra disk fort vil kunne ha mye større negativ effekt.

 

(merk; jeg er ikke ekspert på ms-sql, så om noen er det, hør på dem, ikke på meg).

[Gjest Slettet+9871234]

Takk for glimrende svar.

[tomsi42]

Jepp, glimrende svar fra terjeelde.

 

Jeg har ikke erfaring med ms-sql heller; det går i Oracle her på huset ...

[GeirGrusom]

UTF-8 begynner å enkode til to tegn fra og med Unicode karakter 0x80 (128). Alle karakterer over dette vil enklere kunne uttrykkes i UTF-16 (ettersom de krever flere bytes i UTF-8). Det vil altså si at alle tegnsett som ikke passer inn i US-ASCII vil være bedre å uttrykke i UTF-16. Norsk passer stort sett inn i ASCII, med kun æ, ø og å som unntak.

 

Derimot tegnsett som bruker mye aksenter, eller andre tegnsett vil ha en vesentlig fordel med UTF-16. Enklere å sortere og potensiet krever det mindre minne og lagringsplass.

 

Ref:

http://www.utf8-chartable.de/unicode-utf8-table.pl?utf8=oct&unicodeinhtml=dec&htmlent=1

http://en.wikipedia.org/wiki/UTF-8

 

Windows, Java og .NET bruker UTF-16 eller en variant internt.

[siDDis]

UTF-8 fungerer glimrande til vestlige språk, UTF-16 Fungerer glimrande til Japansk. Til dei forskjellige Kinesiske språka så vil dei fleste teikn uansett ta 4 bytes.

 

Det med henting av data frå disk, er ganske irrellevant for tekster. Då det minste på eldre hardisker du kan lese er 512 bytes, mens det normale idag begynner å bli 4096 bytes.

Det som troleg heller vil skje er at mengden ram som blir brukt i applikasjonen, vil aukast betrakteleg.

 

Applikasjonen din vil troleg bruke unicode, som lagrer tekst i utf-8 eller utf-16 format. Unicode støtter alle teikn. Så UTF-8 er eit trygt val.

[terjeelde]

Henting av en tekst fra disk er ikke noe problem.

 

Det jeg er mer opptatt av er hvor f.eks indeksene lever. Hvis de lever i RAM, så er alle fornøyd. Hvis de vokser seg for store til det, og man må til disk for å gjøre index-lookups, så har man gjerne en dårlig dag forran seg.

 

Konklusjonen blir vel at det finnes gode grunner til å bruke andre ting enn utf-8, men hvis du ikke vet om en slik grunn, så kjør utf-8?

 

Eksempler på gode grunner kan være hvis du primært vil bruke japansk (utf-16 passer bra), eller kinesisk (ucs-4).

 

Eller at språk (nevnte språk), eller os (windows) bruker utf-16 internt, og du vet du har nok minne til både indekser og datasett forøvrig.

 

Utf-8 vil i alle tilfelle kunne representere alle tegn, og database-grensesnittet vil gi deg det du ber om, ikke det som ligger i databasen, så problemer vil mer sansynlig være andre steder.

 

[Gjest Slettet+9871234]

Takker igjen.

 

Jeg ser videre på datatyper i PostgreSQL da det er den plattformen jeg bruker for tiden. Typen nvarchar finnes ikke i postgreSQL ser det ut til:

 

SQL defines two primary character types: character varying(n) and character(n), where n is a positive integer. Both of these types can store strings up to n characters (not bytes) in length. An attempt to store a longer string into a column of these types will result in an error, unless the excess characters are all spaces, in which case the string will be truncated to the maximum length. (This somewhat bizarre exception is required by the SQL standard.) If the string to be stored is shorter than the declared length, values of type character will be space-padded; values of type character varying will simply store the shorter string.

 

If one explicitly casts a value to character varying(n) or character(n), then an over-length value will be truncated to n characters without raising an error. (This too is required by the SQL standard.)

The notations varchar(n) and char(n) are aliases for character varying(n) and character(n), respectively. character without length specifier is equivalent to character(1). If character varying is used without length specifier, the type accepts strings of any size. The latter is a PostgreSQL extension.

In addition, PostgreSQL provides the text type, which stores strings of any length. Although the type text is not in the SQL standard, several other SQL database management systems have it as well.

Values of type character are physically padded with spaces to the specified width n, and are stored and displayed that way. However, the padding spaces are treated as semantically insignificant. Trailing spaces are disregarded when comparing two values of type character, and they will be removed when converting a character value to one of the other string types. Note that trailing spaces are semantically significant in character varying and text values, and when using pattern matching, e.g. LIKE, regular expressions.

http://www.postgresq...-character.html

 

Dersom man ikke bryr seg om portabilitet er det vel da sikrest å bruke tekst for for eksempel URL'er eller skal det gjøres som forklart

 

create table
nvctest (
utf8fld varchar(12)
);
insert into nvctest
select convert('PostgreSQL' using ascii_to_utf_8);
select * from nvctest;

 

i denne

 

http://stackoverflow...server-nvarchar

 

tråden?

 

Se også:

 

http://stackoverflow...mn-type-for-url

 

som sier noe om URL begrensninger i IE < IE 8.

 

The RFC for HTTP has no maximum length for a URL. Microsoft have an MSDN KB at support.microsoft.com/kb/q208427 that states max length is 2083 (at least for all IE up to IE8; no word on max length in IE8).

 

 

Sitter med en lærebok som skriver følgende:

 

Only som database systems implement CLOBs and BLOBs, and they can vary in the way they are implemented across systems; MySQL, for instance implements TEXT instead of CLOB.

 

HTML eller mer generelt XML dokumenter bør man vel lagre med XML typen:

 

http://www.oopschool...=302&p=340#p340

 

Binary Large Objects BLOBs er vel for å lagre videoer, bilder og lyd.?

 

Spørsmål:

 

Hvilken datatype ville dere brukt til å lagre:

1. URLer
   
2. XML dokumenter?
   
3. Binære data
   

gitt at PostgreSQL er databaseplattformen?

Endret 13. mai 2013 av Slettet+9871234

[terjeelde]

Vanligste for URLer er å lagre dem i varchar:

varchar( 1024 )

eller:

character varying( 1024 )

 

HTML tror jeg ikke du kan regne med å kunne lagre som XML, siden HTML ikke nødvendigvis følger XML-standarden.

 

Bilder og denslags pleier jeg å holde ute av databasen, og heller lagre dem i filsystemet. Vil du absolutt ha dem inn i databasen, så er nok BLOB riktig.

[Gjest Slettet+9871234]

Vanligste for URLer er å lagre dem i varchar:

varchar( 1024 )

eller:

character varying( 1024 )

1. Det kan vel bli for kort.
   
2. Mener jeg leste argumenter mot varchar.
   
3. Hva er argumentene mot TEXT for URLer?
   

Litt tvetydig dette her:

 

I'm pretty sure postgres varchar is the same as Oracle/Sybase/MSSQL nvarchar even though it is not explicit in the manual:

 

-------------------------------------------------------------------------------------------------------------------------------------------

 

All of our TEXT datatypes are multibyte-capable, provided you've installed PostgreSQL correctly.

This includes: TEXT (recommended) VARCHAR CHAR

Kilde: http://stackoverflow...server-nvarchar

 

Når det gjelder HTML - leste du det jeg skrev på min oppslagstavle (lenke i tråden ovenfor), jfr. eksempel 1. hvor XPath brukes på HTML data?

Endret 13. mai 2013 av Slettet+9871234

[Djn]

Som terjeelde sier: HTML er ikke XML - det er f.eks. en del tags man har ikke trenger å lukke, fordi det er åpenlyst når de slutter uansett (f.eks. td) .

 

Det finnes forsåvidt også XHTML, som er ment å være lovlig XML. Det ser ut som om HTML5 er fremtiden, så det er litt sekundært - og hvis det er kode fra andre du skal lagre, vil du kunne få problemer med å ikke kunne lagre XHTML som renderer riktig men ikke er teknisk korrekt. (Forsåvidt et incentiv til å fikse koden, men ...)

[terjeelde]

Når det gjelder HTML som XML, så spørs det hva du prøver å gjøre. Hvis du lager all HTMLen som skal inn, og trenger å bruke xpath, så for all del.

 

Normalt vil jeg si at hvis du er i situasjonen at du trenger xpath mot en SQL-database, så er det gode ods for at du heller burde strukturere data på en annen måte, eller bruke en NoSQL-løsning ved siden av SQL-databasen.

 

Text vs varchar, så er det litt spørsmål om smak og behag. Ingen stor ytelsesforskjell, men personlig liker jeg å være litt streng på hva som går inn i en database, for å spare meg for å måtte gjøre datavask senere.

 

Jeg vil ikke ha en 700MB-streng som URL, så jeg tillater det ikke. Synes det er bedre å spørre meg hva max bør være, doble det, og gi det som linit til varchar.

 

Gjerne sammen med en check-constraint som sjekker at strengen ser ut som en URL, ikke inneholder mellomrom, osv.

 

Dette blir kanskje mer smak og behag enn rett og galt. Jeg opplever at dette sparer meg for arbeid senere, men det trenger ikke være likt for deg, osv.

[GeirGrusom]

Er TEXT en standardisert datatype i SQL? MS SQL har fjernet TEXT fra SQL Server 2005 og nyere.

Men mulig jeg tar feil. Eneste referansen jeg klarte å finne på dette var herifra, og det faktum at MS fjernet typen fra MS SQL.

De bruker istedet varchar(max).

[tomsi42]

Jeg mener å huske at TEXT ikke er en standarisert type; og at det er ganske få databaser som støtter det.

[Gjest Slettet+9871234]

Som terjeelde sier: HTML er ikke XML - det er f.eks. en del tags man har ikke trenger å lukke, fordi det er åpenlyst når de slutter uansett (f.eks. td) .

Det vet jeg. Jeg kjenner til

• Vel-formete XML dokumenter
  
• Gyldige XML dokumenter.
  

Man kan med en viss rett si at HTML er en dårlig dialket av XML om man lukker alle tagger og validerer koden. Der er videre problemer med anførselstegn etc. For ytterligere inormasjon søk på:

 

xml OR XPath OR XLS OR XPath kgun site:www.sitepoint.com

 

hvor du finner ytterligere forklaring.

 

Det finnes forsåvidt også XHTML, som er ment å være lovlig XML. Det ser ut som om HTML5 er fremtiden, så det er litt sekundært - og hvis det er kode fra andre du skal lagre, vil du kunne få problemer med å ikke kunne lagre XHTML som renderer riktig men ikke er teknisk korrekt. (Forsåvidt et incentiv til å fikse koden, men ...)

 

Studerte du det eksemplet jeg viste til i min forrige post? Hvorfor bruker en SQL lærebokforfatter som kjenner ulike databaser og jobber med Oracle XML om HTML dokumenter?

 

Jfr. også overskriften "Converting SQL/XML Output to HTML".

 

For å unngå ytterligere begrunnesle fra min side, ber jeg deg om å lese denne posten:

 

XML and Json datatypes in PostgreSQL.

 

PostgreSQL er den databaseplattformen jeg kommer til å bruke.

 

P.S. En fordel med XML er også at man kan lage sitt eget språk.

Endret 13. mai 2013 av Slettet+9871234

[Gjest Slettet+9871234]

Jeg mener å huske at TEXT ikke er en standarisert type; og at det er ganske få databaser som støtter det.

 

Stemmer. MySQL og PostgreSQL støtter TEXT.

[terjeelde]

Å konvertere SQL/XML til HTML er trivielt. Å konvertere HTML til XML er noe helt annet, og gir vanligvis ingen andre resultater enn langvarig hodepine. (Med mindre det er ryddig HTML du har laget selv, og ingenting annet).

 

Men for all del, hvis det er hva du vil, så kjør på.

 

Vi prøvde ikke annet enn å si ifra om at dette kanskje ikke er rett vei å gå.

 

Ang. lage sitt eget språk i XML, så er nok det kjent for de fleste her. Man kan også lage sitt eget språk med f.eks. ASCII.

[Djn]

Korrekt XHTML er også alltid korrekt XML.

Korrekt HTML og XML er begge korrekt SGML, som er grunnen til at de ser nokså like ut.

Korrekt XHTML er korrekt HTML, enskjønt det er noen viktige forskjeller i parsingen (som, for å være artig, avhenger av MIME-typen det sendes med: XHTML sendt som text/html blir tolket som HTML)

Korrekt HTML kan, men må ikke (og ifølge standarden bør ikke) være lovlig XHTML.

Og selvfølgelig: Typisk HTML - og HTML som gir riktig-utseende resultater i alle browsere - behøver ikke være korrekt HTML (langt mindre XHTML). Det har det med å gi konverteringsforsøk en ekstra dimensjon av ubehag.

 

"Hvorfor bruker en SQL lærebokforfatter som kjenner ulike databaser og jobber med Oracle XML om HTML dokumenter?" Nei, si det? Det er konkret og beviselig feil, så jeg håper han mente XHTML og det bare gikk litt fort i svingene. Databaser er uansett et forskjellig felt fra markup-språk, så det kan jo også være han bare ikke tenkte over forskjellen.

 

At det er mulig å få XSLT til å produsere lovlig HTML er en bivirkning av at HTML har en del lovlige-men-ikke-anbefalte varianter som lar det overlappe med XHTML.

 

Og forøvrig mener jeg HTML5 burde ta opp i seg noen triks fra SGML - slik som <aside>dette</> , eller kanskje til og med <aside/dette/ .

Endret 13. mai 2013 av Djn