SpellCheckClient.SpellCheckerWithHttpMessagesAsync Méthode

Référence

Définition

Espace de noms:: Microsoft.Azure.CognitiveServices.Language.SpellCheck

Assembly:: Microsoft.Azure.CognitiveServices.Language.SpellCheck.dll

Paquet:: Microsoft.Azure.CognitiveServices.Language.SpellCheck v4.0.0

Paquet:: Microsoft.Azure.CognitiveServices.Language.SpellCheck v4.1.0-preview.1

Source:: SpellCheckClient.cs

Important

Certaines informations portent sur la préversion du produit qui est susceptible d’être en grande partie modifiée avant sa publication. Microsoft exclut toute garantie, expresse ou implicite, concernant les informations fournies ici.

L’API Vérification orthographique Bing vous permet d’effectuer une vérification orthographique et grammaticale contextuelle. Bing a développé un vérificateur orthographique basé sur le web, qui utilise l’apprentissage automatique et la traduction automatique statistique pour entraîner et mettre à jour en continu un algorithme en constante évolution et hautement contextuel. Le vérificateur orthographique repose sur un important recueil de documents et de recherches sur le web.

public System.Threading.Tasks.Task<Microsoft.Rest.HttpOperationResponse<Microsoft.Azure.CognitiveServices.Language.SpellCheck.Models.SpellCheckModel>> SpellCheckerWithHttpMessagesAsync (string text, string acceptLanguage = default, string pragma = default, string userAgent = default, string clientId = default, string clientIp = default, string location = default, string actionType = default, string appName = default, string countryCode = default, string clientMachineName = default, string docId = default, string market = default, string sessionId = default, string setLang = default, string userId = default, string mode = default, string preContextText = default, string postContextText = default, System.Collections.Generic.Dictionary<string,System.Collections.Generic.List<string>> customHeaders = default, System.Threading.CancellationToken cancellationToken = default);

abstract member SpellCheckerWithHttpMessagesAsync : string * string * string * string * string * string * string * string * string * string * string * string * string * string * string * string * string * string * string * System.Collections.Generic.Dictionary<string, System.Collections.Generic.List<string>> * System.Threading.CancellationToken -> System.Threading.Tasks.Task<Microsoft.Rest.HttpOperationResponse<Microsoft.Azure.CognitiveServices.Language.SpellCheck.Models.SpellCheckModel>>
override this.SpellCheckerWithHttpMessagesAsync : string * string * string * string * string * string * string * string * string * string * string * string * string * string * string * string * string * string * string * System.Collections.Generic.Dictionary<string, System.Collections.Generic.List<string>> * System.Threading.CancellationToken -> System.Threading.Tasks.Task<Microsoft.Rest.HttpOperationResponse<Microsoft.Azure.CognitiveServices.Language.SpellCheck.Models.SpellCheckModel>>

Public Function SpellCheckerWithHttpMessagesAsync (text As String, Optional acceptLanguage As String = Nothing, Optional pragma As String = Nothing, Optional userAgent As String = Nothing, Optional clientId As String = Nothing, Optional clientIp As String = Nothing, Optional location As String = Nothing, Optional actionType As String = Nothing, Optional appName As String = Nothing, Optional countryCode As String = Nothing, Optional clientMachineName As String = Nothing, Optional docId As String = Nothing, Optional market As String = Nothing, Optional sessionId As String = Nothing, Optional setLang As String = Nothing, Optional userId As String = Nothing, Optional mode As String = Nothing, Optional preContextText As String = Nothing, Optional postContextText As String = Nothing, Optional customHeaders As Dictionary(Of String, List(Of String)) = Nothing, Optional cancellationToken As CancellationToken = Nothing) As Task(Of HttpOperationResponse(Of SpellCheckModel))

Paramètres

text: String

Chaîne de texte à case activée pour les erreurs d’orthographe et de grammaire. La longueur combinée de la chaîne de texte, de la chaîne preContextText et de la chaîne postContextText ne peut pas dépasser 10 000 caractères. Vous pouvez spécifier ce paramètre dans la chaîne de requête d’une requête GET ou dans le corps d’une requête POST. En raison de la limite de longueur des chaînes de requête, vous utilisez généralement une requête POST, sauf si vous vérifiez uniquement les chaînes courtes.

acceptLanguage: String

Liste délimitée par des virgules d’une ou plusieurs langues à utiliser pour les chaînes d’interface utilisateur. Elle est triée par ordre de préférence décroissant. Pour plus d’informations, notamment sur le format attendu, consultez RFC2616. Cet en-tête et le paramètre de requête setLang s’excluent mutuellement ; ne spécifiez pas les deux. Si vous définissez cet en-tête, vous devrez également spécifier le paramètre de requête cc. Bing utilise la première langue prise en charge qu’il trouve dans la liste et combine cette langue avec la valeur du paramètre cc pour déterminer le marché pour lequel retourner des résultats. Si la liste n’inclut pas de langue prise en charge, Bing recherche la langue et le marché les plus proches qui prennent en charge la demande, et peut utiliser un marché agrégé ou par défaut pour les résultats au lieu d’un marché spécifié. Vous devez utiliser cet en-tête et le paramètre de requête cc uniquement si vous spécifiez plusieurs langues ; sinon, vous devez utiliser les paramètres de requête mkt et setLang. Une chaîne d’interface utilisateur est une chaîne utilisée comme étiquette dans une interface utilisateur. Il existe très peu de chaînes d’interface utilisateur dans les objets de réponse JSON. Tous les liens dans les objets de réponse vers Bing.com propriétés appliqueront la langue spécifiée.

pragma: String

Par défaut, Bing retourne le contenu en cache, s’il est disponible. Pour éviter cela, définissez l’en-tête Pragma sur no-cache (par exemple, Pragma: no-cache).

userAgent: String

Agent utilisateur à l’origine de la requête. Bing utilise l’agent utilisateur pour offrir une expérience optimisée aux utilisateurs mobiles. Bien que facultatif, nous vous recommandons vivement de toujours spécifier cet en-tête. L’agent utilisateur doit être la même chaîne que n’importe quel navigateur couramment utilisé envoyer. Pour plus d’informations sur les agents utilisateurs, voir RFC 2616.

clientId: String

Bing utilise cet en-tête pour garantir aux utilisateurs un comportement cohérent d’un appel d’API Bing à l’autre. Bing propose souvent de nouvelles fonctionnalités et améliorations, et se sert de l’ID client comme d’une clé pour attribuer le trafic aux différentes versions d’évaluation. Si vous n’assignez pas le même ID client à un utilisateur d’une demande à l’autre, Bing est susceptible d’affecter cet utilisateur à plusieurs versions d’évaluation en conflit, ce qui risque de nuire à l’expérience utilisateur. Par exemple, si la deuxième demande comporte une attribution de version d’évaluation différente de la première, l’expérience se révélera peut-être inattendue. De même, Bing peut utiliser l’ID client pour personnaliser les résultats web d’après l’historique de recherche correspondant à cet ID et ainsi proposer à l’utilisateur une expérience plus riche. Bing utilise également cet en-tête pour aider à améliorer le classement des résultats en analysant l’activité générée par un ID client. L’amélioration de la pertinence permet d’obtenir des résultats de meilleure qualité de la part des API Bing et, en retour, des taux de clic plus élevés pour le consommateur des API. IMPORTANT : Il est vivement recommandé d’indiquer cet en-tête, bien qu’il soit facultatif. Grâce à la persistance de l’ID client dans plusieurs demandes pour une même combinaison appareil/utilisateur final, (1) le consommateur des API bénéficie d’une expérience utilisateur cohérente et (2) le taux de clic est plus élevé du fait des résultats de meilleure qualité provenant des API Bing. Chaque utilisateur de votre application sur l’appareil doit avoir un ID client unique, généré par Bing. Si vous n’insérez pas cet en-tête dans la demande, Bing génère un ID et le retourne dans l’en-tête de réponse X-MSEdge-ClientID. La première fois que l’utilisateur utilise votre application sur cet appareil est la seule fois où vous ne devez PAS inclure cet en-tête dans la demande. Utilisez l’ID client pour chaque requête d’API Bing qu’effectue votre application pour cet utilisateur sur l’appareil. Conservez l’ID client. Pour conserver l’identifiant dans une application de navigateur, utilisez un cookie HTTP persistant qui garantit l’utilisation de cet identifiant dans toutes les sessions. N’utilisez pas de cookie de session. Dans le cas d’autres applications, comme des applications mobiles, utilisez le stockage persistant de l’appareil pour conserver cet identifiant. La prochaine fois que l’utilisateur utilisera votre application sur cet appareil, vous récupérerez l’ID client que vous aurez conservé. Les réponses de Bing ne comportent pas forcément cet en-tête. Si elles l’incluent, capturez l’ID client et utilisez-le pour toutes les demandes Bing suivantes concernant l’utilisateur sur cet appareil. Si vous insérez l’en-tête X-MSEdge-ClientID, n’incluez pas les cookies dans la requête.

clientIp: String

Adresse IPv4 ou IPv6 de l’appareil client. L’adresse IP est utilisée pour découvrir l’emplacement de l’utilisateur. Bing utilise les informations de localisation pour déterminer le comportement de recherche approprié. Nous vous conseillons de toujours indiquer cet en-tête et l’en-tête X-Search-Location, bien qu’ils soient facultatifs. N’obfusquez pas l’adresse (par exemple, en remplaçant le dernier octet par 0). Cela aurait pour effet d’éloigner la localisation de l’emplacement réel de l’appareil, ce qui pourrait conduire Bing à retourner des résultats erronés.

location: String

Liste délimitée par des points-virgules de paires clé/valeur qui décrivent la situation géographique du client. Bing utilise les informations de localisation pour déterminer le comportement de recherche approprié et retourner le contenu local pertinent. Spécifiez la paire clé/valeur sous la forme <clé>:<valeur>. Voici les clés permettant de spécifier l’emplacement de l’utilisateur. lat (obligatoire) : latitude de l’emplacement du client, en degrés. Elle doit être supérieure ou égale à -90,0 et inférieure ou égale à +90,0. Les valeurs négatives indiquent les latitudes sud et les valeurs positives les latitudes nord. long (obligatoire) : longitude de l’emplacement du client, en degrés. Elle doit être supérieure ou égale à -180,0 et inférieure ou égale à +180,0. Les valeurs négatives indiquent les longitudes occidentales et les valeurs positives les longitudes orientales. re (obligatoire) : rayon, en mètres, qui spécifie la précision horizontale des coordonnées. Transmettez la valeur retournée par le service de localisation de l’appareil. Voici quelques valeurs courantes : 22 m pour le GPS/Wi-Fi, 380 m pour la triangulation des tours cellulaires et 18 000 m pour la recherche IP inversée. ts (facultatif) : horodatage UNIX UTC du moment où le client se trouvait à l’emplacement. (L’horodatage UNIX correspond au nombre de secondes écoulées depuis le 1er janvier 1970.) head (facultatif) : titre ou sens de déplacement relatif du client. Spécifiez-la en degrés, entre 0 et 360, dans le sens horaire par rapport au nord géographique. Spécifiez cette clé uniquement si la clé sp est différente de zéro. sp (facultatif) : vitesse horizontale (vitesse), en mètres par seconde, que l’appareil client est en train de parcourir. alt (facultatif) : altitude de l’appareil client, en mètres. sont (facultatif) : rayon, en mètres, qui spécifie la précision verticale des coordonnées. Spécifiez cette clé uniquement si vous spécifiez la touche de remplacement. Bien que la plupart des clés soient facultatives, plus vous fournissez d’informations, plus les résultats de localisation sont précis. Nous vous conseillons de toujours indiquer la situation géographique de l’utilisateur (qui est facultative). C’est particulièrement important si l’adresse IP du client ne reflète pas exactement l’emplacement physique de l’utilisateur (par exemple, si le client utilise un VPN). Pour des résultats optimaux, vous devez inclure cet en-tête et l’en-tête X-Search-ClientIP, mais au minimum, vous devez inclure cet en-tête.

actionType: String

Chaîne utilisée par la journalisation pour déterminer si la demande provient d’une session interactive ou d’un chargement de page. Les valeurs possibles sont les suivantes. 1) Modifier : la demande provient d’une session interactive 2) Chargement : la demande provient d’un chargement de page. Les valeurs possibles sont les suivantes : 'Edit', 'Load'

appName: String

Nom unique de votre application. Le nom doit être connu par Bing. N’incluez pas ce paramètre, sauf si vous avez déjà contacté Bing pour obtenir un nom d’application unique. Pour obtenir un nom unique, contactez votre responsable de développement d’entreprise Bing.

countryCode: String

Code à 2 caractères du pays d'où proviennent les résultats. Cette API prend uniquement en charge le marché États-Unis. Si vous spécifiez ce paramètre de requête, il doit être défini sur nous. Si vous définissez ce paramètre, vous devez également spécifier l’en-tête Accept-Language. Bing utilise la première langue prise en charge qu’il trouve dans la liste des langues, et combine cette langue avec le code de pays que vous spécifiez pour déterminer le marché pour lequel retourner des résultats. Si la liste des langues n’inclut pas de langue prise en charge, Bing recherche la langue et le marché les plus proches qui prennent en charge la demande, ou il peut utiliser un marché agrégé ou par défaut pour les résultats au lieu d’un marché spécifié. Vous devez utiliser ce paramètre de requête et le paramètre de requête Accept-Language uniquement si vous spécifiez plusieurs langues ; sinon, vous devez utiliser les paramètres de requête mkt et setLang. Ce paramètre et le paramètre de requête mkt s’excluent mutuellement ; ne spécifiez pas les deux.

clientMachineName: String

Nom unique de l’appareil à partir duquel la demande est effectuée. Générez une valeur unique pour chaque appareil (la valeur n’est pas importante). Le service utilise l’ID pour aider à déboguer les problèmes et améliorer la qualité des corrections.

docId: String

ID unique qui identifie le document auquel le texte appartient. Générez une valeur unique pour chaque document (la valeur n’est pas importante). Le service utilise l’ID pour aider à déboguer les problèmes et améliorer la qualité des corrections.

market: String

Marché d’où proviennent les résultats. Nous vous recommandons vivement de toujours spécifier le marché, s’il est connu. Le fait d’indiquer le marché aide Bing à router la requête et à renvoyer une réponse appropriée et optimale. Ce paramètre et le paramètre de requête cc s’excluent mutuellement ; ne spécifiez pas les deux.

sessionId: String

ID unique qui identifie cette session utilisateur. Générez une valeur unique pour chaque session utilisateur (la valeur n’est pas importante). Le service utilise l’ID pour aider à déboguer les problèmes et améliorer la qualité des corrections

setLang: String

Langue à utiliser pour les chaînes de l’interface utilisateur. Spécifiez la langue en utilisant le code de langue ISO 639-1 à deux lettres. Par exemple, celui de l’anglais est EN. La valeur par défaut est EN (anglais). Nous vous conseillons de toujours indiquer la langue, bien qu’elle soit facultative. En règle générale, vous définissez setLang sur la même langue spécifiée par mkt, sauf si l’utilisateur souhaite que les chaînes d’interface utilisateur soient affichées dans une autre langue. Ce paramètre et l’en-tête Accept-Language s’excluent mutuellement ; ne spécifiez pas les deux. Une chaîne d’interface utilisateur est une chaîne utilisée comme étiquette dans une interface utilisateur. Les objets de réponse JSON en comportent quelques-unes. En outre, les liens vers les propriétés Bing.com dans les objets de la réponse s’appliquent à la langue spécifiée.

userId: String

ID unique qui identifie l’utilisateur. Générez une valeur unique pour chaque utilisateur (la valeur n’est pas importante). Le service utilise l’ID pour aider à déboguer les problèmes et améliorer la qualité des corrections.

mode: String

Type de vérifications orthographiques et grammaticales à effectuer. Voici les valeurs possibles (les valeurs ne respectent pas la casse). La valeur par défaut est Proof. 1) Preuve : recherche la plupart des erreurs d’orthographe et de grammaire. 2) Orthographe : recherche la plupart des fautes d’orthographe, mais ne trouve pas certaines des erreurs de grammaire que Proof intercepte (par exemple, la majuscule et les mots répétés). Les valeurs possibles sont les suivantes : 'proof', 'spell'

preContextText: String

Chaîne qui donne un contexte à la chaîne de texte. Par exemple, le pétale de chaîne de texte est valide. Toutefois, si vous définissez preContextText sur bike, le contexte change et la chaîne de texte devient non valide. Dans ce cas, l’API vous suggère de changer de pétale en pédale (comme dans la pédale de vélo). Ce texte n’est pas vérifié pour détecter les erreurs de grammaire ou d’orthographe. La longueur combinée de la chaîne de texte, de la chaîne preContextText et de la chaîne postContextText ne peut pas dépasser 10 000 caractères. Vous pouvez spécifier ce paramètre dans la chaîne de requête d’une requête GET ou dans le corps d’une requête POST.

postContextText: String

Chaîne qui donne un contexte à la chaîne de texte. Par exemple, la chaîne de texte lue est valide. Toutefois, si vous définissez postContextText sur tapis, le contexte change et la chaîne de texte devient non valide. Dans ce cas, l’API vous suggère de remplacer la lecture par rouge (comme dans le tapis rouge). Ce texte n’est pas vérifié pour détecter les erreurs de grammaire ou d’orthographe. La longueur combinée de la chaîne de texte, de la chaîne preContextText et de la chaîne postContextText ne peut pas dépasser 10 000 caractères. Vous pouvez spécifier ce paramètre dans la chaîne de requête d’une requête GET ou dans le corps d’une requête POST.