Dokumentumok keresése (előzetes verziójú REST API)

API-verzió: 2021. 04. 30. előzetes verzió

Fontos

Az API előzetes verziójú funkciói közé tartozik a szemantikai lekérdezések típusa és válaszai, egy helyesírás-javítást lehetővé telő helyesírás-paraméter, valamint egy featuresMode paraméter, amely képes jelentést adni a mezőnkénti kifejezés gyakoriságáról, a mezőnkénti hasonlóság pontszámáról és az egyedi egyezések mezőnkénti számáról. A szemantikai lekérdezésekhez és a helyesírás-ellenőrzőkhez is új queryLanguage paraméterre van szükség. Ezen előzetes funkciók mind támogatottak a 2020. 06. 30. előzetes verzióban is.

A lekérdezési kérelem egy keresési szolgáltatás egyetlen indexének dokumentumgyűjteményét célozza meg. Olyan paramétereket tartalmaz, amelyek meghatározzák az egyeztetési feltételeket, valamint a választ meghatározó paramétereket.

Használhatja a GET vagy a POST használhatja. A lekérdezési paraméterek GET-kérések esetén a lekérdezési sztringben, POST-kérések esetén pedig a kérelem törzsében vannak megadva.

GET https://[service name].search.windows.net/indexes/[index name]/docs?[query parameters] 
  Content-Type: application/json   
  api-key: [admin or query key]  

Ha POST-et használ, adja hozzá a "search" műveletet URI-paraméterként.

POST https://[service name].search.windows.net/indexes/[index name]/docs/search?api-version=[api-version]  
  Content-Type: application/json  
  api-key: [admin or query key]  

A GET használatával hívva a kérés URL-címe nem haladhatja meg a 8 KB-os méretet. Ez a hossz általában elegendő a legtöbb alkalmazáshoz. Egyes alkalmazások azonban rendkívül nagy méretű lekérdezéseket hoznak létre, különösen OData-szűrőkifejezések használata esetén. Ezekhez az alkalmazásokhoz a HTTP POST jobb választás, mert nagyobb szűrőket tesz lehetővé, mint a GET.

A POST használata esetén a szűrőben szereplő záradékok száma a korlátozó tényező, nem pedig a nyers szűrősring mérete, mivel a POST kérésméretének korlátja körülbelül 16 MB. Bár a POST-kérések méretkorlátja nagyon nagy, a szűrőkifejezések nem összetettek tetszőlegesen. A szűrők összetettségének korlátozásával kapcsolatos további információkért lásd: Az OData-kifejezések szintaxisa Azure Cognitive Search.

URI-paraméterek

Paraméter Leírás
[szolgáltatásnév] Kötelező. Állítsa ezt a keresési szolgáltatás egyedi, felhasználó által definiált nevére.
[index neve]/dokumentumok Kötelező. Egy megnevezett index dokumentumgyűjteményét adja meg.
[lekérdezési paraméterek] A lekérdezési paraméterek a GET-kérések URI-ján és a POST-kérések kérelem törzsében vannak megadva.
api-verzió Kötelező. Az aktuális verzió api-version=2021-04-30-Preview a következő: . További verziókért lásd: API-verziók.

URL-kódolási javaslatok

Ne felejtsen el URL-kódolást megadni bizonyos lekérdezési paraméterekhez, amikor közvetlenül a GET REST API hív. A Dokumentumok keresése művelethez URL-kódolásra lehet szükség a következő lekérdezési paraméterekhez:

  • keresés
  • $filter
  • Tényezője
  • highlightPreTag
  • highlightPostTag

Az URL-kódolás csak az egyes paraméterekhez ajánlott. Ha véletlenül URL-kódolást ad a teljes lekérdezési sztringnek (mindent a ? után), a kérések meg fognak hiúsulni.

Emellett az URL-kódolásra csak akkor van szükség, ha a REST API a GET használatával. A POST vagy a Azure Cognitive Search .NETügyféloldali kódtár használata esetén nincs szükség URL-kódolásra, amely a kódolást kezeli.

Kérelemfejlécek

Az alábbi táblázat a szükséges és választható kérésfejléceket ismerteti.

Mezők Leírás
Content-Type Kötelező. Állítsa "application/json" (alkalmazás/json) beállításra
api-key Kötelező. Egy egyedi, rendszer által létrehozott sztring, amely hitelesíti a kérést a keresési szolgáltatásnak. A dokumentumgyűjteményre vonatkozó lekérdezési kérelmek rendszergazdai vagy lekérdezési kulcsot is megadhatnak API-kulcsként. A lekérdezési kulcs csak olvasható műveletekhez használható a dokumentumgyűjteményen. Az API-kulcsot a keresési szolgáltatás irányítópultján találja a Azure Portal.

Kérelem törzse

GET: Nincs.

POST::

{  
     "answers": "none" (default) | "extractive", 
     "count": true | false (default),  
     "facets": [ "facet_expression_1", "facet_expression_2", ... ],  
     "featuresMode" : "disabled" (default) | "enabled",
     "filter": "odata_filter_expression",  
     "highlight": "highlight_field_1, highlight_field_2, ...",  
     "highlightPreTag": "pre_tag",  
     "highlightPostTag": "post_tag",  
     "minimumCoverage": # (% of index that must be covered to declare query successful; default 100),  
     "orderby": "orderby_expression",
     "queryLanguage": "en-us" (default) | (a supported language code), 
     "queryType": "simple" (default) | "full" | "semantic",
     "scoringParameters": [ "scoring_parameter_1", "scoring_parameter_2", ... ],  
     "scoringProfile": "scoring_profile_name",  
     "scoringStatistics" : "local" (default) | "global",
     "search": "simple_query_expression",  
     "searchFields": "field_name_1, field_name_2, ...",  
     "searchMode": "any" (default) | "all",  
     "select": "field_name_1, field_name_2, ...",  
     "sessionId" : "session_id",
     "skip": # (default 0), 
     "speller": "none" (default) | "lexicon",  
     "top": #  
   }  

Részleges keresési válaszok folytatása

Néha Azure Cognitive Search, hogy az összes kért eredményt nem tudja visszaadni egyetlen Search-válaszban. Ez különböző okok miatt fordulhat elő, például ha a lekérdezés túl sok dokumentumot kér azáltal$top hogy nem ad meg értéket $top túl nagy méretű dokumentumhoz. Ilyen esetekben a Azure Cognitive Search a jegyzetet a válasz törzsében, valamint akkor is, ha @odata.nextLink @search.nextPageParameters az egy POST-kérés volt. Ezeknek a jegyzeteknek az értékeit használva egy másik keresési kérést is kialakíthat a keresési válasz következő részének lekérésére. Ezt az eredeti keresési kérelem folytatásának, a jegyzeteket pedig általában folytatási tokennek nevezzük. Az alábbi Válaszban található példában részletesen olvashat ezeknek a jegyzeteknek a szintaxisával, valamint arról, hogy hol jelennek meg a válasz törzsében.

Az okok, Azure Cognitive Search folytatási tokeneket ad vissza, implementációspecifikusak, és változhatnak. A robusztus ügyfeleknek mindig készen kell állniuk az olyan esetekre, amelyekben a vártnál kevesebb dokumentumot ad vissza a rendszer, és egy folytatási tokent is tartalmaznak a dokumentumok leolvasásának folytatásához. Azt is vegye figyelembe, hogy a folytatáshoz ugyanazt a HTTP-metódust kell használnia, mint az eredeti kérést. Ha például EGY GET kérést küldött, minden elküldött folytatási kérelemnek a GET (és a POST) igénylést is használnia kell.

Megjegyzés

A és a célja, hogy megvédje a szolgáltatást a túl sok eredményt lekért lekérdezésekkel kapcsolatosaktól, és ne biztosítson @odata.nextLink @search.nextPageParameters általános lapozási mechanizmust. Ha az eredményeket lapszámokkal szeretné lapszámba $top és $skip használhatja. Ha például 10 méretű oldalakat szeretne, az első kérésnek $top=10-nek és $skip=0-nak kell lennie, a második kérésnek $top=1'-nek és $skip=10-nek kell lennie, a harmadik kérésnek $top=10 és $skip=20 stb. kell lennie.

Lekérdezési paraméterek

A lekérdezések több paramétert is elfogadnak az URL-címen a GET használatával való meghíváskor, valamint JSON-tulajdonságokként a kérelem törzsében a POST használatával való meghíváskor. Egyes paraméterek szintaxisa kissé eltér a GET és a POST paraméterektől. Ezeket a különbségeket alább, az alkalmazható módon jegyezzük fel.

Név Típus Leírás
válaszok (előzetes verzió) sztring Választható. Az érvényes értékek a "nincs" és az "extractive". Az alapértelmezett érték a "nincs". Ez a paraméter csak akkor érvényes, ha a lekérdezés típusa "szemantikai". Ha "extractive" (kinyerés) értékűre van állítva, a lekérdezés a legmagasabb szemantikailag rangsorolt dokumentumok kulcsrészeiből ad vissza válaszokat. Az alapértelmezett egy válasz, de legfeljebb tízet adhat meg egy darabszám hozzáadásával. Például a "answers": "extractive | count-3" három választ ad vissza. Ahhoz, hogy a rendszer választ adna vissza, elegendő információnak kell lennie a searchFields (keresési mező) mezőben ahhoz, hogy ki legyen dolgozva. Emellett magának a lekérdezésnek is kérdésként kell kinéznie. A kulcsszókeresés nem ad vissza választ.
api-verzió sztring Kötelező. A kérelemhez REST API verziószáma. A támogatott verziók listáját lásd: API-verziók. Ehhez a művelethez az api-version paraméter URI-paraméterként van megadva, függetlenül attól, hogy a Dokumentumok keresése a GET vagy a POST használatával hívja-e meg.
$count boolean Választható. Érvényes értékek: "true" (igaz) vagy "false". Az alapértelmezett érték a "false". Post használatával hívva ennek a paraméternek a neve nem $count. Meghatározza, hogy a lekéri-e az eredmények teljes számát. Ez a keresési és keresési paraméterekkel egyező összes dokumentum $filter, figyelmen kívül hagyva a $top és $skip. Ha ezt az értéket "true" (igaz) értékre váltja, az ronthatja a teljesítményt. A visszaadott darabszám egy közelítés. Ha csak a dokumentumok nélküli darabszámra van szükség, használja a $top=0 paramétert.
Tényezője sztring Választható. Egy mező, amelyet meg kell adni. A sztring olyan paramétereket tartalmazhat, amelyek testre szabják az a facetinget, vesszővel elválasztott név:érték párokként kifejezve. A POST használatával hívva ez a paraméter a facets helyett facets lesz.

Érvényesség: "count", "sort", "values", "interval" és "timeoffset".

A "count" a facet kifejezések maximális száma; Az alapértelmezett érték 10. A kifejezések számának nincs felső korlátja, de a magasabb értékek rontják a teljesítményt, különösen akkor, ha a faceted mező sok egyedi feltételt tartalmaz. A "facet=category,count:5" például a facet eredmények első öt kategóriáját kapja meg. Ha a count paraméter kevesebb, mint az egyedi kifejezések száma, akkor előfordulhat, hogy az eredmények nem pontosak. Ennek az az oka, ahogyan a faceting lekérdezések el vannak osztva a szegmensek között. A darabszám növelése általában növeli a kifejezésszámok pontosságát, de teljesítményköltséggel.

A "sort" beállítható "count", "-count", "value", "-value" értékre. A count (darabszám) használatával csökkenő sorrendbe rendezheti őket. A -count használatával növekvő sorrendbe rendezheti a darabszámokat. Az érték használatával növekvő sorrendbe rendezheti az értékeket. A -value használatával csökkenő sorrendbe rendezhet érték szerint (például a "facet=category,count:3,sort:count" a facet results (értékkorrekt) első három kategóriáját kapja meg csökkenő sorrendben az egyes városnevekkel együtt. Ha a három legjobb kategória a Budget (Költségvetés) , a Pedig a Luxury (Luxus) és a Budget (Luxus) 5 találatot, a Pedig 6 találatot, a Luxus kategóriát pedig 4-nek, akkor a gyűjtők a Következő sorrendben lesznek megrendelve: ). A -value esetében a "facet=rating,sort:-value" gyűjtőket hoz létre az összes lehetséges értékeléshez érték szerint csökkenő sorrendben (például ha az értékelések 1 és 5 között vannak, a gyűjtők 5, 4, 3, 2, 1 szerint lesznek rendezve, függetlenül attól, hogy hány dokumentum felel meg az egyes értékeléseknek).

Az "értékek" beállíthatók pipe-tagolt numerikus vagy Edm.DateTimeOffset értékekre, amelyek a facet belépési értékek dinamikus készletét határozzák meg (például a "facet=baseRate,values:10 20" három gyűjtőt hoz létre: egyet a 0 és 10 között, egyet a 10-hez, de nem a 20-hoz, egyet pedig a | 20-hoz és a 20-hoz. A "facet=lastRenovationDate,values:2010-02-01T00:00:00Z" sztring két gyűjtőt hoz létre: egyet a 2010 februárja előtti szállodákhoz, egyet pedig a 2010. február 1- és újabb szállodákhoz.

Az "interval" egy 0-snál nagyobb egész szám- vagy perc-, óra-, nap-, hét-, hónap-, negyedév-, dátum- és időértékek esetén. A "facet=baseRate,interval:100" például 100-as alapdíjtartományok alapján hoz létre gyűjtőket. Ha az alapárak mind 60 és 600 USD között vannak, gyűjtők lesznek a 0–100, 100–200, 200–300, 300–400, 400–500 és 500–600 gyűjtőkből. A "facet=lastRenovationDate,interval:year" sztring minden évhez létrehoz egy gyűjtőt a szállodák kiújításának esetén.

A "timeoffset" ([+-]hh:mm, [+-]hhmm vagy [+-]hh) beállításra is beállítható. Ha használja, a timeoffset paramétert az interval beállítással kell kombinálni, és csak akkor, ha egy Edm.DateTimeOffset típusú mezőre van alkalmazva. Az érték határozza meg az időhatárok beállításakor figyelembe vennie az UTC-időeltolást. Például: "facet=lastRenovationDate,interval:day,timeoffset:-01:00" a 01:00:00 időponttól (UTC) éjfélkor (a célidőzónában éjfél) eltító naphatárt használja.

A count és a sort kombinálható ugyanabban a facet specifikációban, de nem kombinálhatók intervallummal vagy értékekkel, és az intervallum és az értékek nem kombinálhatók együtt.

A dátum és idő intervallum-aktretásai az UTC-idő alapján vannak kiszámítva, ha az időeltolódás nincs megadva. Például: "facet=lastRenovationDate,interval:day" esetén a nap határa 00:00:00 UTC időponttól kezdődik.
featuresMode (előzetes verzió) boolean Választható. Az érvényes értékek "engedélyezve" és "letiltva". Az alapértelmezett beállítás a "disabled" (letiltva). Egy érték, amely meghatározza, hogy az eredmények tartalmazzák-e a lekérdezési eredmények funkcióit, amely egy dokumentum relevanciapontszámának a lekérdezéshez viszonyított kiszámítására használható, például mezőnkénti hasonlóság. Az "enabled" (engedélyezve) beállítással további lekérdezési eredményekre vonatkozó funkciókat is elérhetővé lehet tenni: mezőnkénti hasonlóság pontszám, mezőkifejezés-gyakoriság és megfeleltethető egyedi jogkivonatok mezőnkénti száma. További információ: Hasonlóság és pontozás.
$filter sztring Választható. Strukturált keresési kifejezés standard OData-szintaxisban. Szűrőben csak szűrhető mezők használhatók. Post használatával hívva ennek a paraméternek a neve szűrő, nem pedig $filter. Az OData-kifejezések szintaxisa Azure Cognitive Search OData-kifejezés szintaxisának az OData-kifejezés által támogatott részkészletét Azure Cognitive Search meg.
Kiemelni sztring Választható. A találatok kiemelését vesszővel elválasztott mezőnevek halmaza. A találatok kiemeléséhez csak kereshető mezők használhatók. Alapértelmezés szerint a Azure Cognitive Search legfeljebb 5 kiemelést ad vissza mezőnként. A korlát mezőnként konfigurálható a "-<maximális> száma" a mező neve után. Például a "highlight=title-3,description-10" legfeljebb 3 kiemelt találatot ad vissza a cím mezőből, és legfeljebb 10 találatot a leírás mezőből. A kiemelések maximális számának 1 és 1000 közötti egész számnak kell lennie.
highlightPostTag sztring Választható. Az alapértelmezett érték "</em>" a . A kiemelt kifejezéshez hozzáfűző sztringcímke. A highlightPreTag beállítással kell beállítani. Az URL-címben foglalt karaktereknek százalék kódolásúnak kell lennie (például :23 a #helyett).
highlightPreTag sztring Választható. Az alapértelmezett érték "</em>" a . Egy sztringcímke, amely a kiemelt kifejezésre van előtagként kivetve. A highlightPostTag beállítással kell beállítani. Az URL-címben foglalt karaktereknek százalék kódolásúnak kell lennie (például :23 a #helyett).
minimumCoverage egész szám Választható. Az érvényes értékek 0 és 100 közötti számok, amelyek azt jelzik, hogy az indexnek hány százalékban kell elérhetőnek lennie a lekérdezés kiszolgálására ahhoz, hogy sikeresként jelenthető legyen. Az alapértelmezett érték a "100".

A 100%-os lefedettség azt jelenti, hogy minden szegmens válaszolt a kérésre (sem a szolgáltatás állapotával kapcsolatos problémák, sem a karbantartási tevékenységek nem csökkentették a lefedettséget). Az alapértelmezett beállításnál a kisebb, mint teljes lefedettség az 503-as HTTP-állapotkódot adja vissza.

A minimumCoverage csökkentésének hasznos lehet 503-as hibák esetén, és növelni szeretné a lekérdezés sikerességének valószínűségét, különösen az egy replikához konfigurált szolgáltatások esetén. Ha a minimumCoverage és a Search succeeds (Sikeres keresés) értéket ad vissza, az HTTP 200-as értéket ad vissza, és egy értéket tartalmaz a válaszban, amely jelzi a lekérdezésben szereplő index százalékos @search.coverage arányát. Ebben a forgatókönyvben nem minden egyező dokumentum fog garantáltan jelen lenni a keresési eredményekben, de ha a keresés rendelkezésre állása fontosabb, mint a felidézés, akkor a lefedettség csökkentése megvalósítható kockázatcsökkentési stratégia lehet.
$orderby sztring Választható. Az eredmények rendezése vesszővel elválasztott kifejezések listája. Post használatával hívva a paraméter neve helyett orderby $orderby. Minden kifejezés lehet mezőnév vagy a geo.distance() függvény hívása. Minden kifejezés után az "asc" kifejezéssel jelezheti a növekvő, a "desc" pedig a csökkenő sorrendet. Ha a rendezési mezőben null értékek vannak, a null értékek először növekvő, majd csökkenő sorrendben jelennek meg. Az alapértelmezett érték a növekvő sorrend. Az egyezések a dokumentumok egyezései pontszámai alapján lesznek fel bontva. Ha nincs $orderby megadva, az alapértelmezett rendezési sorrend a dokumentum egyezésének pontszáma szerint csökkenő. A záradékok felső korlátja 32 $orderby.
queryLanguage (előzetes verzió) sztring Választható. Az érvényes értékek a támogatott nyelvek. Az alapértelmezett érték az "en-us". Ezt a paramétert akkor kell beállítani, ha speller=lexicon vagy queryType=szemantikai típust használ. A queryLanguage alatt megadott nyelvet a helyesírás-ellenőrzéshez és az eredményeket újra rangsorolja, és feliratot vagy választ kinyerő szemantikai modellek is használják. A lekérdezésnyelvhez használt kódtárak függetlenek a területi beállításokon alapuló mezőattribútumoktól, például az indexeléshez és a teljes szöveges kereséshez használt nyelvi elemzőktől.
queryType (lekérdezés típusa) sztring Választható. Érvényes értékek: "simple", "full" (teljes) vagy "szemantikai" (előzetes verzió). Az alapértelmezett érték az "egyszerű".

Az "egyszerű" a lekérdezési sztringeket az olyan egyszerű lekérdezési szintaxissal értelmezi, amely lehetővé teszi az olyan szimbólumokat, mint a + , a és a * "" . A lekérdezések kiértékelése alapértelmezés szerint minden dokumentum összes kereshető mezőjében (vagy a searchFields mezőben jelzett mezőkben) történik.

A "full" a teljes Lucene lekérdezési szintaxissal értelmezi a lekérdezési sztringeket, ami lehetővé teszi a mezőspecifikus és súlyozott kereséseket. A Tartománykeresés a Lucene lekérdezési nyelvben nem támogatott a hasonló funkciókat $filter funkciókat kínál.

A "szemantikai" úgy javítja a keresési eredmények pontosságát, hogy az első 50 találatot egy, a Bing-korpuszban betanított rangsorolási modellel, a kulcsszavakkal szemben természetes nyelven kifejezett lekérdezésekhez használja. Ha a lekérdezés típusa szemantikai, akkor a queryLanguage lekérdezést is be kell állítania. Ha szeretné, beállíthatja a searchFields (keresési mező) mezőben a szemantikai pontszám kiszámításának prioritási sorrendjét, és opcionálisan megadhat válaszokat is, ha az első 3 választ is szeretné visszaadni, ha a lekérdezés bemenete természetes nyelven lett megállítva ("mi az a ...).
scoringParameter (pontozásiparaméter) sztring Választható. A pontozási függvényben (például referencePointParameter) definiált paraméterek értékeit jelzi a "name-value1,value2,..." formátumban Post használatával hívva a paraméter neve scoringParameters a scoringParameter helyett. Emellett sztringek JSON-tömbjeként adhatja meg, ahol minden sztring különálló név-érték pár.

A függvényt is magában foglaló pontozási profilok esetében a függvényt egy karakterrel válassza el a bemeneti - listából. Egy nevű függvény például "mylocation" "&scoringParameter=mylocation---122.2,44.8". Az első kötőjel elválasztja a függvény nevét az értéklisttól, míg a második kötőjel az első érték része (ebben a példában a hosszúság).

A pontozási paraméterek, például a vesszőket tartalmazó címkekiemelések esetén a lista bármely ilyen értéke kiveheti a listára a egyszeres idézőjelek használatával. Ha maguk az értékek egyszeres idézőjeleket tartalmaznak, duplálással oldhatja fel őket. Tegyük fel, hogy van egy nevű címkekiemelési paramétere, és szeretné kiemelni a "Hello, O'Brien" és "Smith" címkeértékeket, a lekérdezési sztring a következő lenne: "mytag" "&scoringParameter=mytag-'Hello, O''Brien',Smith". Az idézőjelek csak vesszőket tartalmazó értékekhez szükségesek.
scoringProfile (pontozásiprofil) sztring Választható. Egy pontozási profil neve, amely kiértékeli az egyező dokumentumok egyezési pontszámait az eredmények rendezése érdekében.
scoringStatistics (pontozási statisztika) sztring Választható. Az érvényes értékek a "local" (helyi) vagy a "global" (globális). Az alapértelmezett érték a "local". Adja meg, hogy a pontozási statisztikákat, például a dokumentum gyakoriságát, globálisan (az összes szegmensre) számítja-e ki a konzisztensebb pontozás érdekében, vagy helyileg (az aktuális szegmensen) az alacsonyabb késés érdekében. Lásd: Pontozási statisztika Azure Cognitive Search. A pontozási statisztikákat a rendszer mindig helyben számítja ki az fuzzy search ('~') kifejezésre.
keresés sztring Választható. A kereshető szöveg. A rendszer alapértelmezés szerint minden kereshető mezőben keres, kivéve, ha a searchFields (Mezők) mező meg van adva. Az indexben a kereshető mező szövege jogkivonattal van elválasztva, így több kifejezés is elválasztható térközvel (például: "search=hello world"). Bármely kifejezés egyeztetéséhez használja a kifejezést (ez hasznos lehet a * logikai szűrőlekérdezésekhez). A paraméter kihagyása ugyanazokkal a hatásokkal rendelkezik, mint a * beállítása. A keresési szintaxissal kapcsolatos részletekért lásd: Egyszerű lekérdezési szintaxis.

Az eredmények néha meglepőek a kereshető mezők lekérdezésekor. A tokenizer olyan logikát tartalmaz, amely az angol nyelvű szövegekben gyakran használt eseteket kezeli, például aposztrófokat, számokat vesszőket stb. Például a "search=123,456" kifejezés egyetlen "123 456" kifejezésre fog illeszkedni az "123" és a "456" egyedi kifejezés helyett, mivel a vesszőket a nagy számok ezreselválasztóként használják angol nyelven. Ezért a keresési paraméterben a kifejezések elválasztása érdekében írásjelek helyett térköz használatát javasoljuk.
searchMode (keresési mód) sztring Választható. Érvényes értékek: "any" vagy "all" Defaults to "any". Megadja, hogy a keresési kifejezéseket vagy az összeset meg kell-e egyeznie ahhoz, hogy a dokumentum egyezésként legyen megszámolva.
searchFields sztring Választható. A megadott szöveg keresését vesszővel elválasztott mezőnevek listája. A célmezőket kereshetőként kell megjelölni az indexsémában.
$select sztring Választható. Az eredményhalmazba foglalható, vesszővel elválasztott mezők listája. Ebben a záradékban csak a lekértként megjelölt mezőket lehet szerepelni. Ha nincs meghatározva, vagy a beállítása , akkor a leképezés a sémában lekértként megjelölt összes * mezőt tartalmazza. Post használatával hívva ennek a paraméternek a neve select, nem pedig $select.
Munkamenet sztring Választható. A sessionId használatával javítható a relevanciapontszám-konzisztencia a több replikával rendelkező keresési szolgáltatásoknál. A több replikakonfigurációk esetében kismértékű eltéréseket mutathat az egy adott lekérdezéshez használható egyes dokumentumok relevanciapontszáma között. Ha meg van adva egy munkamenet-azonosító, a szolgáltatás mindent megtesz, hogy egy adott kérést az adott munkamenetnek megfelelő replikára irányít. Legyen óvatos, hogy ugyanazon munkamenet-azonosítók értékeinek ismételt ismételt igénylése megzavarhatja a kérések terheléselosztását a replikák között, és kedvezőtlen hatással lehet a keresési szolgáltatás teljesítményére. A sessionId érték nem kezdődhet "_" karakterrel. Ha egy szolgáltatás nem rendelkezik replikával, ez a paraméter nincs hatással a teljesítményre vagy a pontszám konzisztenciára.
$skip egész szám Választható. A kihagyott keresési eredmények száma. A POST használatával való hívatáskor ennek a paraméternek a neve skip ( kihagyás) a $skip. Ez az érték nem lehet nagyobb 100 000-től. Ha egymás után kell beolvasnia a dokumentumokat, de ez a korlátozás miatt nem tudja használni a $skip-t, fontolja meg az $orderby használatát egy olyan mezőn, amely az index minden dokumentumához egyedi értékekkel rendelkezik (például a dokumentumkulcshoz), és ehelyett tartománylekérdezéssel $filter-t használ.
speller (előzetes verzió) Sztring Választható. Az érvényes értékek a "none" és a "lexikon". Az alapértelmezett érték a "nincs". A felidézés javítása az egyes keresési lekérdezési kifejezések helyesírásának kijavítása által. Egyszerű, teljes és szemantikai lekérdezéstípusokhoz is használható. Ha használja, a helyesírás-ellenőrző paraméterhez queryLanguage szükséges. További információkért és példákért lásd: Helyesírás-ellenőrzés hozzáadása a lekérdezésekhez.
$top egész szám Választható. A lekért keresési eredmények száma. Ez az alapértelmezett érték 50. A POST használatával való hívatáskor a paraméter neve top, nem pedig $top. Ha 1000-esnél nagyobb értéket ad meg, és több mint 1000 találatot ad meg, a rendszer csak az első 1000 eredményt adja vissza, az eredmények következő oldalára mutató hivatkozással együtt (lásd az alábbi példában a @odata.nextLink "" értéket).

Azure Cognitive Search kiszolgálóoldali lapozás használatával megakadályozza, hogy a lekérdezések egyszerre túl sok dokumentumot lekérdeznek. Az alapértelmezett oldalméret 50, a maximális oldalméret pedig 1000. Ez azt jelenti, hogy a Dokumentumok keresése alapértelmezés szerint 50 találatot ad vissza, ha nem ad meg $top. Ha több mint 50 találatot kapott, a válasz az alábbi példákban a következő oldal lekérését tartalmazza ( lásd: @odata.nextLink " és " @search.nextPageParameters ). Hasonlóképpen, ha az $top-hez 1000-esnél nagyobb értéket ad meg, és több mint 1000 találatot ad vissza, csak az első 1000 eredmény lesz visszaadva, és a rendszer a következő oldal legalább 1000 eredményre vonatkozó információit adja vissza.

Reagálás

Állapotkód: Sikeres válasz esetén a 200 OK érték lesz visszaadva. Ebben a cikkben két mintaválasz található, egy-egy a featuresMode (funkciók) és a szemantikai keresés (szemantikai keresés) esetében.

Az első példa a "felhők űrlapja" szemantikai lekérdezés legfelső szintű eredményére adott teljes választ mutatja.

  • " akkor jelenik meg, ha megadja a válaszparamétert, és ha a lekérdezés és a mögöttes searchFields mezői elősegítik @search.answers a válaszok előállítását. A @search.answers kulcsot, szöveget és kiemelést tartalmazó tömb. A pontszám a válasz erősségét jelzi.

  • A "value" a válasz törzse. A a szemantikai rangsorolási algoritmus által van hozzárendelve, és az eredmények rangsorolására használatos ( a kezdeti eredmények pontozásakor használt @search.rerankerScore @search.score BM25 hasonlóság algoritmusból áll). A feliratok egyszerű szöveget és kiemelt verziókat tartalmaznak. Ez a példa OCR- és entitásfelismerési képességek használatával lett létrehozva. A kinyert és egyesített tartalom mezői szerepelnek a válaszban.

{
    "@search.answers": [
        {
            "key": "aHR0cHM6Ly9oZWlkaXN0YmxvYnN0b3JhZ2UuYmxvYi5jb3JlLndpbmRvd3MubmV0L25hc2EtZWJvb2stMS01MC9wYWdlLTQ1LnBkZg2",
            "text": "Sunlight heats the land all day, warming that moist air and causing it to rise high into the   atmosphere until it cools and condenses into water droplets. Clouds generally form where air is ascending (over land in this case),   but not where it is descending (over the river).",
            "highlights": "Sunlight heats the land all day, warming that moist air and causing it to rise high into the   atmosphere until it cools and condenses into water droplets. Clouds generally form<em> where air is ascending</em> (over land in this case),   but not where it is<em> descending</em> (over the river).",
            "score": 0.94639826
        }
    ],
    "value": [
        {
            "@search.score": 0.5479723,
            "@search.rerankerScore": 1.0321671911515296,
            "@search.captions": [
                {
                    "text": "Like all clouds, it forms when the air reaches its dew point—the temperature at    which an air mass is cool enough for its water vapor to condense into liquid droplets. This false-color image shows valley fog, which is common in the Pacific Northwest of North America.",
                    "highlights": "Like all<em> clouds</em>, it<em> forms</em> when the air reaches its dew point—the temperature at    which an air mass is cool enough for its water vapor to condense into liquid droplets. This false-color image shows valley<em> fog</em>, which is common in the Pacific Northwest of North America."
                }
            ],
            "content": "\nA\nT\n\nM\nO\n\nS\nP\n\nH\nE\n\nR\nE\n\nE\nA\n\nR\nT\n\nH\n\n34\n\nValley Fog\nCanada\n\nFog is essentially a cloud lying on the ground. Like all clouds, it forms when the air reaches its dew point—the temperature at  \n\nwhich an air mass is cool enough for its water vapor to condense into liquid droplets.\n\nThis false-color image shows valley fog, which is common in the Pacific Northwest of North America. On clear winter nights, the \n\nground and overlying air cool off rapidly, especially at high elevations. Cold air is denser than warm air, and it sinks down into the \n\nvalleys. The moist air in the valleys gets chilled to its dew point, and fog forms. If undisturbed by winds, such fog may persist for \n\ndays. The Terra satellite captured this image of foggy valleys northeast of Vancouver in February 2010.\n\n\n",
            "metadata_storage_path": "aHR0cHM6Ly9oZWlkaXN0YmxvYnN0b3JhZ2UuYmxvYi5jb3JlLndpbmRvd3MubmV0L25hc2EtZWJvb2stMS01MC9wYWdlLTQxLnBkZg2",
            "people": [],
            "locations": [
                "Pacific Northwest",
                "North America",
                "Vancouver"
            ],
            "merged_content": "\nA\nT\n\nM\nO\n\nS\nP\n\nH\nE\n\nR\nE\n\nE\nA\n\nR\nT\n\nH\n\n34\n\nValley Fog\nCanada\n\nFog is essentially a cloud lying on the ground. Like all clouds, it forms when the air reaches its dew point—the temperature at  \n\nwhich an air mass is cool enough for its water vapor to condense into liquid droplets.\n\nThis false-color image shows valley fog, which is common in the Pacific Northwest of North America. On clear winter nights, the \n\nground and overlying air cool off rapidly, especially at high elevations. Cold air is denser than warm air, and it sinks down into the \n\nvalleys. The moist air in the valleys gets chilled to its dew point, and fog forms. If undisturbed by winds, such fog may persist for \n\ndays. The Terra satellite captured this image of foggy valleys northeast of Vancouver in February 2010.\n\n\n",
            "text": [],
            "layoutText": []
        }

Ez a példa egy featuresMode (funkciókat) tartalmazó lekérdezés @search.features "" kimenetét mutatja be.

  {
    "@odata.count": # (if $count=true was provided in the query),
    "@search.coverage": # (if minimumCoverage was provided in the query),
    "@search.facets": { (if faceting was specified in the query)
      "facet_field": [
        {
          "value": facet_entry_value (for non-range facets),
          "from": facet_entry_value (for range facets),
          "to": facet_entry_value (for range facets),
          "count": number_of_documents
        }
      ],
      ...
    },
    "@search.nextPageParameters": { (request body to fetch the next page of results if not all results could be returned in this response and Search was called with POST)
      "count": ... (value from request body if present),
      "facets": ... (value from request body if present),
      "featuresMode" : ... (value from request body if present),
      "filter": ... (value from request body if present),
      "highlight": ... (value from request body if present),
      "highlightPreTag": ... (value from request body if present),
      "highlightPostTag": ... (value from request body if present),
      "minimumCoverage": ... (value from request body if present),
      "orderby": ... (value from request body if present),
      "scoringParameters": ... (value from request body if present),
      "scoringProfile": ... (value from request body if present),
      "scoringStatistics": ... (value from request body if present),
      "search": ... (value from request body if present),
      "searchFields": ... (value from request body if present),
      "searchMode": ... (value from request body if present),
      "select": ... (value from request body if present),
      "sessionId" : ... (value from request body if present),
      "skip": ... (page size plus value from request body if present),
      "top": ... (value from request body if present minus page size),
    },
    "value": [
      {
        "@search.score": document_score (if a text query was provided),
        "@search.highlights": {
          field_name: [ subset of text, ... ],
          ...
        },
        "@search.features": {
          "field_name": {
            "uniqueTokenMatches": feature_score,
            "similarityScore": feature_score,
            "termFrequency": feature_score,
          },
          ...
        },
        key_field_name: document_key,
        field_name: field_value (retrievable fields or specified projection),
        ...
      },
      ...
    ],
    "@odata.nextLink": (URL to fetch the next page of results if not all results could be returned in this response; Applies to both GET and POST)
  }

Példák

További példákat az OData expression Syntax for Azure Cognitive Search.

  1. Meghívhatja a szemantikus rangsorolási modellt válaszokkal, feliratokkal és kiemelt tartalommal. A lekérdezésre adott válasz az előző szakaszban található.

    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview 
    {
      "search": "how do clouds form",
      "queryType": "semantic",
      "queryLanguage": "en-us",
      "answers": "extractive",
      "count": "true"
    }
    
  2. Keresés az Indexben dátum szerint csökkenő sorrendben:

    GET /indexes/hotels/docs?search=*&$orderby=LastRenovationDate desc&api-version=2020-06-30-Preview 
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview 
        {  
          "search": "*",  
          "orderby": "LastRenovationDate desc"
        }  
    
  3. A jellemzős keresések esetében az indexben kereshet, és lekérheti a kategóriákat, értékeléseket, címkéket, valamint a baseRate értékkel megadott tartományokban található elemeket.

    GET /indexes/hotels/docs?search=*&facet=Category&facet=Rating&facet=Tags&facet=Rooms/BaseRate,values:80|150|220&api-version=2020-06-30-Preview  
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview
        {  
          "search": "test",  
          "facets": [ "Category", "Rating", "Tags", "Rooms/BaseRate,values:80|150|220" ]  
        }  
    

    Figyelje meg, hogy az utolsó a facet egy almezőn van. Az a facets (a facets) a szülődokumentumot (Hotels) és nem a köztes aldokumentumokat (Szoba) számolja, így a válasz határozza meg az egyes árkategóriákban található helyiségek számát.

  4. Egy szűrő használatával szűkítse le az előző a faceted lekérdezés eredményét, miután a felhasználó kiválasztotta a Rating 3 (Minősítés 3) és a Category "Hotel" kategóriát.

    GET /indexes/hotels/docs?search=*&facet=tags&facet=Rooms/BaseRate,values:80|150|220&$filter=Rating eq 3 and Category eq 'Motel'&api-version=2020-06-30-Preview  
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview 
        {  
          "search": "test",  
          "facets": [ "tags", "Rooms/BaseRate,values:80|150|220" ],  
          "filter": "Rating eq 3 and Category eq 'Motel'"  
        }  
    
  5. A faceted (akorlátos) keresésben állítson be egy felső korlátot a lekérdezésben visszaadott egyedi kifejezésekre. Az alapértelmezett érték 10, de ezt az értéket a facet attribútum count paraméterével növelheti vagy csökkentheti. Ez a példa 5-re korlátozott ad vissza értékeket a városhoz.

    GET /indexes/hotels/docs?search=*&facet=Address/City,count:5&api-version=2020-06-30-Preview  
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview 
        {  
          "search": "test",  
          "facets": [ "Address/City,count:5" ]  
        }  
    
  6. Keresés az Indexben adott mezőkben (például egy nyelvi mezőben):

    GET /indexes/hotels/docs?search=hôtel&searchFields=Description_fr&api-version=2020-06-30-Preview  
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview 
        {  
          "search": "hôtel",  
          "searchFields": "Description_fr"
        }  
    
  7. Keresés az Indexben több mezőben. Például több nyelven is tárolhat és lekérdezhet kereshető mezőket, amelyek mind ugyanazon az indexen belül találhatóak. Ha ugyanabban a dokumentumban angol és francia nyelvű leírások is léteznek, a lekérdezési eredmények bármelyikét vagy mindegyikét visszaadhatja:

    GET /indexes/hotels/docs?search=hotel&searchFields=Description,Description_fr&api-version=2020-06-30-Preview
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview
        {  
          "search": "hotel",  
          "searchFields": "Description, Description_fr"
        }  
    

    Egyszerre csak az indexet lehet lekérdezni. Csak akkor hozzon létre több indexet minden nyelvhez, ha egyszerre egy lekérdezést tervez.

  8. Lapozás – Az elemek első oldalának lezása (az oldalméret 10):

    GET /indexes/hotels/docs?search=*&$skip=0&$top=10&api-version=2020-06-30-Preview 
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview
        {  
          "search": "*",  
          "skip": 0,  
          "top": 10  
        }  
    
  9. Lapozás – Az elemek második oldalának lezása (az oldalméret 10):

    GET /indexes/hotels/docs?search=*&$skip=10&$top=10&api-version=2020-06-30-Preview 
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview
        {  
          "search": "*",  
          "skip": 10,  
          "top": 10  
        }  
    
  10. Adott mezőkészlet lekérése:

    GET /indexes/hotels/docs?search=*&$select=HotelName,Description&api-version=2020-06-30-Preview  
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview  
        {  
          "search": "*",  
          "select": "HotelName, Description"
        }  
    
  11. Egy adott szűrőkifejezésnek megfelelő dokumentumok lekérése:

    GET /indexes/hotels/docs?$filter=(Rooms/BaseRate ge 60 and Rooms/BaseRate lt 300) or HotelName eq 'Fancy Stay'&api-version=2020-06-30-Preview  
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview  
        {  
          "filter": "(Rooms/BaseRate ge 60 and Rooms/BaseRate lt 300) or HotelName eq 'Fancy Stay'"  
        }  
    
  12. Keresse meg az indexet, és adja vissza a töredékeket a találatok kiemelése után:

    GET /indexes/hotels/docs?search=something&highlight=Description&api-version=2020-06-30-Preview
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview 
        {  
          "search": "something",  
          "highlight": "Description"  
        }  
    
  13. Keresse meg az indexet, és adja vissza a referenciahelytől közelebbről távolabb található dokumentumokat:

    GET /indexes/hotels/docs?search=something&$orderby=geo.distance(Location, geography'POINT(-122.12315 47.88121)')&api-version=2020-06-30-Preview 
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview
        {  
          "search": "something",  
          "orderby": "geo.distance(Location, geography'POINT(-122.12315 47.88121)')"
        }  
    
  14. Ha az indexben van egy "geo" nevű pontozási profil két távolságpontozási funkcióval, az egyik a "currentLocation" paramétert, a másik pedig a "lastLocation" paramétert definiálja:

    GET /indexes/hotels/docs?search=something&scoringProfile=geo&scoringParameter=currentLocation--122.123,44.77233&scoringParameter=lastLocation--121.499,44.2113&api-version=2020-06-30-Preview 
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview
        {  
          "search": "something",  
          "scoringProfile": "geo",  
          "scoringParameters": [ "currentLocation--122.123,44.77233", "lastLocation--121.499,44.2113" ]  
        }  
    
  15. Dokumentumokat keres az indexben egyszerű lekérdezési szintaxissal. Ez a lekérdezés olyan szállodákat ad vissza, ahol a kereshető mezők tartalmazzák a "kényelmi" és a "hely" kifejezéseket, de a "."." kifejezéseket nem:

    Get /indexes/hotels/docs?search=comfort +location –motel&searchMode=all&api-version=22020-06-30-Preview
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview
        {  
          "search": "comfort +location -motel",  
          "searchMode": "all"  
        }  
    

    Tipp

    A használata felülbírálja az alapértelmezett beállítását, így az searchMode=all "OR NOT" helyett az searchMode=any -motel "AND NOT" értéket jelenti. A nélkül az "OR NOT" kifejezés fog bővülni ahelyett, hogy korlátozná a keresési eredményeket, és ez egyes felhasználók számára magától értetődő searchMode=all lehet.

  16. Dokumentumokat keres az indexben Lucene lekérdezési szintaxissal (lásd a Lucene lekérdezési szintaxista Azure Cognitive Search). Ez a lekérdezés olyan szállodákat ad vissza, ahol a category mező tartalmazza a "budget" kifejezést és az összes kereshető mezőt, amely tartalmazza a "recently recently edd" kifejezést. A "nemrégiben lekiáltott" kifejezést tartalmazó dokumentumok magasabb prioritást képviselnek a boost value (kiemelési érték) kifejezés eredményeként (3)

    GET /indexes/hotels/docs?search=Category:budget AND \"recently renovated\"^3&searchMode=all&api-version=2020-06-30-Preview&querytype=full` 
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview
        {  
         "search": "Category:budget AND \"recently renovated\"^3",  
          "queryType": "full",  
          "searchMode": "all"  
    }  
    
  17. Dokumentumokat keres az indexben, és a konzisztens pontozást támogatja az alacsonyabb késéssel. Ez a lekérdezés kiszámítja a dokumentum gyakoriságát a teljes indexben, és mindent megtesz, hogy ugyanazt a replikát célozza meg az összes lekérdezéshez ugyanazon a "munkameneten" belül, ami segít a stabil és reprodukálható rangsorolás létrehozásában.

    GET /indexes/hotels/docs?search=hotel&sessionId=mySessionId&scoringStatistics=global&api-version=2020-06-30-Preview
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview
        {  
          "search": "hotel",  
          "sessionId": "mySessionId",
          "scoringStatistics" :"global"
        }  
    
  18. Dokumentumokat keres az indexben, és visszaadja az egyes eredményekhez az információlekérési funkciók listáját, amely leírja az egyező dokumentum és a lekérdezés közötti pontozást. A lekérdezés a dokumentum gyakoriságát is kiszámítja a teljes indexben, így konzisztensebb pontozást hoz létre.

    GET /indexes/hotels/docs?search=hotel&featuresMode=enabled&scoringStatistics=global&api-version=2020-06-30-Preview 
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30-Preview
        {  
          "search": "hotel",  
          "featuresMode": "enabled",
          "scoringStatistics" :"global"
        }  
    

    A választ tartalmazó példa a search.features következőre hasonlít:

        "@search.score": 0.91875637,
        "@search.features": {
            "Description": {
                "uniqueTokenMatches": 1,
                "similarityScore": 0.2917966,
                "termFrequency": 2
            },
            "HotelName": {
                "uniqueTokenMatches": 1,
                "similarityScore": 0.44458693,
                "termFrequency": 1
            }
          . . .
    
    

Definitions

This section provides details about parameters that are too complex to cover in the main table.

queryLanguage

queryLanguage

Valid values for the queryLanguage parameter are provided in the following table, in the "queryLanguage" column, and are not case-sensitive. The default for the parameter as a whole is "en-us". Within each language, there is a default variant for each two-character language code. For example, if you specify "es", then "es-us" is used by default. The queryLanguage parameter is required for a query request that includes "queryType=semantic" or "speller=lexicon". There is only one queryLanguage value for the entire request, and that value will be used for semantic ranking, captions, answers, and speller (there is no override for individual features).

At this time, language support varies by feature. Only English, Spanish, French, and German are supported for the full set of features, but notice that spell check implements fewer variants.

If you specify a language code that is not supported by a given feature, such as EN-GB with speller, the service will return HTTP 400.

For more information about using each feature, see Enable semantic ranking and captions, Return a semantic answer, and Add spell check to queries.

The "(preview)" designation indicates that validation testing across all features (semantic ranking, captions, answers, and spell check) is either ongoing or pending. We encourage the use of all of the language variants in the following table, but recommend additional testing of preview languages to ensure the results are valid for your content. Languages with a green check and no preview designation have been validated using equivalent data sets, with measurable gain in relevance.

Language queryLanguage Semantic ranker and captions Semantic answer Speller
English [EN] EN, EN-US (default), EN-GB, EN-IN, EN-CA, EN-AU ✔️ ✔️ ✔️ (EN, EN-US)
French [FR] FR, FR-FR (default), FR-CA ✔️ ✔️ ✔️ (FR, FR-FR)
German [DE] DE, DE-DE (default) ✔️ ✔️ ✔️ (DE, DE-DE)
Spanish [ES] ES, ES-ES (default), ES-MX ✔️ ✔️ ✔️ (ES, ES-ES)
Italian [IT] IT, IT-IT (default) ✔️ ✔️
Japanese [JA] JA, JA-JP (default) ✔️ ✔️ (preview)
Chinese [ZH] ZH, ZH-CN (default), ZH-TW ✔️ ✔️ (preview)
Portuguese [PT] PT, PT-BR (default), PT-PT ✔️ ✔️ (preview)
Dutch [NL] NL, NL-BE, NL-NL (default) ✔️ (preview) ✔️ (preview) ✔️ (NL, NL-NL)
Arabic [AR] AR, AR-SA (default), AR-EG, AR-MA. AR-KW, AR-JO ✔️ (preview) ✔️ (preview)
Armenian hy-AM (default) ✔️ (preview) ✔️ (preview)
Bangla bn-IN (default) ✔️ (preview) ✔️ (preview)
Basque eu-ES (default) ✔️ (preview) ✔️ (preview)
Bulgarian [BG] BG, BG-BG (default) ✔️ (preview) ✔️ (preview)
Catalan [CA] CA, CA-ES (default) ✔️ (preview) ✔️ (preview)
Croatian [HR] HR, HR-HR (default), HR-BA ✔️ (preview) ✔️ (preview)
Czech [CS] CS, CS-CZ (default) ✔️ (preview) ✔️ (preview)
Danish [DA] DA, DA-DK (default) ✔️ (preview) ✔️ (preview)
Estonian [ET] ET, ET-EE (default) ✔️ (preview) ✔️ (preview)
Finnish [FI] FI, FI-FI (default) ✔️ (preview) ✔️ (preview)
Galician gl-ES (default) ✔️ (preview) ✔️ (preview)
Greek [EL] EL, EL-GR (default) ✔️ (preview) ✔️ (preview)
Gujarati gu-IN (default) ✔️ (preview) ✔️ (preview)
Hebrew he-IL (default) ✔️ (preview) ✔️ (preview)
Hindi [HI] HI, HI-IN (default) ✔️ (preview) ✔️ (preview)
Icelandic [IS] IS, IS-IS (default) ✔️ (preview) ✔️ (preview)
Indonesian [ID] ID, ID-ID (default) ✔️ (preview) ✔️ (preview)
Irish ga-IE (default) ✔️ (preview) ✔️ (preview)
Kannada kn-IN (default) ✔️ (preview) ✔️ (preview)
Korean [KO] KO, KO-KR (default) ✔️ (preview) ✔️ (preview)
Latvian [LV] LV, LV-LV (default) ✔️ (preview) ✔️ (preview)
Lithuanian [LT] LT, LT-LT (default) ✔️ (preview) ✔️ (preview)
Malayalam ml-IN (default) ✔️ (preview) ✔️ (preview)
Malaysian [MS] MS, MS-MY (default), MS-BN ✔️ (preview) ✔️ (preview)
Marathi mr-IN (default) ✔️ (preview) ✔️ (preview)
Norwegian [NO] NO, NO-NO (default) ✔️ (preview) ✔️ (preview)
Persian fa-AE (default) ✔️ (preview) ✔️ (preview)
Polish [PL] PL, PL-PL (default) ✔️ (preview) ✔️ (preview)
Punjabi pa-IN (default) ✔️ (preview) ✔️ (preview)
Romanian [RO] RO, RO-RO (default) ✔️ (preview) ✔️ (preview)
Russian [RU] RU, RU-RU (default) ✔️ (preview) ✔️ (preview)
Serbian [SR] (Cyrillic or Latin) SR, SR-BA (default), SR-ME, SR-RS ✔️ (preview) ✔️ (preview)
Slovak [SK] SK, SK-SK (default) ✔️ (preview) ✔️ (preview)
Slovenian [SL] SL, SL-SL (default) ✔️ (preview) ✔️ (preview)
Tamil [TA] TA, TA-IN (default) ✔️ (preview) ✔️ (preview)
Swedish [SV] SV, SV-SE (default) ✔️ (preview) ✔️ (preview)
Telugu te-IN (default) ✔️ (preview) ✔️ (preview)
Thai [TH] TH, TH-TH (default) ✔️ (preview) ✔️ (preview)
Turkish [TR] TR, TR-TR (default) ✔️ (preview) ✔️ (preview)
Ukrainian [UK] UK, UK-UA (default) ✔️ (preview) ✔️ (preview)
Urdu ur-PK (default) ✔️ (preview) ✔️ (preview)
Vietnamese [VA] VA, VI-VN (default) ✔️ (preview) ✔️ (preview)

See also