Unicode je průmyslový standard navržený tak, aby umožňoval konzistentní reprezentaci textu a symbolů ze všech jazyků a manipulaci s nimi v počítačích.
Znaky Unicode lze kódovat pomocí některého z několika schémat označovaných jako Unicode Transformation Formats (UTF).
Konsorcium Unicode si klade ambiciózní cíl nahradit stávající schémata kódování znaků systémem Unicode, protože mnohá stávající schémata jsou omezená co do velikosti a rozsahu a nejsou kompatibilní s vícejazyčnými prostředími. Jeho úspěch při sjednocování znakových sad vedl k jeho širokému a převažujícímu používání při internacionalizaci a lokalizaci počítačového softwaru. Standard byl implementován do mnoha nejnovějších technologií, včetně XML, programovacího jazyka Java a moderních operačních systémů.
Unicode má výslovně za cíl překonat omezení tradičních kódování znaků, jako jsou kódování definovaná normou ISO 8859, která jsou široce používána v různých zemích světa, ale zůstávají do značné míry vzájemně nekompatibilní. Mnohá tradiční kódování znaků mají společný problém v tom, že umožňují dvojjazyčné počítačové zpracování (obvykle s použitím římských znaků a místního jazyka), ale ne vícejazyčné počítačové zpracování (počítačové zpracování libovolných jazyků smíšených mezi sebou).
Unicode v podstatě kóduje základní znaky – grafémy a grafémům podobné jednotky – a nikoli varianty glyfů (ztvárnění) těchto znaků. V případě čínských znaků to někdy vede ke sporům o rozlišení základního znaku od jeho variantních glyfů (viz sjednocení Han).
Při zpracování textu Unicode zajišťuje pro každý znak jedinečný kódový bod – číslo, nikoli glyf. Jinými slovy, Unicode představuje znak abstraktním způsobem a vizuální ztvárnění (velikost, tvar, písmo nebo styl) přenechává jinému softwaru, například webovému prohlížeči nebo textovému procesoru. Tento jednoduchý cíl se však komplikuje ústupky, které tvůrci Unicode učinili v naději, že podpoří rychlejší přijetí Unicode.
Prvních 256 kódových bodů bylo vytvořeno shodně s obsahem normy ISO 8859-1, aby bylo možné triviálně převádět stávající západní text. Mnoho v podstatě stejných znaků bylo zakódováno vícekrát v různých kódových bodech, aby se zachovaly rozdíly používané ve starších kódováních a umožnil se tak převod z těchto kódování do Unicode (a zpět) bez ztráty informací. Například sekce kódových bodů „fullwidth forms“ zahrnuje celou latinku, která je oddělena od hlavní sekce latinky. V písmech CJK jsou tyto znaky vykreslovány ve stejné šířce jako ideografy CJK, nikoliv v poloviční šířce. Další příklady naleznete v části Duplicitní znaky v Unicode.
Standard Unicode obsahuje také řadu souvisejících položek, jako jsou vlastnosti znaků, formy normalizace textu a obousměrné pořadí zobrazení (pro správné zobrazení textu obsahujícího písmo zprava doleva, jako je arabština nebo hebrejština, a písmo zleva doprava).
Unicode pokrývá téměř všechna dnes používaná písma (systémy psaní), včetně:
V nejbližší době se neplánuje začlenění egyptských nebo mayských hieroglyfů.
Do již zakódovaných písem se přidávají další znaky a také symboly, zejména pro matematiku a hudbu (v podobě not a rytmických symbolů). V cestovní mapě Unicode jsou uvedena písma, která dosud nejsou v Unicode, s předběžným přiřazením ke kódovým blokům. Vynalezená písma, z nichž většina nesplňuje podmínky pro zařazení do Unicode z důvodu nedostatečného reálného používání, jsou uvedena v registru ConScript Unicode spolu s neoficiálními, ale široce používanými přiřazeními kódů pro oblast soukromého použití. Podobně je mnoho středověkých variant písmen a ligatur, které nejsou v Unicode, zakódováno v iniciativě Medieval Unicode Font Initiative.
V roce 1997 předložil Michael Everson návrh na kódování znaků fiktivního jazyka klingonština v rovině 1 normy ISO/IEC 10646-2. Konsorcium Unicode tento návrh v roce 2001 zamítlo jako „nevhodný pro kódování“ – ne kvůli nějaké technické nevhodnosti, ale proto, že uživatelé klingonštiny běžně čtou, píší a vyměňují si data v latinské transliteraci. Nyní, když někteří nadšenci blogují v tlhIngan pIqaD (klingonské abecedě) s využitím nově dostupných písem a rozložení klávesnice, se objevila možnost opětovného podání žádosti do ISO.
V roce 1993 bylo navrženo zařazení elfských písem Tengwar a Cirth z fiktivního prostředí Středozemě J. R. R. Tolkiena do roviny 1. Konsorcium návrh stáhlo, aby do něj zapracovalo změny navržené tolkienisty, a od roku 2005 se o něm stále uvažuje.
Klingonština i Tolkienovo písmo mají přiřazení v registru ConScript Unicode.
Standard Unicode vyvíjí konsorcium Unicode se sídlem v Kalifornii. Členem této organizace se může stát každá společnost nebo jednotlivec, který je ochoten platit členské příspěvky. Mezi členy patří prakticky všechny hlavní společnosti zabývající se počítačovým softwarem a hardwarem, které mají nějaký zájem na standardech pro zpracování textu, například Apple Computer, Microsoft, IBM, Xerox, HP, Adobe Systems a mnoho dalších.
Konsorcium poprvé vydalo Standard Unicode (ISBN 0321185781) v roce 1991 a na základě tohoto původního díla pokračuje ve vývoji standardů. Unicode se vyvíjel ve spolupráci s Mezinárodní organizací pro normalizaci a sdílí repertoár znaků s normou ISO/IEC 10646. Unicode a ISO/IEC 10646 fungují jako rovnocenná kódování znaků, ale norma The Unicode Standard obsahuje mnohem více informací pro implementátory a zabývá se – do hloubky – tématy, jako je bitové kódování, srovnávání a vykreslování. Standard Unicode vyjmenovává množství vlastností znaků, včetně těch, které jsou potřebné pro podporu obousměrného textu. Obě normy používají mírně odlišnou terminologii.
Skladování, přenos a zpracování
Unicode zatím slouží pouze jako prostředek k přiřazení jedinečného čísla každému znaku používanému ve světových psaných jazycích. Uchovávání těchto čísel při zpracování textu představuje jiné téma; problémy vyplývají ze skutečnosti, že většina softwaru napsaného v západním světě pracuje pouze s 8bitovými kódováními znaků, přičemž podpora Unicode se přidává jen pomalu v posledních letech. Podobně při reprezentaci asijských písem nemohou dvoubajtová kódování znaků ani z principu zakódovat více než 65 536 znaků a v praxi zvolené architektury kladou mnohem nižší limity. Takové limity nestačí pouze pro potřeby vědců zabývajících se čínským jazykem.
Unicode definuje dvě metody mapování:
Čísla v názvech kódování udávají počet bitů v jedné kódové hodnotě (u kódování UTF) nebo počet bajtů v jedné kódové hodnotě (u kódování UCS).
V UTF-32 a UCS-4 slouží jedna 32bitová kódová hodnota jako poměrně přímá reprezentace kódového bodu libovolného znaku (i když endianita, která se na různých platformách liší, ovlivňuje, jak se kódová hodnota skutečně projeví jako posloupnost bitů). V ostatních případech může být každý kódový bod reprezentován různým počtem kódových hodnot.
UTF-8 používá jeden až čtyři bajty na jeden kódový bod a vzhledem k tomu, že je relativně kompaktní (pro latinku) a kompatibilní s ASCII, představuje de facto standardní kódování pro výměnu textu Unicode. Používá se také ve většině nejnovějších linuxových distribucí jako přímá náhrada starších kódování při obecné práci s textem.
UTF-16, který má obvykle 16 bitů na kódový bod – stejně jako UCS-2 – ale někdy i 32, se používá v mnoha rozhraních API. Většinou je to z historických důvodů (pocházejí z dob, kdy byl Unicode založen na UCS-2, nebo z rozhraní s jinými API, která používají UTF-16). UTF-16 je standardní formát pro rozhraní API systému Windows (i když podpora náhradních kódů není ve výchozím nastavení povolena) a pro prostředí Java a .NET bytecode.
UCS-2 je zastaralé 16bitové kódování s pevnou šířkou, které pokrývá pouze základní multilinkuální rovinu. Pro znaky v základní vícejazyčné rovině jsou UCS-2 a UTF-16 shodné. Proto je lze považovat za různé implementační úrovně téhož kódování.
UCS-4 a UTF-32 se běžně nepoužívají, protože z 32 bitů přidělených na jeden kódový bod se nikdy nevyužije více než 21, ale stále častěji se v implementacích programovacích jazyků používá UCS-4 pro interní ukládání kódovaného textu.
Kódování UCS-2 a UTF-16 určují značku pořadí bajtů (BOM) Unicode pro použití na začátku textových souborů. Někteří vývojáři softwaru ji převzali i pro další kódování, včetně UTF-8, které označení pořadí bajtů nepotřebuje. V tomto případě se pokouší označit soubor jako obsahující text Unicode. BOM, kódový bod U+FEFF má důležitou vlastnost jednoznačnosti bez ohledu na použité kódování Unicode. Jednotky FE a FF se v UTF-8 nikdy nevyskytují; U+FFFE (výsledek záměny bajtů U+FEFF) se nerovná legálnímu znaku a U+FEFF vyjadřuje nulovou šířku mezery bez zlomu (znak bez vzhledu a bez jiného účinku než zabránění vzniku ligatur). Stejný znak převedený do UTF-8 se stane posloupností bajtů EF BB BF.
GB18030 je další kódovací forma pro Unicode, ale od čínské standardizační správy.
Ready-made versus složené postavy
Unicode obsahuje mechanismus pro úpravu tvaru znaků, který výrazně rozšiřuje repertoár podporovaných glyfů. To se týká i používání kombinovaných diakritických znamének. Ty se vkládají za hlavní znak (nad jeden znak lze naskládat několik kombinujících diakritických znamének). Z důvodu kompatibility však Unicode obsahuje také velké množství předkomponovaných znaků. V mnoha případech tak mají uživatelé k dispozici více způsobů kódování téhož znaku. Pro řešení této situace poskytuje Unicode mechanismus kanonické ekvivalence.
Podobná situace je i u jazyka hangul. Unicode poskytuje mechanismus pro skládání slabik Hangul pomocí Hangul Jamo. Poskytuje však také předkomponované slabiky Hangul (11 172).
Ideografy CJK mají v současné době kódy pouze pro svou předkomponovanou podobu. Přesto se většina těchto ideografů zjevně skládá z jednodušších prvků (radikálů), takže by je Unicode v zásadě mohl rozkládat stejně jako v případě hangul. Tím by se výrazně snížil počet potřebných kódových bodů a zároveň by bylo možné zobrazit prakticky všechny myslitelné ideografy (což by mohlo odstranit některé problémy způsobené sjednocením Han). Podobná myšlenka se týká i některých vstupních metod, například Cangjie a Wubi. Pokusy o tento způsob kódování znaků však narazily na skutečnost, že ideografy se ve skutečnosti nerozkládají tak jednoduše a pravidelně, jak by zřejmě měly.
V Unicode 3.0 byla k dispozici sada radikálů (radikály CJK v rozsahu U+2E80 až U+2EFF, radikály KangXi v rozsahu U+2F00 až U+2FDF a ideografické popisné znaky v rozsahu U+2FF0 až U+2FFB), ale standard Unicode (kap. 11.1 Unicode 4.1) varuje před používáním ideografických popisných sekvencí jako alternativní reprezentace dříve zakódovaných znaků:
Tento proces se liší od formálního kódování ideografu. Neexistuje žádný kanonický popis nekódovaných ideografů; popsaným ideografům není přiřazena žádná sémantika; pro popsané ideografy není definována žádná ekvivalence. Z konceptuálního hlediska se popisy ideografů podobají spíše anglické větě „an ‚e‘ with an acute accent on it“ než posloupnosti znaků .
Kombinování znaků, stejně jako složité tvarování písma, které je nutné pro správné vykreslení arabského textu a mnoha dalších písem, obvykle závisí na složitých technologiích písem, jako je OpenType (od společností Adobe a Microsoft), Graphite (od společnosti SIL International) a AAT (od společnosti Apple), pomocí kterých tvůrce písma do písma zahrne instrukce, které softwaru říkají, jak správně zobrazit různé sekvence znaků. Písma s pevnou šířkou někdy používají jinou metodu: umístění glyfu spojovacího znaku před jeho vlastní levý postranní znak; tato metoda však funguje pouze pro některá diakritická znaménka a ta se správně neskládají.
Od roku 2004 většina softwaru stále nedokáže spolehlivě zpracovat mnoho funkcí, které starší formáty písem nepodporují, takže kombinování znaků obecně nefunguje správně. Teoreticky mají znaky ḗ (předkomponované e s makronem a akutním přízvukem nad sebou) a ḗ (e následované kombinujícím makronem nad sebou a kombinujícím akutním přízvukem nad sebou) stejný vzhled, oba dávají e s makronem a akutním přízvukem, ale v praxi se jejich vzhled může v různých softwarových aplikacích značně lišit.
Také podtržítka, která jsou v indické romanizaci potřebná, jsou často umístěna nesprávně. Ukázka:
Takové problémy samozřejmě ve skutečnosti neukazují na slabiny samotného Unicode, ale pouze odhalují nedostatky v technologii vykreslování a písmech. Všimněte si také existence předkomponovaných glyfů pro mnoho znaků s diakritikou, např. ṃ – ṇ – ḷ.
Někteří lidé, hlavně v Japonsku, se staví proti Unicode obecně, přičemž se odvolávají na technická omezení a politické problémy v procesu. Lidé pracující na standardu Unicode považují taková tvrzení jednoduše za nepochopení standardu Unicode a procesu, kterým se vyvíjel. Nejčastější omyl podle tohoto názoru spočívá v záměně abstraktních znaků a jejich vysoce variabilních vizuálních podob (glyfů). Na druhou stranu, zatímco Číňané dokáží snadno přečíst většinu typů glyfů používaných Japonci nebo Korejci, Japonci často rozpoznají pouze určitou variantu.
Někteří označili Unicode za spiknutí proti asijským kulturám, kterého se dopouštějí lidé ze Západu, kteří nerozumějí znakům používaným v čínštině, korejštině a japonštině, a to navzdory tomu, že ve skupině ideografických zpravodajů (IRG) je většina odborníků ze všech tří zemí. IRG radí konsorciu a ISO v otázkách doplňování repertoáru a sjednocování han, tedy identifikace forem ve třech jazycích, které lze považovat za stylistické varianty téhož historického znaku. Unifikace han se stala jedním z nejkontroverznějších aspektů Unicode.
Unicode je kritizován za to, že nepovoluje starší a alternativní formy kandži, což prý komplikuje zpracování starých japonských a neobvyklých japonských jmen, ačkoli se řídí doporučeními japonských jazykovědců a japonské vlády. Bylo učiněno několik pokusů o vytvoření alternativy k Unicode. Patří mezi ně TRON (ačkoli v Japonsku není příliš rozšířen, někteří, zejména ti, kteří potřebují zpracovávat historický japonský text, jej upřednostňují) a UTF-2000. Je pravda, že mnoho starších forem nebylo do prvních verzí standardu Unicode zahrnuto, ale Unicode 4.0 obsahuje více než 90 000 znaků Han, což je mnohem více než jakýkoli slovník nebo jiný standard, a práce na přidávání znaků z rané literatury Číny, Koreje a Japonska pokračují.
Podpora thajštiny byla kritizována za nelogické řazení thajských znaků. Tato komplikace je způsobena tím, že Unicode zdědil thajský průmyslový standard 620, který fungoval stejným způsobem. Tento problém s řazením komplikuje proces srovnávání Unicode.
Odpůrci Unicode někdy i nyní tvrdí, že Unicode nezvládá více než 65 535 znaků, což je omezení, které bylo odstraněno v Unicode 2.0.
Na druhou stranu několik vlád, například indická vláda, projevilo o unicode velký zájem a indická vláda je hlasujícím členem konsorcia unicode.
Unicode se stal dominantním schématem pro interní zpracování a někdy i ukládání (i když mnoho textu je stále ukládáno ve starších kódováních) textu. První uživatelé měli tendenci používat UCS-2 a později přešli na UTF-16 (protože to byl nejméně rušivý způsob, jak přidat podporu pro jiné než bmp znaky). Nejznámějším takovým systémem je Windows NT (a jeho potomci Windows 2000 a Windows XP). Prostředí java a .net bytecode jej také používají.
UTF-8 (původně vyvinutý pro Plan 9) se stal hlavním kódováním ve většině operačních systémů podobných Unixu (i když některé knihovny používají i jiné), protože je relativně snadnou náhradou tradičních rozšířených znakových sad ascii.
Protokol MIME definuje dva různé mechanismy kódování znaků jiných než ASCII v e-mailu podle toho, zda se tyto znaky nacházejí v záhlaví e-mailu, například v položce „Předmět:“, nebo v textu zprávy. V obou případech je identifikována původní znaková sada a také kódování pro přenos. Pro e-mailový přenos Unicode se doporučuje znaková sada UTF-8 a přenosové kódování Base64. Podrobnosti obou různých mechanismů jsou specifikovány ve standardech MIME a uživatelům softwaru pro elektronickou poštu jsou zpravidla skryty.
Přijetí Unicode v elektronické poště bylo velmi pomalé. Většina východoasijského textu je stále kódována v lokálním kódování, jako je Shift-JIS, a mnoho běžně používaných e-mailových programů stále nedokáže správně zpracovat data Unicode, pokud je vůbec podporují. Neočekává se, že by se tato situace v dohledné době změnila.
Nejnovější webové prohlížeče zobrazují webové stránky pomocí Unicode, pokud je nainstalováno vhodné písmo (viz Unicode a HTML).
Přestože pravidla syntaxe mohou ovlivnit pořadí, v jakém se mohou znaky objevit, dokumenty HTML 4.0 i XML 1.0 z definice obsahují znaky z většiny kódových bodů Unicode, s výjimkou:
Tyto znaky se projevují buď přímo jako bajty podle kódování dokumentu, pokud je kódování podporuje, nebo je uživatelé mohou zapsat jako číselné odkazy na znaky založené na kódovém bodě Unicode, pokud kódování dokumentu podporuje číslice a symboly potřebné k zápisu odkazů (všechna kódování schválená pro použití na internetu je podporují). Například odkazy Δ, Й, ק, م, ๗, あ, 叶, 葉 a 냻 (nebo stejné číselné hodnoty vyjádřené v šestnáctkové soustavě, s předponou &#x) se v prohlížečích zobrazují jako Δ, Й, ק, م, ๗, あ, 叶, 葉 a 냻- pokud existují příslušná písma, tyto symboly vypadají jako velké řecké písmeno „Delta“, velké cyrilské písmeno „Krátké I“, hebrejské písmeno „Qof“, arabské písmeno „Meem“, thajská číslice 7, japonská hiragana „A“, zjednodušená čínština „Leaf“, tradiční čínština „Leaf“ a korejská slabika hangul „Nyaelh“.
Bezplatná a maloobchodní písma založená na Unicode se vyskytují běžně, protože nejprve TrueType a nyní OpenType podporují Unicode. Tyto formáty písem mapují kódové body Unicode na glyfy.
Je standardizováno několik podmnožin Unicode: Microsoft Windows od verze Windows NT 4.0 podporuje WGL-4 s 652 znaky, což je považováno za podporu všech jazyků založených na latince, řečtině a cyrilici. Mezi další normalizované podmnožiny Unicode patří MES-1 (335 znaků) a MES-2 (1062 znaků) (CWA 13873:2000, Multilingual European Subsets in ISO/IEC 10646-1).
Vykreslovací software, který nedokáže znak Unicode vhodně zpracovat, jej nejčastěji zobrazuje pouze jako otevřený obdélník nebo „náhradní znak“ Unicode (U+FFFD, �), který označuje pozici nerozpoznaného znaku. Některé systémy se pokusily poskytnout o takových znacích více informací. Písmo Apple LastResort zobrazí náhradní glyf označující rozsah znaku v Unicode a náhradní písmo SIL Unicode zobrazí rámeček s hexadecimální skalární hodnotou znaku.
Vícejazyčné motory pro vykreslování textu
Protože rozložení klávesnice nemůže obsahovat jednoduché kombinace kláves pro všechny znaky, nabízí několik operačních systémů alternativní metody zadávání, které umožňují přístup k celému repertoáru.
V systému Microsoft Windows (od systému Windows 2000) poskytuje program „Mapa znaků“ (Start/Programy/Příslušenství/Systémové nástroje/Mapa znaků) ovládací prvky pro bohaté úpravy textu pro všechny znaky tabulky I až po U+FFFF, a to výběrem z rozevírací tabulky za předpokladu, že je vybrán font Unicode. Programy, jako je Microsoft Word, mají podobné ovládání zabudované (Vložit/Symbol). Poněkud bolestivěji a tam, kde je znám kódový bod požadovaného znaku, je možné vytvářet znaky Unicode stisknutím kombinace kláves Alt + #, kde # představuje 0 následovanou desetinným kódovým bodem; například kombinace Alt + 0331 vytvoří znak Unicode ŋ. (Aby bylo # považováno za kódový bod Unicode, musí začínat číslicí 0 a musí být použity klávesy na numerickém bloku klávesnice). Tento postup funguje i v mnoha jiných aplikacích systému Windows, nikoli však v aplikacích, které používají standardní ovládací prvek pro úpravy systému Windows a nemají žádná zvláštní ustanovení umožňující tento typ vstupu. Viz kódy Alt. Chcete-li přidat znaky Unicode do názvů grafů v aplikaci Microsoft Excel, zadejte nejprve text názvu do buňky pracovního listu, kde lze použít ovládací prvek (Vložit/Symbol). Výsledný text lze vyjmout a vložit do názvů grafů.
Uživatelé počítačů Apple Macintosh mají v systémech Mac OS X a Mac OS 8.5 a novějších podobnou funkci s metodou zadávání nazvanou „Unicode Hex Input“: podržte klávesu Option a zadejte čtyřmístný šestimístný kód Unicode. Zadávání kódových bodů vyšších než U+FFFF se provádí zadáváním zástupných dvojic; software každou dvojici automaticky převede na jeden znak. Systém Mac OS X (verze 10.2 a novější) má také „paletu znaků“, která umožňuje uživatelům vizuálně vybrat libovolný znak Unicode z tabulky uspořádané číselně, podle bloku Unicode nebo podle dostupných znaků vybraného písma. Metoda „Hex zadávání Unicode“ musí být aktivována v Mezinárodních systémových předvolbách v systému Mac OS X nebo v ovládacím panelu „Klávesnice“ v systému Mac OS 8.5 a novějším. Po aktivaci musí být metoda „Unicode Hex Input“ vybrána také v nabídce Klávesnice (označené ikonou vlaječky), aby bylo možné zadat kódový bod Unicode.
Prostředí GNOME nabízí nástroj Mapa znaků (Aplikace/Příslušenství/Mapa znaků), který zobrazuje znaky seřazené podle bloku Unicode nebo podle systému zápisu a umožňuje vyhledávání podle názvu znaku nebo rozšířeného popisu. Pokud je kódový bod znaku znám, lze jej zadat podle normy ISO 14755: podržte stisknuté klávesy Ctrl a Shift a zadejte hexadecimální hodnotu Unicode.
Na úrovni vstupní metody X nebo vstupního modulu GTK+ poskytuje editor vstupní metody SCIM metodu zadávání „surového kódu“, která uživateli umožňuje zadat čtyřmístnou hexadecimální hodnotu Unicode.
Všechny aplikace X Window (včetně prostředí GNOME a KDE, ale nejen ty) podporují použití klávesy Compose Key. Na klávesnicích, které nativně neobsahují klávesu Compose, lze jako klávesu Compose nadefinovat libovolnou klávesu (např. CapsLock).
Konzola Linuxu umožňuje zadávat znaky Unicode podržením klávesy Alt a zadáním desetinného kódu na numerické klávesnici. (Aby to fungovalo, konzola by měla být uvedena do režimu Unicode pomocí unicode_start(1) a vhodného fontu vybraného pomocí setfont(8).)
Webový prohlížeč Opera ve verzi 7.5 a vyšší umožňuje uživatelům zadat jakýkoli znak Unicode přímo do textového pole zadáním jeho hexadecimálního kódu, jeho výběrem a stisknutím kláves Alt + x.
V textovém editoru Vim lze znaky Unicode zadávat stisknutím klávesy CTRL-V a následným zadáním kombinace kláves. Další informace získáte ve Vimu zadáním „:help i_CTRL-V_digit“. (Všimněte si, že zadaný text bude Unicode pouze v případě, že je aktuální kódování nastaveno na Unicode nebo příbuzný formát, jako je UTF-8; pro podrobnosti zadejte ve Vimu „:help encoding“). Mnoho znaků Unicode lze také zadávat pomocí digrafů; tabulku takových znaků a jim odpovídajících digrafů lze získat příkazem „:digraphs“ (opět za předpokladu, že je aktuální kódování nastaveno na Unicode).
K dispozici je několik vizuálních klávesnic, které velmi usnadňují zadávání znaků a symbolů Unicode.