Teckenuppsättningskodningar och lagringsstorleksfaktorer

Om du inte bara är intresserad av den maximala förändringen är ditt exempel inte korrekt.

AL32UTF8 är en teckenuppsättning med variabel längd. I allmänna termer kommer alla tecken som finns i US7ASCII-teckenuppsättningen att ta 1 byte, europeiska tecken kräver vanligtvis 2 byte, olika asiatiska språktecken kräver 3 byte, och en handfull mycket sällsynta tecken kräver 4 byte. Realistiskt sett, om du pratar om att konvertera faktiska WE8ISO8859P1-data till AL32UTF8, kommer du i praktiken att se en konverteringsfaktor mellan 1 och 2 som är mycket närmare 1 än 2. Utan att leta upp Unicode-mappningen för varje giltigt WE8ISO8859P1-tecken , Jag skulle bli förvånad om någon krävde 3 eller 4 byte lagringsutrymme i teckenuppsättningen AL32UTF8.

I Globalization Support Guide finns ett avsnitt om teckenuppsättningar som talar om för dig vilka teckenuppsättningar som är enbyte, vilka som är multibyte och vilka av multibyteteckenuppsättningarna som har fast bredd. Nästan alla multi-byte teckenuppsättningar har variabel bredd så faktorn du letar efter beror på dina data.

I de flesta fall är det bättre att deklarera att dina kolumner använder teckenlängdssemantik snarare än bytelängdssemantik ändå, vilket låter databasen ta reda på bakom kulisserna hur mycket data som ska allokeras. Till exempel om du deklarerar en kolumn

CREATE TABLE foo (
  col1 VARCHAR2(10 CHAR)
)

Oracle kommer att tilldela utrymme för 10 tecken lagring oavsett databasteckenuppsättning och oavsett det faktiska antalet byte som krävs för att lagra dessa data (med förbehåll för gränsen på 4000 byte per VARCHAR2 kolumn). Det gör i allmänhet att definiera kolumnstorlekar mycket enklare eftersom du inte behöver överdimensionera kolumnerna om någon bestämmer sig för att lägga 10 4-byte UTF-8-tecken på en rad och du inte behöver förklara för användarna att kolumnen kommer att acceptera strängar med olika antal tecken beroende på språket och/eller de specifika tecken som valts.

Även om Oracle-folk som hanterar globalisering regelbundet avråder från det , och föredrar att du uttryckligen anger teckenlängdssemantiken när du deklarerar dina kolumner eller åtminstone bara ställer in den på en sessionsnivå, kan du ställa in NLS_LENGTH_SEMANTICS initieringsparameter för att orsaka VARCHAR2(10) att använda teckenlängdssemantik istället för bytelängdssemantik som standard (du kan fortfarande ange VARCHAR2(10 BYTE) om du vill ha byte-längds semantik).