Johdanto

Rakensin tämän työkalun yhdestä yksinkertaisesta syystä. Saman asian tekeminen käsin joka kerta oli liian työlästä.

Sisäisten järjestelmien CSV:t, Excelistä muunnetut CSV:t sekä Linuxin, Windowsin tai tietokantojen ulostulot. Kun lähde vaihtuu, myös merkistökoodaus, rivinvaihdot ja BOM vaihtelevat.

  • Luulit UTF-8:ksi, mutta se olikin Shift_JIS
  • Luulit LF:ksi, mutta se olikin CRLF
  • Osa järjestelmistä toimii vain BOM:n kanssa, osa hajoaa BOM:iin

Tarkistus ja muunnos pelkällä silmämäärällä ei skaalaudu. Siksi tein työkalun, joka ottaa vastaan tiedostot mistä tahansa lähteestä ja yhtenäistää ulostulon kohdejärjestelmän vaatimuksiin.

Todellinen ongelma ei ole yksi rikkoutunut tiedosto

Jos yksi tiedosto hajoaa, sen saa yleensä korjattua. Vaikea tilanne on, kun 10 tai 100 tiedostoa tulee yhtä aikaa eri lähteistä.

Lisäksi jokaisella kohdejärjestelmällä on oma käsitys “oikeasta” muodosta.

  • Järjestelmä A hyväksyy vain UTF-8 ilman BOM:ia
  • Järjestelmä B toimii vakaammin UTF-8 + BOM -muodossa
  • Järjestelmä C olettaa Shift_JIS:n; UTF-8 näyttää luettavalta, mutta tuonti epäonnistuu

Tällöin yleisohje “muunna kaikki UTF-8:aan” ei auta. Tarvitaan turvallinen ja toistettava toimintatapa kohteen mukaan.

Mitä tällä työkalulla halusin saavuttaa

Vain kolme periaatetta:

  1. Hyväksy tiedostot mistä tahansa lähteestä
  2. Muunna kohteen tuontivaatimusten mukaan
  3. Älä lisää virheitä edes eräajossa

Tämä ei ole muunnostekniikan esittely, vaan operatiivisen kitkan vähentämistä.

Menettely, jota käytän oikeasti

1. Päätä ensin ulostulon spesifikaatio

Aloita ulostulosta, älä syötteestä. Lukitse nämä kolme:

  • Koodaus (UTF-8 / Shift_JIS jne.)
  • Rivinvaihto (LF / CRLF)
  • BOM (on / ei)

Jos tämä jää epäselväksi, tulos vaihtuu tekijän mukaan.

2. Pilko käsiteltävä aineisto pieniin eriin

Älä aja kaikkea kerralla. Jaa järjestelmän, ajanjakson tai tiedostotyypin mukaan ja aloita pienillä erillä.

Syy: epäonnistumisessa rollback on mahdollinen. Koko volyymin one-shot on nopea vain onnistuessaan.

3. Lukitse ehdot ja aja erämuunnos

Merkkikoodausmuuntimessa aseta ehdot kohdekohtaisesti ja pidä ne samoina. Älä muuta asetuksia kesken ajon. Toistettavuus on olennaista.

4. Älä hyväksy tulosta pelkän silmäilyn perusteella

“Tiedosto aukeaa, siis ok” on monen virheen alku. Vähintään tarkista:

  • Rivimäärä ennen/jälkeen on sama
  • CSV/TSV-sarakemäärä ei rikkoudu
  • � (korvausmerkki) ei lisäänny
  • Avainsarakkeiden (ID/koodi) pituus ja merkkityyppi säilyvät

Jos tarkistus ei läpäise, älä etene tuontiin.

BOM ei ole ideologiaa, vaan vastapuolen vaatimus

Keskustelu BOM vai ei BOM on käytännössä usein hyödytöntä. Ratkaisevaa on, miten vastapuolen järjestelmä lukee tiedoston.

  • Jos vastapuoli on vakaa BOM:n kanssa, tuota BOM:n kanssa
  • Jos BOM rikkoo, tuota ilman BOM:ia

Aseta etusijalle “muoto, joka ei riko vastapuolta” eikä “teoreettisesti oikea muoto”. Näin operointi toimii.

Työkalun arvo ei ole itse muunnoksessa

Todellinen arvo on kahdessa asiassa:

  • Päätökset eivät riipu henkilöstä
  • Toistuvien tarkistusten kustannus pienenee

Koodausvirheitä ei voi nollata täysin. Mutta samojen virheiden toistamisen voi lopettaa. Siksi tein työkalun, joka ottaa kaiken vastaan ja palauttaa käyttötarkoitukseen sovitetun tuloksen.

Yhteenveto

Tätä työkalua ei tehty idealistisesta teoriasta. Se tehtiin poistamaan toistuva ja rasittava koodauksen säätö arjen työstä.

Vastaanota eri lähteistä tulevat tiedostot, sovita koodaus/rivinvaihto/BOM kohteeseen ja palauta yhtenäinen ulostulo. Pelkkä tämän virran automatisointi helpottaa operointia merkittävästi.

Mojibaken käsittely ei ole tahdonvoimakysymys. Se pitää muuttaa toistettavaksi prosessiksi, jolla kuka tahansa saa saman tuloksen. Vasta silloin voidaan puhua turvallisesta eräpelastuksesta.