Proč nepoužívat diakritiku v názvech souborů a IFC modelech

Diakritika v názvech souborů se může zdát jako maličkost, ale v praxi způsobuje řadu technických problémů - od nečitelných názvů přes ztracené soubory až po kompletně rozbitá data v IFC modelech.

Nejde o to, že by české znaky byly "špatné". Problém je v tom, že různé systémy je zpracovávají různě - a to vede k chaosu.

Problém #1: Kódování znaků (encoding)

Když vytvoříte soubor s názvem Výkres_přízemí.pdf, uloží se jako sekvence bajtů. Jenže které bajty?

• UTF-8: "ř" = 2 bajty (0xC5 0x99)
• Windows-1250: "ř" = 1 bajt (0xF8)
• ISO-8859-2: "ř" = 1 bajt (0xF8, ale jiný kontext)

Starší Windows systémy používaly Windows-1250. Moderní systémy UTF-8. Když soubor vytvořený v jednom kódování otevřete v systému s jiným výchozím kódováním, dostanete "Výkres_pøízemí" nebo "V�kres_p��zem�".

Reálný scénář: Projektant vytvoří soubory na novém Windows 11 notebooku (UTF-8). Pošle je kolegovi se starším Windows 10 (Windows-1250). Kolega vidí rozsypané znaky a soubor přejmenuje. Vznikají duplicity, zmatek ve verzích.

Problém #2: Normalizace Unicode (macOS vs Linux)

I když všichni používají UTF-8, macOS a Linux/Windows ukládají stejné znaky jinak:

• NFC (Linux, Windows): "ř" = jeden kódový bod U+0159
• NFD (macOS): "ř" = dva kódové body U+0072 (r) + U+030C (háček)

Oba zápisy vypadají stejně, ale jsou to různé sekvence bajtů. Verzovací systémy (Git, SVN) je vidí jako různé soubory.

Reálný scénář: Vývojář na macOS commitne soubor Řez_A-A.dwg. Kolega na Windows udělá pull a soubor se stáhne s jiným názvem. Git hlásí "untracked file" i když soubor existuje. Merge konflikty, ztracená práce.

Problém #3: URL encoding a webové služby

Když nahrajete soubor Schéma_rozvodu.pdf na webový server nebo do cloudového úložiště, URL musí být ASCII. Diakritika se zakóduje:

https://server.cz/files/Sch%C3%A9ma_rozvodu.pdf

Některé systémy kódují správně, jiné ne. Některé dekódují při zobrazení, jiné ne. Výsledek: nefunkční odkazy, 404 chyby, "soubor nenalezen".

Reálný scénář: CDE systém vygeneruje odkaz na soubor. Odkaz obsahuje špatně zakódovanou diakritiku. Odkaz nefunguje v emailovém klientu, který má jiný parser URL. Příjemce si myslí, že soubor neexistuje.

Problém #4: Konzole, scripty a automatizace

Příkazová řádka má vlastní kódování (chcp 852, chcp 65001...). Python script má své (# -*- coding: utf-8 -*-). Terminál má své. Když se neshodnou:

• Script spadne na FileNotFoundError
• Wildcard *.dwg přeskočí soubory s diakritikou
• Automatické zálohy vynechají "problémové" soubory

Reálný scénář: Noční backup script projde složku a zkopíruje všechny DWG soubory. Soubory s diakritikou v názvu se přeskočí (encoding mismatch). Nikdo si toho nevšimne, dokud se neztratí právě ten důležitý výkres.

Problém #5: ZIP archivy a komprese

ZIP formát má historicky problém s kódováním názvů souborů. Standard původně předpokládal CP437 (DOS), později přibylo UTF-8, ale podpora je nekonzistentní.

• Windows ZIP: může použít lokální kódování systému
• 7-Zip: UTF-8 ve výchozím nastavení
• macOS Archive Utility: vlastní implementace
• Linux unzip: hádá kódování

Reálný scénář: Architekt zabalí dokumentaci do ZIPu na Windows. Statik rozbalí na Linuxu. Polovina názvů je rozbitá. Musí ručně přejmenovávat desítky souborů.

Problém #6: IFC soubory - speciální případ

IFC STEP formát je textový soubor s přísným pravidlem: pouze ASCII znaky 32-126. Vše ostatní musí být escapováno:

• \S\ pro ISO 8859-1 rozšíření
• \X2\...\X0\ pro Unicode (UTF-16 hex)

"Přízemí" v IFC vypadá takto: P\X2\0159\X0\ízemí nebo horší varianty podle implementace exportéru.

Co se pokazí:

• Různé exportéry, různé výsledky: Revit, ArchiCAD, Tekla - každý escapuje jinak
• Špatná detekce v prohlížečích: BIMcollab, Solibri mohou zobrazit "P?ízemí" nebo "Prízemí"
• Selhání textového vyhledávání: Hledáte "přízemí", ale v IFC je "\X2\0159" - nenajdete nic
• Porovnání verzí: Dva identické modely s různým escapováním vypadají jako kompletně odlišné

Jak se tomu vyhnout

Pro názvy souborů (ISO 19650 konvence):

• Pouze a-z, A-Z, 0-9, - (pomlčka), _ (podtržítko)
• Žádné mezery - nahraďte podtržítkem nebo pomlčkou
• Žádná diakritika - "ř" → "r", "ž" → "z", "č" → "c"
• Krátké názvy - max 50-80 znaků včetně cesty

Pro IFC vlastnosti a názvy:

• Anglické názvy vlastností (mezinárodní standard)
• České popisy v dokumentaci/bSDD, ne v datech
• Konzistentní konvence napříč projekty

FAQ: Časté námitky

"Ale já mám Windows 11 a UTF-8, vše funguje!"

Ano, na vašem počítači. Co váš subdodavatel se starším systémem? Co zákazník v Německu? Co archiv za 10 let?

"Tak ať si všichni updatují systémy!"

Realita stavebnictví: Na projektu spolupracuje 20 firem. Každá má jiné IT, jiné systémy, jiné politiky. Nemáte kontrolu nad jejich prostředím.

"ISO 19650 říká, že můžu použít národní znaky!"

ISO 19650 doporučuje omezit se na základní ASCII právě kvůli interoperabilitě. Národní znaky jsou povoleny tam, kde je zajištěna konzistence - což v praxi znamená nikdy.

Proč o tom píšu

Negrafické informace v BIM modelech jsou to, co z 3D modelu dělá skutečný informační model. A právě práce s těmito daty - jejich pojmenování, struktura, výměna - je v České republice uchopená mizerně.

Řekněme si to na rovinu. Místo toho, abychom přejali mezinárodní standardy a best practices, vymýšlíme vlastní české cesty, které nikam nevedou.

Diakritika v názvech souborů je jen symptom většího problému: ignorujeme, že BIM je mezinárodní standard, a snažíme se ho "počeštit". Výsledek? Projekty, které nejdou otevřít, data, která nejdou přenést, a hodiny strávené řešením problémů, které by nemusely existovat.

Mezinárodní firmy to dělají jednoduše: ASCII názvy, anglické property sety, čisté IFC. My tady bojujeme s háčky a čárkami místo toho, abychom projektovali.