Power Query: 20 wzorców czyszczenia danych tekstowych (diakrytyki, spacje, OCR, kody produktów)

1. Wprowadzenie: po co czyszczenie tekstu w Power Query i jak podejść do wzorców

Dane tekstowe rzadko trafiają do raportu w stanie „gotowym do analizy”. Nawet jeśli wyglądają poprawnie na pierwszy rzut oka, często zawierają drobne niespójności: nadmiarowe spacje, znaki niewidoczne, różne warianty zapisu tego samego pojęcia, mieszane separatory czy błędy powstałe podczas kopiowania, importu i rozpoznawania tekstu. Efekt jest praktyczny i kosztowny: te same wartości nie łączą się w relacjach, wyszukiwanie zwraca niepełne wyniki, grupowania rozbijają się na wiele „prawie takich samych” kategorii, a reguły walidacji przepuszczają śmieci lub blokują poprawne rekordy.

Power Query jest naturalnym miejscem do czyszczenia tekstu, bo działa na etapie przygotowania danych: zanim trafią do modelu, raportu lub dalszych obliczeń. Dzięki temu porządki są:

• powtarzalne – te same kroki wykonują się automatycznie przy każdym odświeżeniu,
• audytowalne – widać, jakie transformacje zostały zastosowane i w jakiej kolejności,
• skalowalne – można je stosować do wielu kolumn i źródeł, nie tylko do pojedynczego arkusza,
• bezpieczniejsze – czyszczenie dzieje się w warstwie ETL, zamiast ręcznych poprawek w plikach źródłowych.

W praktyce czyszczenie tekstu to nie „jedna magiczna funkcja”, tylko zestaw powtarzalnych wzorców (patterns). Wzorzec to mała, przewidywalna operacja, którą da się wielokrotnie zastosować w różnych miejscach, np. ujednolicenie białych znaków, normalizacja zapisu, sprowadzanie znaków do jednego alfabetu czy usuwanie „opakowań” typu nawiasy i cudzysłowy. Myślenie wzorcami pomaga uniknąć dwóch skrajności: zbyt agresywnego czyszczenia (utrata informacji) oraz zbyt ostrożnego (brak efektu i dalsze problemy w analizie).

Żeby podejść do tematu metodycznie, warto rozdzielić cele czyszczenia na kilka typowych zastosowań:

• łączenie i dopasowanie – gdy tekst ma być kluczem do merge, relacji lub porównywania rekordów,
• kategoryzacja – gdy tekst ma być podstawą grupowania, segmentacji lub etykiet,
• wyszukiwanie i filtrowanie – gdy użytkownicy mają znajdować wartości po fragmencie nazwy,
• walidacja – gdy tekst powinien spełniać format (np. kod, identyfikator, wariant produktu),
• przygotowanie do ekstrakcji – gdy z opisu trzeba wydobyć elementy strukturalne (np. symbol, rozmiar, numer).

Każdy z tych celów wymaga innej „siły” czyszczenia. Przykładowo, to co jest dobre dla kluczy (maksymalna spójność) może być złe dla opisów (ryzyko utraty niuansów). Dlatego przed wdrożeniem reguł warto zdecydować, czy dana kolumna ma pełnić rolę identyfikatora, nazwy do prezentacji, czy pola pomocniczego do wyszukiwania i dopasowań. Częstą praktyką jest utrzymywanie dwóch wersji: „oryginału” oraz wersji „oczyszczonej” do łączenia i porównań.

Drugim filarem podejścia wzorcowego jest kolejność działań. Najpierw zwykle usuwa się przeszkody techniczne (niewidoczne znaki, niespójne odstępy), potem ujednolica zapis, a dopiero na końcu stosuje reguły specyficzne dla domeny (np. kody produktów, typowe pomyłki OCR). Taka hierarchia minimalizuje konflikty między regułami i ułatwia diagnozę, gdy wynik nie jest zgodny z oczekiwaniami.

Wreszcie, skuteczne czyszczenie tekstu opiera się na obserwacji danych: sprawdzaniu najczęstszych wariantów, identyfikowaniu „ogonków” (rzadkich anomalii) i testowaniu na próbkach z różnych źródeł. Zamiast pisać jedną długą, kruchą transformację, lepiej budować zestaw krótkich, czytelnych kroków, które odpowiadają konkretnym wzorcom i dają się łatwo utrzymać, gdy zmieni się źródło lub pojawią się nowe wyjątki.

2. Podstawowe porządki: Trim/Clean, usuwanie znaków niedrukowalnych i normalizacja białych znaków

Najwięcej „cichych” błędów w danych tekstowych nie wynika z literówek, tylko z niewidocznych znaków: spacji na końcu, twardych spacji, znaków końca wiersza wklejonych z PDF, tabulatorów czy znaków sterujących. W Power Query warto zacząć od uporządkowania właśnie tego poziomu, bo dopiero na czystej bazie sensownie działają późniejsze operacje: łączenie kolumn, dopasowania, grupowanie, usuwanie duplikatów i wyszukiwanie wartości.

Ten wpis powstał w odpowiedzi na zagadnienia, które regularnie pojawiają się na szkoleniach prowadzonych przez Cognity — bo w praktyce to właśnie „niewidoczne” znaki najczęściej psują dopasowania i automatyzację.

W praktyce te podstawowe porządki dotyczą trzech obszarów: (1) usunięcia zbędnych spacji z początku i końca, (2) pozbycia się znaków niedrukowalnych/sterujących, oraz (3) ujednolicenia wszystkich odmian „białych znaków” do jednego, przewidywalnego standardu.

Trim: usuwa nadmiar na brzegach, ale nie rozwiązuje wszystkiego

Trim jest najprostszym krokiem: usuwa białe znaki z początku i końca tekstu. To często wystarcza, by „ABC” i „ABC ” przestały być traktowane jako różne wartości. Trzeba jednak pamiętać, że Trim nie naprawia sytuacji typu „A  B” (podwójne spacje w środku), ani nie zawsze poradzi sobie z mniej oczywistymi separatorami, np. twardą spacją wklejoną z dokumentu.

Clean: usuwa znaki sterujące, które psują porównania i eksport

Clean koncentruje się na znakach niedrukowalnych, takich jak różne kody sterujące, niewidoczne separatory czy „śmieci” powstałe przy kopiowaniu z systemów źródłowych. Typowe objawy ich obecności to:

• wartości, które wyglądają identycznie, ale nie chcą się dopasować w scalaniu lub filtrowaniu,
• nieoczekiwane łamanie wiersza w środku komórki,
• problemy przy eksporcie do CSV lub ładowaniu do modelu danych,
• zaskakujące wyniki sortowania (np. pusty znak na początku).

Clean bywa niezbędny, gdy dane pochodzą z plików PDF, raportów, zrzutów ekranów lub integracji, które przenoszą do tekstu znaki techniczne.

Normalizacja białych znaków: jedna reguła zamiast wielu wyjątków

Nawet po Trim i Clean tekst może zawierać różne odmiany białych znaków: zwykłe spacje, twarde spacje, tabulatory, wielokrotne odstępy, znaki nowej linii. Dlatego kolejnym bazowym wzorcem jest normalizacja białych znaków, czyli sprowadzenie ich do jednej konwencji, np.:

• zamiana tabulatorów i łamań wiersza na pojedynczą spację,
• redukcja wielu spacji do jednej (kolaps),
• użycie jednolitego separatora w miejscach, gdzie dane były „porozrywane” przez formatowanie,
• opcjonalne usunięcie wszystkich spacji w polach, w których spacje nie mają znaczenia (np. niektóre identyfikatory).

Kluczowa korzyść: tekst staje się przewidywalny, więc te same wartości przestają „rozjeżdżać się” przez formatowanie i łatwiej je porównywać oraz łączyć.

Kolejność działań: najpierw higiena, potem logika

W podstawowym porządku często sprawdza się podejście: najpierw usunięcie znaków sterujących, potem uporządkowanie białych znaków, a na końcu przycięcie brzegów. Dzięki temu najpierw znikają ukryte znaki, potem stabilizują się separatory, a dopiero później „docinane” są końcówki. To ogranicza ryzyko, że w danych zostaną resztki niewidocznych znaków, które nadal będą powodować fałszywe różnice.

Na co uważać w podstawowym czyszczeniu

• Znaczące spacje: w niektórych polach spacja może być częścią sensownej wartości (np. opis), więc warto rozróżniać kolumny „identyfikacyjne” od „opisowych”.
• Łamanie wiersza jako separator: czasem znak nowej linii nie jest błędem, tylko ukrytym separatorem (np. lista w jednej komórce). Zanim go usuniesz, upewnij się, czy nie trzeba go najpierw zastąpić kontrolowanym znakiem.
• Różne „puste” wartości: tekst może wyglądać na pusty, ale zawierać spację lub znak niedrukowalny. Po normalizacji łatwiej zamienić takie przypadki na prawdziwe puste wartości.

Te trzy proste wzorce (Trim, Clean i normalizacja białych znaków) są fundamentem: nie zmieniają znaczenia tekstu, ale usuwają techniczny „szum”, który najczęściej blokuje poprawne dopasowania i automatyzację w Power Query.

3. Standaryzacja zapisu: wielkość liter, interpunkcja, separatory i ujednolicenie formatów

Po wstępnym „odszumieniu” tekstu kolejnym krokiem jest standaryzacja zapisu: tak, aby te same wartości wyglądały identycznie niezależnie od źródła (CSV, ERP, formularz, skan, ręczne wpisy). W Power Query celem nie jest „upiększanie” danych, tylko zmniejszenie liczby wariantów zapisu, co poprawia dopasowania, grupowanie, łączenia (merge) i walidację.

Co najczęściej standaryzujemy

• Wielkość liter (np. wszystko wielkimi, wszystko małymi, „Proper case” dla nazw).
• Interpunkcję (kropki, przecinki, myślniki, ukośniki) i jej konsekwentne stosowanie.
• Separatory w kodach i identyfikatorach (np. „AB-123”, „AB 123”, „AB/123” → jeden standard).
• Ujednolicenie formatów (np. skróty jednostek, zapisy „nr”, „No.”, „#”; różne warianty zapisu numerów/oznaczeń).

Wielkość liter: kiedy i jaką strategię wybrać

Zmiana wielkości liter w Power Query jest prosta, ale wybór strategii powinien wynikać z użycia danych:

• Klucze, kody, identyfikatory: najczęściej UPPER (łatwiejsze porównania, mniej wariantów).
• E-maile, loginy: często lowercase (praktyka systemowa), o ile nie tracisz informacji.
• Nazwy własne: czasem Proper case, ale ostrożnie (akronimy, skróty i człony typu „Sp. z o.o.” mogą wyglądać nienaturalnie po automatycznej zmianie).

Interpunkcja: mniej wariantów = mniej problemów

Interpunkcja bywa „kosmetyczna”, ale w danych tekstowych powoduje realne rozjazdy: „A-1” ≠ „A.1” ≠ „A 1”. Zwykle wybiera się jeden zestaw znaków dozwolonych i zastępuje resztę. Najczęstsze decyzje standaryzacyjne:

• Ujednolicenie myślnika (różne typy myślników z Unicode) do „-”.
• Konsekwencja w kropkach w skrótach (np. zawsze bez kropek: „dr”, „mgr”, „nr”).
• Zamiana przecinków/kropek w opisach do jednego stylu, jeśli dane mają być porównywane tekstowo.
• Usuwanie „ozdobników” typu wielokropek, powtarzane wykrzykniki, przypadkowe średniki.

Separatory: standaryzacja kodów i oznaczeń

Separatory (spacja, myślnik, ukośnik, podkreślenie) są kluczowe w kodach produktów, numerach dokumentów i oznaczeniach partii. Dobrą praktyką jest:

• Wybranie jednego separatora (np. „-”) i zastąpienie pozostałych.
• Ograniczenie wielokrotnych separatorów (np. „A--001” → „A-001”).
• Ujednolicenie odstępów wokół separatora (np. „A - 001” → „A-001”).

Ujednolicenie formatów: słowniki skrótów i konsekwencja zapisu

W wielu zestawach danych problemem nie są literówki, tylko różne poprawne formy tej samej informacji: „nr”, „numer”, „No”, „#”; „szt.”, „szt”, „pcs”. Standaryzacja polega na tym, by przyjąć kanoniczny zapis i mapować do niego warianty. Na tym etapie warto myśleć kategoriami:

• Synonimy (różne słowa/skróty → jeden zapis).
• Konwencje (np. czy zapisujesz „VAT ID”, „NIP”, czy zawsze jedną etykietę).
• Porządek składni (np. najpierw prefiks, potem liczba: „FV-2024-001”).

Najczęstsze funkcje Power Query przy standaryzacji

W praktyce standaryzacja bazuje na prostych transformacjach tekstu. Najczęściej używane elementy M to:

• Text.Upper, Text.Lower, Text.Proper – wielkość liter.
• Text.Replace, Text.ReplaceRange – zamiany znaków i wzorców.
• Text.Combine, Text.Split – gdy standaryzacja wymaga pracy na segmentach.

// Przykład: ujednolicenie separatorów i wielkości liter w kolumnie [Kod]
let
    Src = #table({"Kod"}, {{"ab 001"}, {"AB/001"}, {"Ab-001"}}),
    Std = Table.TransformColumns(
        Src,
        {"Kod", each Text.Upper(Text.Replace(Text.Replace(_, "/", "-"), " ", "-")), type text}
    )
in
    Std

Powyższy przykład pokazuje ideę: wybierasz jeden standard i sprowadzasz do niego warianty. W zależności od danych zamiany mogą dotyczyć też kropek, podkreśleń czy niestandardowych znaków myślnika.

Pułapki: kiedy standaryzacja może zepsuć dane

• Znacząca wielkość liter: w niektórych systemach „Aa” i „AA” mogą oznaczać różne rzeczy.
• Interpunkcja jako informacja: np. „A-1” vs „A1” mogą być innymi kodami, jeśli separator ma znaczenie biznesowe.
• Proper case na danych mieszanych: skróty i akronimy (np. „USA”, „R&D”) mogą zostać zniekształcone.

Dlatego standaryzację najlepiej oprzeć o proste reguły i jasny „kanon” zapisu, a wszelkie wyjątki traktować jako świadome odstępstwa (np. osobne reguły dla kodów, osobne dla nazw i opisów).

4. Diakrytyki i transliteracja: usuwanie/normalizacja polskich znaków oraz wariantów Unicode

Tekst z polskimi znakami bywa niespójny nie tylko przez „brak ogonków”, ale też przez różne warianty Unicode tego samego znaku (np. litera z akcentem jako jeden znak vs litera + znak łączący). W Power Query problem widać szczególnie przy łączeniu danych z wielu źródeł, porównywaniu wartości, wyszukiwaniu, deduplikacji oraz budowaniu kluczy (np. do mapowań lub indeksów). Doświadczenie Cognity pokazuje, że rozwiązanie tego problemu przynosi szybkie i zauważalne efekty w codziennej pracy – zwłaszcza gdy dane pochodzą z kilku systemów i mają być ze sobą bezbłędnie porównywane.

W tej sekcji rozróżniamy dwa podejścia:

• Normalizacja – sprowadzenie tekstu do jednolitej reprezentacji Unicode (bez zmiany „sensu” zapisu, nadal z diakrytykami), aby porównania i transformacje były przewidywalne.
• Transliteracja / usunięcie diakrytyków – zamiana „ą→a”, „ł→l” itd., gdy potrzebujesz wersji uproszczonej (np. do identyfikatorów, systemów bez wsparcia dla znaków narodowych, adresów URL, niektórych integracji).

Dlaczego „ten sam” znak potrafi być inny?

Unicode dopuszcza różne sposoby zapisu znaków diakrytycznych. Najczęstszy problem to znaki prekomponowane (pojedynczy znak) vs kombinacja (litera podstawowa + znak łączący). Wizualnie wyglądają identycznie, ale mogą mieć inną długość i nie przechodzić prostego porównania tekstowego. To potrafi psuć dopasowania (merge) i deduplikację.

Polska transliteracja: najczęstsze mapowania

Jeśli potrzebujesz wersji „bez ogonków”, w praktyce najczęściej stosuje się deterministyczną mapę znaków. Poniżej zestaw podstawowy (z zachowaniem wielkości liter):

Ważne: transliteracja nie jest odwracalna (np. „ż” i „ź” redukują się do „z”), więc traktuj ją jako wariant techniczny, a nie „poprawę” danych źródłowych.

Power Query: prosta transliteracja przez listę zamian

W Power Query najczęściej robi się to przez serię zamian (Replace Values) lub przez funkcję opartą o listę par (znak → zamiennik). Poniższy przykład pokazuje minimalistyczny wzorzec funkcji, którą można zastosować do dowolnej kolumny tekstowej.

// Funkcja: usuń polskie diakrytyki (mapowanie PL->ASCII)
(let txt as nullable text) as nullable text =>
let
  t = if txt = null then null else txt,
  map = {
    {"ą","a"},{"ć","c"},{"ę","e"},{"ł","l"},{"ń","n"},{"ó","o"},{"ś","s"},{"ż","z"},{"ź","z"},
    {"Ą","A"},{"Ć","C"},{"Ę","E"},{"Ł","L"},{"Ń","N"},{"Ó","O"},{"Ś","S"},{"Ż","Z"},{"Ź","Z"}
  },
  out = List.Accumulate(map, t, (state, pair) => Text.Replace(state, pair{0}, pair{1}))
in
  out)

Normalizacja a transliteracja: jak wybrać szybko i bez „przestrzelenia”?

• Gdy dane mają pozostać „po polsku” (nazwy, adresy, opisy) i zależy Ci na poprawnych dopasowaniach między źródłami – priorytetem jest normalizacja reprezentacji znaków, nie usuwanie diakrytyków.
• Gdy budujesz klucz techniczny (np. „nazwa uproszczona” do indeksowania) – stosuj transliterację, a oryginał zachowaj w osobnej kolumnie.
• Jeśli masz mieszankę: część rekordów z diakrytykami, część bez – często warto utrzymywać dwie kolumny: oryginalną i „unifikującą” (np. do porównań).

Typowe objawy problemów z Unicode w danych

• Wizualnie identyczne wartości nie łączą się w Merge albo nie znikają w Remove Duplicates.
• Różna długość tekstu mimo „tego samego” zapisu.
• Nietypowe wyniki filtrowania (np. filtr na „Łódź” nie łapie wszystkich wariantów).

W takich przypadkach najpierw ujednolić reprezentację znaków, a dopiero potem decydować, czy potrzebna jest wersja bez diakrytyków.

5. Korekta błędów OCR i typowych literówek: mapowania znaków i reguły zamiany

Dane tekstowe pochodzące z OCR (skany, PDF-y, zdjęcia) oraz ręcznego przepisywania często zawierają systematyczne błędy: mylenie podobnych znaków, „rozpad” ciągów przez wtrącone spacje, niekonsekwentne użycie łączników czy przypadkowe dopiski. W Power Query da się je korygować szybko, o ile podejdziesz do tematu jak do zestawu wzorców: najpierw identyfikujesz typy pomyłek, potem budujesz powtarzalne reguły zamiany.

Najczęstsze klasy błędów, które warto adresować

• Substytucje znaków podobnych wizualnie (np. „O”↔„0”, „I”↔„1”, „S”↔„5”).
• Wtrącone lub zduplikowane separatory (spacje, myślniki, kropki), które rozbijają tokeny: „AB 123” zamiast „AB123”, „12--34”.
• „Śmieci” z OCR: pojedyncze znaki wstawione losowo, np. „|”, „¬”, „·”, albo fragmenty z łamania wiersza.
• Typowe literówki powtarzalne dla źródła (np. stała zamiana „rn” na „m” lub odwrotnie, albo konsekwentnie mylony znak w danym alfabecie).

Mapowania znaków: prosta korekta „jeden do jednego”

Najbardziej opłacalny start to mapowania (zamiany) pojedynczych znaków lub krótkich sekwencji, które w danych powtarzają się masowo. Kluczowe jest to, że takie zamiany bywają kontekstowe: ten sam znak może być błędem w jednym polu (np. kod produktu), a poprawnym znakiem w innym (np. opis).

Reguły zamiany: mniej „globalnie”, bardziej „warunkowo”

Gdy proste mapowanie może uszkodzić poprawne wartości, wchodzą reguły: zamieniaj tylko wtedy, gdy tekst spełnia warunek (np. długość, dozwolony zestaw znaków, obecność prefiksu). W praktyce oznacza to budowanie transformacji, które:

• działają na wybranych kolumnach (np. tylko „Kod”, nie „Opis”),
• są etapowe (najpierw usunięcie śmieci, potem zamiany mylących znaków, potem dopiero scalenie separatorów),
• zawierają bezpieczniki (np. nie ruszaj wartości, jeśli po korekcie nie przechodzą podstawowego warunku).

Power Query w praktyce: lista zamian jako „słownik”

W Power Query wygodnie jest trzymać pary „szukaj → zamień” jako listę i zastosować je sekwencyjnie. To daje powtarzalność i łatwe dopisywanie kolejnych reguł bez przebudowy całego zapytania.

// Przykład: sekwencyjne zamiany (mapowania) w jednej kolumnie
let
  Source = ...,
  Replacements = {
    {"|", ""},
    {"¬", ""},
    {"O", "0"},
    {"I", "1"}
  },
  Fixed = Table.TransformColumns(
    Source,
    {"Kod", each List.Accumulate(Replacements, _, (state, pair) => Text.Replace(state, pair{0}, pair{1})), type text}
  )
in
  Fixed

Uwaga: taki schemat jest celowo prosty — sprawdza się, gdy masz pewność, że zamiany są poprawne dla danej kolumny. Jeśli nie masz, lepiej wprowadzić warunek (np. zamieniać tylko, gdy wartość wygląda jak kod).

Jak uniknąć „nadkorekty” (czyli psucia dobrych danych)

• Oddziel pola opisowe od identyfikatorów: to, co bezpieczne w kodzie, bywa błędem w opisie.
• Najpierw usuwaj artefakty, potem poprawiaj znaki: śmieci OCR mogą blokować dopasowania i powodować kaskadowe błędy.
• Minimalizuj globalne zamiany: zamiana „S→5” w całej tabeli prawie zawsze skończy się stratami w nazwach.
• Kontroluj skutki: porównuj liczbę wartości zmienionych vs. niezmienionych i sprawdzaj skrajne przypadki (najdłuższe, najkrótsze, najczęstsze).

Ten zestaw wzorców pozwala szybko „odszumić” dane po OCR i ujednolicić typowe literówki bez przepisywania rekordów ręcznie. Kluczem jest rozdzielenie mapowań (proste, szybkie) od reguł (bezpieczniejsze, kontekstowe) oraz świadome ograniczanie transformacji do tych miejsc, gdzie rzeczywiście mają sens.

6. Ekstrakcja i walidacja danych: kody produktów, identyfikatory, wzorce długości i znaki dozwolone

W wielu zestawieniach tekst nie jest „opisem”, tylko nośnikiem identyfikatora: kodu produktu, numeru partii, EAN/GTIN, NIP/REGON, numeru zamówienia, SKU czy symbolu magazynowego. W takich przypadkach celem czyszczenia nie jest upiększanie tekstu, ale wydobycie poprawnej wartości i odrzucenie (lub oznaczenie) rekordów niezgodnych z regułami.

W Power Query najczęściej pracuje się tu w dwóch trybach:

• Ekstrakcja – wyciągnięcie identyfikatora z dłuższego ciągu (np. „SKU: AB-12345 / kolor czarny”).
• Walidacja – sprawdzenie, czy wartość już „wyglądająca jak kod” spełnia wymagania (długość, znaki, prefiksy, suma kontrolna, zakresy).

Najczęstsze scenariusze

• Kody produktów (SKU): mieszane litery/cyfry, często z myślnikami lub ukośnikami; ważna spójność separatorów i stałe segmenty.
• Identyfikatory numeryczne: EAN/GTIN, NIP, REGON – zwykle wymagają zachowania wiodących zer i pracy jako tekst.
• Numery dokumentów: „FV/2026/03/00123” – walidacja wzorca i spójności segmentów (np. rok/miesiąc/licznik).
• Numery seryjne / partie: długość stała, dopuszczalne znaki (np. tylko A–Z i 0–9), czasem bez samogłosek (zależnie od standardu).

Ekstrakcja vs walidacja – kiedy co stosować

Typowe reguły walidacji (praktyczny zestaw)

Poniższe reguły są proste, a jednocześnie dają duży efekt w jakości dopasowań i eliminacji błędów:

• Długość: stała (np. dokładnie 13 znaków) lub zakres (np. 8–12).
• Zestaw znaków dozwolonych: tylko cyfry; tylko alfanumeryczne; alfanumeryczne + „-” i „/”.
• Wiodące zera: traktuj jako tekst, aby nie utracić „000123”.
• Prefiks: np. kod musi zaczynać się od „PL-” albo „SKU”.
• Struktura segmentów: np. „AAA-9999-BB” (litery/cyfry w segmentach, liczba segmentów).
• Unikalność: pomocniczo – identyfikator powinien nie powtarzać się w obrębie klucza biznesowego (np. w danym dokumencie).

Minimalne przykłady w M (ekstrakcja + walidacja)

Poniższy przykład pokazuje schemat pracy: najpierw wydobycie „kandydata” na kod, potem prosta walidacja długości i dozwolonych znaków.

// Załóżmy kolumnę [Opis] typu tekst
let
    AddCandidate = Table.AddColumn(Source, "Kod_kandydat", each 
        try Text.BetweenDelimiters([Opis], "SKU:", " ") otherwise null, type text),

    Normalize = Table.TransformColumns(AddCandidate, {{"Kod_kandydat", each if _=null then null else Text.Trim(_), type text}}),

    AddIsValid = Table.AddColumn(Normalize, "Kod_poprawny", each
        let
            k = [Kod_kandydat],
            allowed = {"A".."Z","0".."9","-"},
            charsOk = if k=null then false else List.AllTrue(List.Transform(Text.ToList(Text.Upper(k)), each List.Contains(allowed, _))),
            lenOk = if k=null then false else Text.Length(k) >= 6 and Text.Length(k) <= 20
        in
            charsOk and lenOk,
        type logical)
in
    AddIsValid

W praktyce często warto dodać także kolumnę „powód odrzucenia” (np. „za krótki”, „niedozwolony znak”, „brak prefiksu”), bo ułatwia to szybkie poprawki u źródła danych.

Walidacja „numeryczna” bez utraty formatu

Dla identyfikatorów, które składają się wyłącznie z cyfr, częsty błąd to konwersja do liczby (utrata wiodących zer, zaokrąglenia przy bardzo długich numerach). Bezpieczne podejście to:

• przechowywać jako tekst,
• weryfikować „czy same cyfry” przez test znaków,
• dopiero na końcu (jeśli naprawdę trzeba) tworzyć wersję liczbową w osobnej kolumnie.

Co daje ten wzorzec w przepływie danych

• Lepsze łączenia (Merge): ujednolicony i zwalidowany kod znacząco zmniejsza liczbę niedopasowań.
• Mniej błędów raportowych: rekordy odstające są oznaczone i nie „psują” agregacji.
• Kontrola jakości: proste reguły walidacji działają jak filtr wejściowy przed dalszym modelowaniem.

7. Usuwanie prefiksów/sufiksów oraz czyszczenie „opakowań” tekstu: nawiasy, cudzysłowy, dopiski

W praktyce dane tekstowe bardzo często mają poprawne „jądro” informacji, ale są obudowane dodatkami, które przeszkadzają w łączeniu, filtrowaniu i porównywaniu wartości. To nie jest błąd samej treści, tylko nadmiarowy kontekst: dopiski w nawiasach, cudzysłowy z systemów eksportujących, oznaczenia wersji, komentarze po myślniku czy sztuczne prefiksy typu „Kod:”. Ten etap czyszczenia polega na konsekwentnym zdejmowaniu takich „opakowań”, tak aby otrzymać stabilną wartość do dalszej analizy.

W Power Query warto podejść do tego wzorcowo: najpierw rozpoznać typowe formy „opakowań” w źródle, a potem zdecydować, czy usuwamy je tylko na brzegach (prefiks/sufiks), czy wycinamy fragmenty w środku (np. zawartość nawiasów). Kluczowa różnica jest taka, że usuwanie brzegów jest zwykle bezpieczniejsze, a ingerencja w środek wymaga wyraźnej reguły, żeby nie utracić istotnych informacji.

• Prefiksy – stałe lub półstałe fragmenty na początku tekstu (np. etykiety pól, skróty działów, znaczniki kanału, „ID:”, „SKU:”). Zastosowanie: ujednolicenie wartości do porównań i łączenia danych, gdy różne systemy dodają własne nagłówki w samej treści.
• Sufiksy – analogiczne dopiski na końcu (np. „- stary”, „(archiwum)”, „v2”, „/PL”, „— kopia”). Zastosowanie: przygotowanie kluczy, nazw produktów lub kategorii, które w raporcie mają być porównywane bez wariantów edycyjnych.
• Nawiasy i komentarze wtrącone – dopiski w okrągłych/kwadratowych nawiasach albo po separatorach (myślnik, ukośnik, pionowa kreska). Zastosowanie: rozdzielenie informacji podstawowej od opisowej, np. usunięcie komentarzy logistycznych, adnotacji „tymczasowe”, „promocja”, „nie używać”.
• Cudzysłowy i „opakowania” eksportowe – wartości otoczone znakami cytowania, apostrofami lub dodatkowymi nawiasami. Zastosowanie: usunięcie warstwy formatowania pochodzącej z CSV, integracji lub kopiowania z innych narzędzi, aby tekst miał jednolitą postać.

W tym obszarze szczególnie ważne jest rozróżnienie między czyszczeniem a utratą znaczenia. Czasem dopisek jest zbędny dla analizy (np. „(test)”), a czasem jest krytyczny (np. wariant pojemności, wersja modelu, rozmiar). Dlatego zamiast usuwać „wszystko w nawiasach” bezrefleksyjnie, lepiej traktować to jako zestaw powtarzalnych reguł: zdejmujemy tylko znane etykiety, znane separatory i znane dopiski, a resztę pozostawiamy lub kierujemy do osobnej kolumny.

Dobrą praktyką jest też utrzymywanie dwóch warstw wyniku: wartość oczyszczona (do łączeń, deduplikacji i filtrów) oraz wartość oryginalna (do audytu i śledzenia). Dzięki temu łatwo sprawdzić, czy reguły nie są zbyt agresywne, oraz szybko skorygować wzorzec, gdy źródło danych zmieni format.

8. Zaawansowane techniki: regex (jeśli dostępne), słowniki zamian, funkcje pomocnicze i składanie wzorców w pipeline

Gdy pojedyncze operacje przestają wystarczać, czyszczenie tekstu w Power Query warto potraktować jak system reguł: powtarzalny, wersjonowalny i łatwy do zastosowania na wielu źródłach. Na tym poziomie kluczowe jest nie tyle „jak wykonać jedną zamianę”, ile jak budować zestaw wzorców, który można rozwijać bez ryzyka, że kolejne poprawki zepsują wcześniejsze wyniki.

Zaawansowane podejście opiera się na czterech filarach: dopasowaniach wzorców (regex, jeśli dostępne), słownikach zamian, funkcjach pomocniczych oraz składaniu reguł w świadomy pipeline (kolejność i izolacja kroków).

Regex: kiedy ma sens i co daje

Wyrażenia regularne są przydatne, gdy problem dotyczy struktur, a nie pojedynczych znaków: zmiennych separatorów, nieregularnych odstępów, segmentów o określonej długości, prefiksów/sufiksów zależnych od kontekstu czy „szumu” w środku tekstu. Jeśli w Twojej wersji Power Query nie ma natywnego regex, podobne efekty da się czasem osiągnąć kombinacją wbudowanych funkcji, ale bywa to mniej czytelne i trudniejsze w utrzymaniu.

• Najlepsze zastosowania: walidacja formatu, wycinanie fragmentów o przewidywalnym wzorcu, redukcja powtarzalnych „artefaktów” (np. wielokrotne separatory).
• Kiedy nie używać: proste, deterministyczne zamiany znak-po-znaku lub krótkie listy wyjątków, gdzie słownik zamian jest czytelniejszy.

Słowniki zamian: od „Find & Replace” do reguł biznesowych

Słownik zamian to podejście, w którym trzymasz reguły w danych (np. lista par „szukaj → zamień”), a nie rozproszone w wielu krokach. Dzięki temu łatwiej aktualizować reguły, recenzować je i przenosić między projektami. To także naturalny sposób na obsługę wyjątków: rzadkich wariantów zapisu, błędów OCR, skrótów czy alternatywnych kodów.

• Jedno źródło prawdy: reguły w jednym miejscu ułatwiają kontrolę jakości i zmian.
• Rozdzielenie warstw: inne słowniki dla normalizacji ogólnej (np. znaki) i inne dla specyficznych przypadków domenowych (np. nazwy/skrótowce).
• Priorytety: w praktyce ważne jest ustalenie kolejności stosowania reguł, bo zamiana A→B może wpływać na kolejne dopasowania.

Funkcje pomocnicze: modularność i powtarzalność

Największy skok jakościowy daje przeniesienie logiki czyszczenia do funkcji. Zamiast kopiować kroki między zapytaniami, tworzysz jeden zestaw funkcji i wywołujesz je w różnych miejscach. To redukuje duplikację, ułatwia testowanie oraz pozwala stopniowo rozbudowywać bibliotekę narzędzi.

• Funkcje „atomowe”: małe, przewidywalne transformacje (np. normalizacja białych znaków, standaryzacja separatorów).
• Funkcje „kompozytowe”: łączenie kilku atomowych w jedną regułę dla konkretnego przypadku użycia (np. „czyść opis produktu”).
• Parametryzacja: możliwość sterowania zachowaniem funkcji (np. dozwolone znaki, długość, tryb agresywnego czyszczenia).

Pipeline wzorców: kolejność ma znaczenie

W czyszczeniu tekstu kolejność operacji często decyduje o wyniku. Dobry pipeline jest deterministyczny (te same dane wejściowe dają ten sam wynik), czytelny (łatwo zrozumieć, co i po co się dzieje) i odporny na rozszerzenia (nowe reguły nie psują istniejących).

• Najpierw normalizacja „szumu”: ujednolicenie białych znaków i znaków niedrukowalnych, żeby późniejsze reguły działały przewidywalnie.
• Następnie standaryzacja zapisu: ujednolicenie separatorów, interpunkcji i formatu, aby dane były porównywalne.
• Potem reguły kontekstowe: np. transformacje zależne od wzorca (kody, identyfikatory, fragmenty o stałej strukturze).
• Na końcu walidacja i flagi: zamiast „na siłę naprawiać wszystko”, często lepiej oznaczyć rekordy wymagające uwagi.

Kontrola jakości: mniej magii, więcej przewidywalności

Zaawansowane czyszczenie to nie tylko transformacje, ale też mechanizmy bezpieczeństwa. W praktyce warto odróżniać „normalizację” (bezpieczne ujednolicenie) od „korekty” (zmiana znaczenia), a także mieć sposób na wykrywanie skutków ubocznych.

• Wersjonowanie reguł: zmiany w słownikach i funkcjach powinny dać się prześledzić i odtworzyć.
• Idempotencja: dobrze, gdy ponowne uruchomienie czyszczenia na już oczyszczonych danych nie zmienia ich ponownie.
• Obserwowalność: warto wiedzieć, które reguły zadziałały i jak często, aby ocenić ich sens i ryzyko.

Te techniki pozwalają przejść od jednorazowego „porządkowania kolumny” do podejścia, w którym czyszczenie tekstu jest produktem: zestawem reguł, które można utrzymywać, rozwijać i stosować konsekwentnie w całym modelu danych. Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

VBA w 2026: jak przepiąć makra na Office Scripts bez przepisywania całej logiki (mapa ryzyk) 09 czerwca 2026

Claude Code w dużych projektach: refaktoryzacja bez katastrofy i regresji w kodzie 07 czerwca 2026