UTF-32
Wikipedia
UTF-32 är en av varianterna av UTF (Unicode Transformation Format, eller UCS Transformation Format), det vill säga ett sätt att koda tecknen i Unicode. UTF-32 beskriver helt enkelt att varje tecken i Unicode kodas med ett 32 bitar långt binärt tal motsvarande tecknets positionsnummer i Unicode-standarden.
UTF-32 motsvarar det sätt att reprecentera tecknen i ISO-standarden ISO/IEC 10646 som där kallas UCS-4 (Universal Character Set, 4 oktetters representation). Benämningen UTF-32 används inte i ISO/IEC 10646.
Som intern kodning i program är kodningen direkt baserad på 32-bitars tal. Kodningen refereras då till som en CEF, Character Encoding Format. Huruvida dessa tal är representerade som "big-endian" eller "little-endian", är då en helt intern sak på låg nivå. I programmen behandlar man dem som 32-bitars tal.
Som extern kodning (filer, dataöverföring av text) måste man dock, som det heter, serialisera 32-bitars-talen till en följd av 8-bitars-tal, då all datakommunikation idag är baserad på oktetter (8-bitars bytes). Kodningen refereras då till som en CES, Character Encoding Scheme. (Eventuell ytterligare serialisering, till till exempel 4 bitar eller en bit i taget, plus extra bitar för felkorrigering, m.m. sker på lägre nivå.) Denna serialisering till oktetter kan vara antingen big-endian (mest signifikanta oktetten först), även kallad "network byte order", eller little-endian (minst signifikanta oktetten först).
Som extern kodning, och registrerade av IANA, är det därför två kodningar: UTF-32BE (big-endian) och UTF-32LE (little-endian). Big-endian är att föredra, då detta är den konventionella "network byte order", och formellt sett den oktettordning som ISO/IEC 10646 föreskriver. Unicode tillåter dock även formellt båda serialiseringarna. UTF-32 (utan BE eller LE) är även den registrerad som en charset av IANA. Det är då big-endian, men om "filen" (motsv.) börjar med en byte-ordningsindikation (BOM, byte order mark), så är det BOM som avgör vilken byte-serialisering som resten av filen har. BOM ingår då inte i text-innehållet i filen, och skall tas bort vid deserialisering. (Om oktetterna kommer i annan ordning, till exempel 1-3-2-4 eller 2-1-4-3, så är det att betrakta som direkt fel.)
UTF-32(BE|LE) kan i princip användas för webbsidor och andra filer, både lokalt och publiket. För e-post kan UTF-32 dock av olika skäl inte användas, utan då får man använda UTF-8 istället (tillsammans med ESMTP/8BITMIME).
UTF-32 betraktas allmänt som onödigt "slösaktigt", speciellt för stora filer, och även för intern bearbetning av strängar; det tar längre tid att överföra filen (även med komprimering under överföringen), och bearbetning i program kan leda till mer minneshantering och långsammare program. UTF-32 används därför mestadels internt i program och då nästan bara för enskilda tecken (efter som det finns tecken som har kodpositioner som är större än 0xFFFF), sällan för strängar. Eftersom tecken över 0xFFFF är sällan använda (t.ex. utdöda språk och ovanliga kinesiska tecken), tar många programvaruföretag sig friheten att bara stödja tecken upp till 0xFFFF, egentligen ska man använda UTF-16-algoritmen om man lagrar 16-bits-koder.