Zapytania wyszukiwania - wartości testowe
Zapytania, które wyszukiwarka czyta jak symbole wieloznaczne, składnię albo zepsuty adres, a nie tekst. 17 wartości, każda z tym, co psuje, i z tym, co zamiast tego robi poprawna aplikacja.
Wpisuj je po jednej skrótem AltShiftN
w palecie albo weź wszystkie do skryptu poleceniem nkb emit search-queries.
Szukanie 100%
search-queries/percent
100%
100%
- 4 grafemy
- 4 punkty kodowe
- 4 bajty
- 4 jednostki UTF-16
- Co psuje
- W SQL LIKE znak procentu pasuje do czegokolwiek, a zapytanie z parametrem go nie escapuje, więc PostgreSQL, MySQL i SQLite zwracają każdy wiersz, który zawiera samo 100, na przykład 1000 items.
- Co robi poprawna aplikacja
- Tylko wyniki, które zawierają tekst 100%.
Szukanie z podkreśleniem
search-queries/underscore
a_b
a_b
- 3 grafemy
- 3 punkty kodowe
- 3 bajty
- 3 jednostki UTF-16
- Co psuje
- W LIKE podkreślenie pasuje do dowolnego jednego znaku, więc a_b znajduje też a-b, axb i a?b z wklejonego linku, a kod, który escapuje znak procentu, często o nim zapomina.
- Co robi poprawna aplikacja
- Tylko wyniki, które zawierają a_b.
Sama gwiazdka
search-queries/asterisk
*
*
- 1 grafem
- 1 punkt kodowy
- 1 bajt
- 1 jednostka UTF-16
- Co psuje
- Sam symbol wieloznaczny: query_string w Elasticsearch zwraca cały indeks, wyszukiwanie pełnotekstowe MySQL i SQLite FTS5 odrzucają go błędem składni, a wyrażenie regularne zbudowane z zapytania pada z komunikatem, że nie ma czego powtarzać.
- Co robi poprawna aplikacja
- Wyniki, które zawierają gwiazdkę, pusty wynik albo komunikat, nigdy wszystko i nigdy strona błędu.
Cudzysłów, który się nie zamyka
search-queries/unbalanced-quote
"annualreport
"annual report
- 14 grafemów
- 14 punktów kodowych
- 14 bajtów
- 14 jednostek UTF-16
- Co psuje
- query_string w Elasticsearch, SQLite FTS5 i to_tsquery w PostgreSQL czytają cudzysłów jako początek frazy, która się nie kończy, i stają z błędem parsera, który aplikacja przekazująca go dalej pokazuje jako stronę błędu.
- Co robi poprawna aplikacja
- Wyniki dla obu słów, z cudzysłowem pominiętym albo szukanym jako tekst.
Nawias, który się nie zamyka
search-queries/unbalanced-paren
(draft
(draft
- 6 grafemów
- 6 punktów kodowych
- 6 bajtów
- 6 jednostek UTF-16
- Co psuje
- Nawias otwiera grupę, która się nie zamyka: query_string w Elasticsearch, SQLite FTS5, to_tsquery w PostgreSQL, logiczne wyszukiwanie pełnotekstowe MySQL i wyrażenie regularne zbudowane z zapytania w Pythonie albo JavaScripcie stają z błędem składni.
- Co robi poprawna aplikacja
- Wyniki dla draft, z nawiasem pominiętym albo szukanym jako tekst.
Słowo z ukośnikiem wstecznym na końcu
search-queries/backslash-end
draft\
draft\\
- 6 grafemów
- 6 punktów kodowych
- 6 bajtów
- 6 jednostek UTF-16
- Co psuje
- Ukośnik wsteczny na końcu niczego nie escapuje, więc query_string w Elasticsearch, SQLite FTS5, to_tsquery w PostgreSQL i wyrażenie regularne zbudowane z zapytania w Pythonie albo JavaScripcie stają z błędem składni.
- Co robi poprawna aplikacja
- Wyniki dla draft z ukośnikiem wstecznym, pusty wynik albo komunikat, nigdy strona błędu.
Szukanie C++
search-queries/c-plus-plus
C++
C++
- 3 grafemy
- 3 punkty kodowe
- 3 bajty
- 3 jednostki UTF-16
- Co psuje
- Tokenizatory gubią plusy, więc wyszukiwanie pełnotekstowe Elasticsearch i PostgreSQL zwraca każdy wynik z literą C, SQLite FTS5 i logiczny tryb MySQL stają z błędem składni, a w adresie składanym ręcznie każdy plus dociera jako spacja.
- Co robi poprawna aplikacja
- Najpierw wyniki o C++, nie każdy wynik z literą C.
Szukanie C#
search-queries/c-sharp
C#
C#
- 2 grafemy
- 2 punkty kodowe
- 2 bajty
- 2 jednostki UTF-16
- Co psuje
- Doklejony do adresu ręcznie bez kodowania krzyżyk zaczyna fragment adresu, a serwer szuka C. Wyszukiwanie pełnotekstowe Elasticsearch i PostgreSQL też gubi krzyżyk, a wyszukiwanie pełnotekstowe MySQL pomija tak krótkie słowo.
- Co robi poprawna aplikacja
- Wyniki o C#, a krzyżyk dociera do serwera zakodowany jako %23.
Fraza z samych słów pomijanych
search-queries/stop-words
tobeornottobe
to be or not to be
- 18 grafemów
- 18 punktów kodowych
- 18 bajtów
- 18 jednostek UTF-16
- Co psuje
- Każde słowo jest na angielskiej liście słów pomijanych wyszukiwania pełnotekstowego PostgreSQL, więc zapytanie robi się puste, a użytkownik nie znajduje niczego dla słynnej frazy.
- Co robi poprawna aplikacja
- Wyniki, które zawierają frazę, albo komunikat, że zapytanie jest zbyt pospolite.
Słowa połączone przez AND
search-queries/boolean-words
saltANDpepper
salt AND pepper
- 15 grafemów
- 15 punktów kodowych
- 15 bajtów
- 15 jednostek UTF-16
- Co psuje
- SQLite FTS5 i składnia zapytań Lucene czytają wielkie AND jako operator, a wyszukiwanie pełnotekstowe dopasowuje słowa w dowolnym miejscu, więc rekord pepper with sea salt pojawia się dla frazy, którą wpisał użytkownik.
- Co robi poprawna aplikacja
- Te same wyniki co dla salt and pepper albo fraza szukana tak, jak wpisana.
Krok 1: zapisz rekord Łódź z polskimi literami
search-queries/diacritics-storedpołowa 1 z 2 Polska pisownia i to samo słowo bez polskich liter
Łódź
Łódź
- 4 grafemy
- 4 punkty kodowe
- 7 bajtów
- 4 jednostki UTF-16
- Co psuje
- Krok 1 testu akcentów: zapisz rekord o tej nazwie, polskiej pisowni miasta, zanim zaczniesz go szukać bez polskich liter.
- Co robi poprawna aplikacja
- Zapisany tak, jak wpisany.
Krok 2: szukaj lodz bez polskich liter
search-queries/diacritics-searchedpołowa 2 z 2 Polska pisownia i to samo słowo bez polskich liter
lodz
lodz
- 4 grafemy
- 4 punkty kodowe
- 4 bajty
- 4 jednostki UTF-16
- Co psuje
- Krok 2: szukaj rekordu z kroku 1 wpisanego bez polskich liter, tak jak pisze większość użytkowników na klawiaturze bez nich.
- Co robi poprawna aplikacja
- Rekord z kroku 1 znaleziony.
Trzy spacje
search-queries/spaces-only
3 ×
- zaczyna się spacją
- kończy się spacją
- 3 grafemy
- 3 punkty kodowe
- 3 bajty
- 3 jednostki UTF-16
- Co psuje
- Po przycięciu zostaje puste zapytanie, na które jedne wyszukiwarki odpowiadają wszystkimi wierszami, a inne błędem: SQLite FTS5 je odrzuca, a adres składany ręcznie gubi spacje z końca, więc serwer dostaje puste zapytanie.
- Co robi poprawna aplikacja
- Pusty wynik albo komunikat, tak samo jak dla pustego pola wyszukiwania.
Wklejony link
search-queries/url-query
https://example.com/a?b=1
https://example.com/a?b=1
- 25 grafemów
- 25 punktów kodowych
- 25 bajtów
- 25 jednostek UTF-16
- Co psuje
- query_string w Elasticsearch czyta dwukropek jako nazwę pola, a ukośnik jako początek wyrażenia regularnego, i odrzuca link, SQLite FTS5 odpowiada, że nie ma takiej kolumny, a zapytania match zwracają każdy rekord z example albo com.
- Co robi poprawna aplikacja
- Rekordy, które zawierają ten link.
Adres e-mail
search-queries/email-query
first.last@example.com
first.last@example.com
- 22 grafemy
- 22 punkty kodowe
- 22 bajty
- 22 jednostki UTF-16
- Co psuje
- Wyszukiwanie pełnotekstowe Elasticsearch i MySQL dzieli adres przy małpie i kropkach i zwraca każdy rekord z example albo com, logiczny tryb MySQL odrzuca małpę, a SQLite FTS5 odrzuca kropkę.
- Co robi poprawna aplikacja
- Najpierw rekord z tym adresem.
Numer faktury z ukośnikami
search-queries/invoice-number
FV/2027/11/001
FV/2027/11/001
- 14 grafemów
- 14 punktów kodowych
- 14 bajtów
- 14 jednostek UTF-16
- Co psuje
- query_string w Elasticsearch czyta ukośnik jako początek wyrażenia regularnego i odrzuca numer, a wyszukiwanie pełnotekstowe Elasticsearch i MySQL dzieli go przy ukośnikach i zwraca każdą fakturę i każdy inny rekord z 2027 roku.
- Co robi poprawna aplikacja
- Najpierw faktura z tym numerem.
16500 znaków
search-queries/long-query
16 500 × a
- 16 500 grafemów
- 16 500 punktów kodowych
- 16 500 bajtów
- 16 500 jednostek UTF-16
- Co psuje
- Wysłane jako parametr GET zapytanie jest dłuższe, niż serwery WWW domyślnie przyjmują: IIS odpowiada 404 powyżej 2048 bajtów, nginx, Apache i Kestrel 414 powyżej ok. 8 KB, a Node 431 powyżej 16 KB, czyli stroną błędu zamiast wyników albo komunikatu.
- Co robi poprawna aplikacja
- Wyniki albo komunikat, że zapytanie jest za długie.
Pary
Każda para to dwie wartości z listy wyżej, które warto wpisać obok siebie: w dwa pola albo dwa razy w jedno pole. Skrót AltShiftN wpisuje je po kolei, a paleta mówi, która połowa pary jest następna.
Polska pisownia i to samo słowo bez polskich liter
search-queries/diacriticspołowa 1 z 2 Krok 1: zapisz rekord Łódź z polskimi literami
Łódź- 4 grafemy
- 4 punkty kodowe
- 7 bajtów
- 4 jednostki UTF-16
połowa 2 z 2 Krok 2: szukaj lodz bez polskich liter
lodz- 4 grafemy
- 4 punkty kodowe
- 4 bajty
- 4 jednostki UTF-16
- Co psuje
- Krok 3: wyszukiwanie, które zdejmuje akcenty po rozkładzie NFD, i tak nie znajduje rekordu, bo polskie ł nie ma rozkładu. Rozszerzenie unaccent w PostgreSQL i domyślne porównanie MySQL bez akcentów go znajdują, a zwykłe LIKE, SQLite, Elasticsearch z domyślnym analizatorem i JavaScript nie.
- Co robi poprawna aplikacja
- Szukanie lodz znajduje rekord zapisany z polskimi literami.