Niewidoczne znaki w kodzie lub nazwie produktu

Objaw

Wpisujesz kod produktu w wyszukiwarkę panelu i nic nie znajduje — choć towar tam jest i widzisz go na liście. Hurtownia odsyła plik z informacją, że tego kodu nie zna. Integracja z magazynem tworzy drugą kartę zamiast dopasować istniejącą. Na ekranie kod wygląda dokładnie tak, jak powinien.

Bo problem nie jest w tym, co widać. W polu siedzi dodatkowy znak, którego przeglądarka nie rysuje: twarda spacja przeniesiona z arkusza kalkulacyjnego, znak zerowej szerokości z kopiowania ze strony internetowej albo tabulator z eksportu.

Ile to kosztuje

Kod produktu ma jedno zadanie: być tym samym ciągiem znaków u Ciebie, u dostawcy i w każdym systemie po drodze. Niewidoczny znak psuje to cicho.

• Dopasowania przestają działać. Import po kodzie nie znajduje towaru i zakłada nowy. Po kilku takich przebiegach masz w katalogu duplikaty, których nie da się znaleźć wyszukiwarką.
• Wyszukiwarka panelu milczy. Wpisujesz kod, który widzisz na ekranie, i dostajesz pustkę — a wygląda to jak usterka sklepu, nie jak usterka danych.
• Feed i marketplace odrzucają ofertę albo przyjmują ją z kodem, którego nikt później nie dopasuje do zamówienia.

Osobno, i to jest najbardziej podstępne: dwa towary mogą dzielić kod, nie dzieląc go co do bajtu. ABC-1 i ABC-1 z twardą spacją na końcu to dla człowieka ten sam kod, a dla bazy dwa różne. Taki duplikat nie zapali się w żadnej kontroli unikalności — ani w sklepie, ani w systemie magazynowym.

Jak sprawdzić to samodzielnie

Z WP-CLI, bez żadnej wtyczki — szukamy bajtów, nie znaków:

wp db query "SELECT p.ID, pm.meta_value AS sku \
  FROM wp_postmeta pm JOIN wp_posts p ON p.ID = pm.post_id \
  WHERE pm.meta_key = '_sku' AND pm.meta_value <> '' \
  AND (HEX(pm.meta_value) LIKE '%C2A0%' \
       OR HEX(pm.meta_value) LIKE '%E2808B%' \
       OR HEX(pm.meta_value) LIKE '%EFBBBF%' \
       OR pm.meta_value <> TRIM(pm.meta_value))"

Podmień wp_ na swój przedrostek tabel. C2A0 to twarda spacja, E2808B znak zerowej szerokości, EFBBBF znacznik BOM. Zapytanie szuka ich w zapisie szesnastkowym, bo w wyniku i tak byłyby niewidoczne.

Jak to naprawić

1. Skopiuj kod z pola i wklej go do edytora, który pokazuje znaki specjalne, albo po prostu wpisz kod ręcznie od nowa. Przy krótkim kodzie to najszybsza droga.
2. Nie używaj funkcji „przytnij spacje” z arkusza — TRIM w większości arkuszy i w SQL nie usuwa twardej spacji ani znaku zerowej szerokości. Usuwa tylko zwykłą spację.
3. Napraw źródło, bo inaczej wróci przy następnym imporcie. Najczęstsze to kolumna sformatowana w arkuszu jako tekst z wyrównaniem oraz kopiowanie kodów ze strony hurtowni prosto do arkusza.
4. Po naprawie sprawdź, czy nie zrobił się duplikat — jeśli niewidoczny znak był jedyną różnicą między dwoma towarami, po wyczyszczeniu kody staną się identyczne i sklep to odrzuci.

Kiedy to fałszywy alarm

• Kod, który naprawdę zawiera spację, na przykład ABC 123. Zwykła spacja w środku jest legalnym znakiem i ta kontrola jej nie zgłasza — reaguje tylko na znaki, których nie widać.
• Nazwa produktu z twardą spacją użytą celowo. Polska typografia wiąże twardą spacją jednoliterowe spójniki („w domu”, „z drewna”), robią to też wtyczki typograficzne. Dlatego w nazwie kontrola nie zgłasza twardej spacji ani miękkiego łącznika — tylko znaki sterujące, zerowej szerokości i BOM.
• Kod z zewnętrznego systemu, którego nie wolno Ci zmienić. Zdarza się przy kodach narzuconych przez dostawcę. Wtedy ukryj znalezisko — problem zostaje, ale świadomie.

Jak Merchlint to znajduje

Merchlint czyta surową wartość kodu produktu, identyfikatora GTIN i nazwy — dokładnie taką, jaka leży w bazie, bez czyszczenia po drodze — i porównuje ją z tą samą wartością po normalizacji. Różnica znaczy, że w polu jest znak, który do kodu nie należy.

Zgłaszane są: znaki sterujące ASCII, znaki zerowej szerokości (U+200B–U+200D, U+2060), znacznik BOM (U+FEFF), miękki łącznik (U+00AD) oraz twarde spacje (U+00A0, U+202F, U+2007) na brzegach i w środku kodu. W nazwie zakres jest węższy i celowo ostrożny: tylko znaki sterujące, zerowej szerokości i BOM.

Dowód znaleziska pokazuje, gdzie dokładnie siedzi znak, zapisany jako ⟨U+00A0⟩ w miejscu, w którym występuje. Bez tego zapisu „spacja na końcu” i „twarda spacja na końcu” wyglądałyby na ekranie identycznie, a to dwie różne naprawy.

Ta sama definicja czystego kodu obsługuje porównania w kontrolach duplikatów, więc kontrola i porównanie nie mogą się rozjechać: jeśli Merchlint uznaje dwa kody za ten sam, to znaczy, że po usunięciu niewidocznych znaków są identyczne.

Pewność: F — fakt z bazy danych. Bajt albo tam jest, albo go nie ma.

Ta kontrola jest w dodatku Pro.