Úvod

Tento nástroj jsem vytvořil z jednoduchého důvodu. Ruční řešení pokaždé dokola bylo vyčerpávající.

CSV z interních systémů, CSV vzniklé z Excelu, konfigurační soubory z Linuxu, Windows nebo databází. Jakmile se změní původ, změní se i kódování, konce řádků a BOM.

  • Čekáte UTF-8, ale je to Shift_JIS
  • Čekáte LF, ale je to CRLF
  • Některé systémy BOM vyžadují, jiné se s BOM rozbijí

Kontrola a převod „od oka“ se nedá škálovat. Proto jsem udělal nástroj, který přijme libovolný původ a sjednotí výstup podle cílového importu.

Skutečný problém není jeden poškozený soubor

Když je rozbitý jeden soubor, dá se to obvykle zachránit. Těžké je, když najednou přijde 10 nebo 100 souborů z různých zdrojů.

Ještě horší je, že každý cílový systém má jinou definici „správně“.

  • Systém A přijímá pouze UTF-8 bez BOM
  • Systém B je stabilnější s UTF-8 s BOM
  • Systém C předpokládá Shift_JIS; UTF-8 vypadá čitelně, ale import selže

V takové situaci obecná rada „vše sjednoťte na UTF-8“ nepomůže. Je potřeba bezpečný a opakovatelný postup podle cíle.

Co měl tento nástroj vyřešit

Jen tři principy:

  1. Přijmout soubory z jakéhokoli původu
  2. Převést podle požadavků cíle
  3. Nezvyšovat incidenty ani při dávkovém zpracování

Není to demonstrace triků, ale nástroj pro snížení provozního tření.

Postup, který opravdu používám

1. Nejprve určit výstupní specifikaci

Nezačínat vstupem, ale výstupem. Zafixovat tyto tři body:

  • Kódování (UTF-8 / Shift_JIS apod.)
  • Konec řádku (LF / CRLF)
  • BOM (s / bez)

Pokud je to nejasné, výsledek se mění podle operátora.

2. Rozdělit cíle na malé dávky

Nespouštět vše najednou. Rozdělit podle systému, období nebo typu souboru, začít malými batchi.

Důvod: při selhání lze vrátit změny. Jednorázový běh nad celým objemem je rychlý jen při úspěchu.

3. Zafixovat podmínky a spustit hromadný převod

V nástroji pro převod nastavit pevné podmínky pro každý cíl. Během běhu nastavení neměnit. Klíčová je opakovatelnost.

4. Nehodnotit úspěch jen vizuálně

„Soubor se otevře, tedy je v pořádku“ je častý začátek incidentu. Minimálně ověřit:

  • Shodu počtu řádků před/po
  • Stabilitu počtu sloupců CSV/TSV
  • Že nepřibylo � (náhradní znak)
  • Zachování délky a typu znaků u klíčových sloupců (ID/kód)

Pokud kontrola neprojde, nepokračovat k importu.

BOM není ideologie, ale požadavek protistrany

Debata BOM vs. bez BOM má v praxi omezený význam. Rozhoduje jen to, jak soubor zpracuje cílový systém.

  • Pokud je systém stabilní s BOM, exportovat s BOM
  • Pokud s BOM selhává, exportovat bez BOM

Priorita není „teoreticky správný formát“, ale „formát, který protistranu nerozbije“. Tak vypadá reálný provoz.

Hodnota nástroje není samotný převod

Skutečná hodnota je ve dvou bodech:

  • Rozhodnutí nejsou závislá na konkrétním člověku
  • Snižují se opakované náklady na kontrolu

Incidenty s kódováním nelze dostat na absolutní nulu. Lze ale zastavit opakování stejných chyb. Proto jsem připravil nástroj, který přijme vše a vrátí výstup sjednocený podle účelu.

Závěr

Tento nástroj nevznikl z idealistické teorie. Vznikl proto, aby odstranil opakované a únavné ladění kódování v praxi.

Přijmout soubory z různých zdrojů, sjednotit kódování/konce řádků/BOM podle cíle a vrátit konzistentní výstup. Už samotná automatizace tohoto toku provoz výrazně zjednoduší.

Řešení mojibake není práce na „sílu vůle“. Musí to být reprodukovatelný postup, kde kdokoli dosáhne stejného výsledku. Teprve pak lze mluvit o bezpečné hromadné záchraně.