Les caractères ASCII ont 4 octetss dans UTF-32, 2 dans UTF-16 et 1 dans UTF-8. Les caractères non-ASCII des jeux de caractères ISO Latin ont 4, 2 et 2 octetss dans ces codages. Les caractères courants Han (chinois) utilisent 3 octetss dans UTF-8 et 2 octetss (ou plus exactement 16 bits) dans UTF-16. Certains rares caractères Han utilisent 4 octetss dans UTF-16 et UTF-8.
Unicode permet de coder certains caractères de plusieurs manières. Par exemple, le caractère À peut être la caractère Unicode unique ‘Majuscule latine A avec accent grave’ ou deux caractères ‘Majuscule latine A suivi de l'accent grave combiné’. Unicode définit ces caractères comme séquences équivalentes canoniquement. Comme IBM® Netezza doit traiter ces deux séquences de manière identique, il n'autorise pas ces séquences équivalentes dans la base de données.
Dans les éditions précédentes, Netezza ne charge pas les données qui utilisent les caractères combinés. Par conséquent, Netezza ne prend pas en charge l'arabe, le thaï, l'urdu et l'hindi. La commande nzconvert accepte l'option -nfc qui permet de convertir une entrée UTF-8, -16, ou -32 dans le format NFC (Normalization Form C) en utilisant les routines ICU (International Components for Unicode). Netezza charge les données dans le format NFC.
Pour éviter toute ambiguïté, Unicode définit deux formes de normalisation : Normalization Form C (NFC) et Normalization Form D (NFD). (Pour une description, voir Unicode Standard Annex #15 sur http://www.unicode.org/reports/tr15/ pour la spécification.) NFD est essentiellement ‘Toujours décomposer’ et ‘Précomposer si possible’. Depuis l'édition 4.0.3, Netezza charge les données dans le format NFC.
En fait, Netezza prend en charge un surensemble abrégé de NFC, appelé NFC'. Le surensemble permet à Netezza de prendre en charge les caractères de décomposition de singleton également, car les conversions standard de certains codages de caractères existants génèrent parfois des singletons. Pour la description des singletons, voir l'annexe Norme Unicode 15.