Bevezetés

Ezt az eszközt egy egyszerű okból készítettem. Minden alkalommal kézzel megoldani túl fárasztó volt.

Belső rendszerekből érkező CSV-k, Excelből készült CSV-k, valamint Linuxból, Windowsból vagy adatbázisból exportált konfigurációk. Ha az eredet változik, vele változik a kódolás, a soremelés és a BOM is.

  • UTF-8-ra számítasz, de Shift_JIS érkezik
  • LF-re számítasz, de CRLF jön
  • Egyes rendszerek BOM-mal stabilak, mások BOM-mal hibáznak

Az ellenőrzés és konverzió szemre, rutinból nem skálázható. Ezért készítettem olyan eszközt, amely bármilyen forrást fogad, és a célnak megfelelő kimenetet ad.

A valódi probléma nem egyetlen sérült fájl

Ha egy fájl sérül, általában menthető. A nehézség akkor jön, amikor egyszerre 10 vagy 100 fájl érkezik, eltérő forrásokból.

Ráadásul minden célrendszer mást tekint „helyesnek”.

  • A rendszer csak UTF-8-at fogad BOM nélkül
  • B rendszer UTF-8 + BOM mellett stabil
  • C rendszer Shift_JIS-re épül; UTF-8 olvasható, de importnál elhasal

Ilyenkor a „mindent UTF-8-ra” tanács nem segít. Biztonságos, ismételhető, célhoz igazított folyamat kell.

Mit akartam elérni ezzel az eszközzel

Három alapelv:

  1. Bármilyen forrás fogadása
  2. Konvertálás a célrendszer követelményei szerint
  3. Tömeges feldolgozásnál se nőjön az incidensek száma

Ez nem technikai mutatvány, hanem az üzemeltetési súrlódás csökkentése.

Az általam ténylegesen használt eljárás

1. Először a kimeneti specifikációt rögzítsd

Ne bemenetből indulj, hanem kimenetből. Rögzítsd ezt a három pontot:

  • Kódolás (UTF-8 / Shift_JIS stb.)
  • Soremelés (LF / CRLF)
  • BOM (van / nincs)

Ha ez bizonytalan, az eredmény kezelőnként eltér.

2. Oszd kisebb csomagokra a feldolgozást

Ne futtasd az egészet egyszerre. Rendszer, időszak vagy fájltípus szerint bontsd, és kis batch-csel kezdj.

Miért: hiba esetén vissza lehet állni. A teljes mennyiségű one-shot csak siker esetén gyors.

3. Rögzített feltételekkel futtasd a batch konverziót

A konvertálóban célonként rögzítsd a beállításokat. Futás közben ne módosítsd őket. A lényeg az ismételhetőség.

4. Ne csak vizuális ellenőrzés alapján dönts

„Megnyílik, tehát jó” sok incidens kiindulópontja. Legalább ezeket ellenőrizd:

  • Sorok száma megegyezik-e előtte/utána
  • CSV/TSV oszlopszám nem borult-e fel
  • � (helyettesítő karakter) nem nőtt-e
  • Kulcsoszlopok (ID/kód) hossza és karaktertípusa megmaradt-e

Ha nem megy át, ne induljon import.

A BOM nem hitkérdés, hanem partnerkövetelmény

A BOM-ról szóló vita üzemeltetésben ritkán hasznos. Csak az számít, hogyan dolgozza fel a másik rendszer.

  • Ha BOM-mal stabil, BOM-mal add ki
  • Ha BOM-mal hibázik, BOM nélkül add ki

Ne az „elméletileg helyes”, hanem a „másik oldalt nem törő” formátum legyen az első. Ez a gyakorlati üzemeltetés.

Az eszköz értéke nem maga a konverzió

A valódi érték két pontban van:

  • A döntés nem személyfüggő
  • Csökken az ismételt ellenőrzések költsége

A kódolási incidensek nem vihetők abszolút nullára. De ugyanazok az incidensek újrajátszása megállítható. Ezért készült ez az eszköz: bármit fogad, és felhasználási célnak megfelelően ad vissza.

Összegzés

Ez az eszköz nem idealista elméletből született. Azért született, hogy megszüntesse a terepen újra és újra előjövő, fárasztó kódolás-állítgatást.

Különböző eredetű fájlok fogadása, kódolás/soremelés/BOM igazítása a célhoz, majd egységes kimenet. Ennek az egy folyamatnak az automatizálása is sokat könnyít az üzemeltetésen.

A mojibake kezelése nem akaraterő-próba. Reprodukálható eljárássá kell tenni, amelyet bárki ugyanazzal az eredménnyel végrehajt. Csak ekkor mondható, hogy a tömeges mentés biztonságos.