你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
SpellCheckClient 类
通过拼写检查 API - V7，可以检查文本字符串来显示拼写和语法错误。
- 继承
-
azure.cognitiveservices.language.spellcheck.operations._spell_check_client_operations.SpellCheckClientOperationsMixinSpellCheckClientSpellCheckClient
构造函数
SpellCheckClient(endpoint, credentials)参数
- endpoint
- str
支持的认知服务终结点 (协议和主机名，例如：“https://westus.api.cognitive.microsoft.com”、“https://api.cognitive.microsoft.com”) 。
变量
客户端的配置。
方法
| close |
如果keep_alive为 True，请关闭客户端。 |
| spell_checker |
必应拼写检查 API 用于执行上下文语法和拼写检查。 必应开发的基于 Web 的拼写检查器充分利用了机器学习和统计性的机器翻译，可以动态训练一种不断发展且高度取决于上下文的算法。 此拼写检查器基于大量的 Web 搜索和文档。 |
close
如果keep_alive为 True，请关闭客户端。
close() -> Nonespell_checker
必应拼写检查 API 用于执行上下文语法和拼写检查。 必应开发的基于 Web 的拼写检查器充分利用了机器学习和统计性的机器翻译，可以动态训练一种不断发展且高度取决于上下文的算法。 此拼写检查器基于大量的 Web 搜索和文档。
spell_checker(text, accept_language=None, pragma=None, user_agent=None, client_id=None, client_ip=None, location=None, action_type=None, app_name=None, country_code=None, client_machine_name=None, doc_id=None, market=None, session_id=None, set_lang=None, user_id=None, mode=None, pre_context_text=None, post_context_text=None, custom_headers=None, raw=False, **operation_config)参数
- text
- str
要检查拼写和语法错误的文本字符串。 文本字符串、preContextText 字符串和 postContextText 字符串的组合长度不能超过 10,000 个字符。 可以在 GET 请求的查询字符串或 POST 请求的正文中指定此参数。 由于查询字符串长度限制，除非仅检查短字符串，否则通常会使用 POST 请求。
- accept_language
- str
用于用户界面字符串的一个或多个语言的逗号分隔列表。 此列表以降序方式显示首选项。 有关其他信息（包括预期格式），请参阅 RFC2616。 此标头和 setLang 查询参数互斥;不要同时指定两者。 如果设置此标头，则还必须指定 cc 查询参数。 必应将使用它从列表中找到的第一种受支持的语言，并将该语言与 cc 参数值组合在一起，以确定要为其返回结果的市场。 如果列表不包含支持的语言，必应将找到支持该请求的最近语言和市场，并且可能会对结果使用聚合市场或默认市场，而不是指定的市场。 仅当指定多种语言时，才应使用此标头和 cc 查询参数;否则，应使用 mkt 和 setLang 查询参数。 用户界面字符串是用作用户界面中标签的字符串。 JSON 响应对象中的用户界面字符串非常少。 响应对象中指向 Bing.com 属性的任何链接都将应用指定的语言。
- pragma
- str
默认情况下，必应返回缓存的内容（如果适用）。 若要防止必应返回缓存的内容，请将 Pragma 标头设置为 no-cache（例如，Pragma: no-cache）。
- user_agent
- str
发出请求的用户代理。 必应使用用户代理为移动用户提供优化体验。 尽管是可选的，但强烈建议始终指定此标头。 用户代理应与任何常用浏览器发送的字符串相同。 有关用户代理的信息，请参阅 RFC 2616。
- client_id
- str
必应使用此标头跨必应 API 调用为用户提供一致的行为。 必应通常会发布新功能和改进，并将客户端 ID 用作密钥以在不同航班上分配客流量。 如果未跨多个请求将相同的客户端 ID 用于用户，则必应可能将用户分配给多个冲突的航班。 分配给多个冲突航班可能导致用户体验不一致。 例如，如果第二个请求与第一个请求的航班分配不同，体验可能会出现意外。 此外，必应可以使用客户端 ID 根据该客户端 ID 的搜索历史记录定制 Web 结果，为用户提供更丰富的体验。 通过分析由客户端 ID 生成的活动，必应还会使用此标头来提高结果排名。 相关改进有助于提高必应 API 交付的结果质量，从而提高 API 客户的点击率。 重要提示：尽管是可选的，但应将此标头视为必选。 对于同一最终用户和设备组合，如果跨多个请求保留客户端 ID，则 1) API 客户可以获取一致的用户体验；2) 可通过必应 API 提高结果质量，从而提高点击率。 在设备上使用你的应用程序的每个用户必须具有必应生成的唯一客户端 ID。 如果未在请求中包含此标头，必应会生成 ID，然后在 X-MSEdge-ClientID 响应标头中将其返回。 仅当用户首次在设备上使用应用时，才不可以在请求中包含此标头。 针对应用为设备上的此用户生成的每个必应 API 请求，使用客户端 ID。 保留客户端 ID。 若要在浏览器应用中保留 ID，请使用持久性 HTTP Cookie 来确保所有会话均使用此 ID。 请勿使用会话 Cookie。 对于移动应用等其他应用，请使用设备的持久存储来保留 ID。 下次用户在该设备上使用你的应用时，会获取保留的客户端 ID。 必应响应不一定包含此标头。 如果响应包含此标头，请针对该设备上的用户捕获客户端 ID 并将其用于所有后续必应请求。 如果包含 X-MSEdge-ClientID，不可在请求中包含 Cookie。
- client_ip
- str
客户端设备的 IPv4 或 IPv6 地址。 IP 地址用于发现用户的位置。 必应使用位置信息来确定安全搜索行为。 尽管是可选的，但还是建议始终指定此标头和 X-Search-Location 标头。 不要混淆地址（例如，通过将最后一个八位字节更改为 0 来混淆地址）。 混淆地址会导致位置未处于设备实际位置附近，这可能导致必应提供错误的结果。
- location
- str
以分号分隔的键/值对列表，描述客户端的地理位置。 必应使用位置信息来确定安全搜索行为并返回相关的本地内容。 以 : 形式指定键/值对。 下面是用于指定用户位置的键。 lat (所需的) ：客户端位置的纬度（以度为单位）。 纬度必须大于或等于 -90.0 且小于或等于 +90.0。 负值表示南纬，正值表示北纬。 long (必需) ：客户端位置的经度（以度为单位）。 经度必须大于或等于 -180.0 且小于或等于 +180.0。 负值表示西经，正值表示东经。 re (所需的) ：半径（以米为单位），指定坐标的水平精度。 传递设备定位服务返回的值。 典型的值可能是：22m - GPS/Wi-Fi、380m - 蜂窝基站三角网定位、18,000m - 反向 IP 查询。 ts (可选) ：客户端位于该位置时的 UTC UNIX 时间戳。 (UNIX 时间戳是自 1970 年 1 月 1 日以来的秒数。) 头 (可选) ：客户端的相对航向或行驶方向。 以度数指定旅行方向（从 0 到 360），相对于正北方向顺时针计数。 仅当 sp 键为非零时，才指定此键。 sp (可选) ：客户端设备正在行驶的水平速度 (速度) （以米/秒为单位）。 alt (可选) ：客户端设备的高度（以米为单位）。 (可选) ：半径（以米为单位），指定坐标的垂直精度。 仅当指定 alt 键时，才指定此键。 尽管许多键是可选的，但提供的信息越多，位置结果越精确。 尽管是可选的，但还是建议始终指定用户的地理位置。 如果客户端的 IP 地址未准确反映用户的物理位置（例如，如果客户端使用 VPN），则提供位置尤其重要。 为了获得最佳结果，应包含此标头和 X-Search-ClientIP 标头，但至少应包含此标头。
- action_type
- str 或 ActionType
日志记录使用的字符串，用于确定请求是来自交互式会话还是页面加载。 下面是可能的值。 1) 编辑 — 请求来自交互式会话 2) 加载 — 请求来自页面加载。 可能的值包括：“Edit”、“Load”
- country_code
- str
结果来源的国家/地区的 2 个字符国家/地区代码。 此 API 仅支持美国市场。 如果指定此查询参数，则必须将其设置为我们。 如果设置此参数，则还必须指定 Accept-language 标头。 必应使用从语言列表中找到的第一种受支持的语言，并将该语言与指定的国家/地区代码组合在一起，以确定要为其返回结果的市场。 如果语言列表不包括受支持的语言，必应会查找支持该请求的最接近的语言和市场，或者它可能会对结果使用聚合市场或默认市场，而不是使用指定的市场。 仅当指定多种语言时，才应使用此查询参数和 Accept-Language 查询参数;否则，应使用 mkt 和 setLang 查询参数。 此参数和 mkt 查询参数相互排斥，不可同时指定两者。
- market
- str
产生结果的市场。 强烈建议您始终指定市场（如果已知）。 指定市场有助于必应路由请求，并返回适当的最佳响应。 此参数和 cc 查询参数相互排斥，不可同时指定两者。
- set_lang
- str
可用于用户界面字符串的语言。 使用 ISO 639-1 2 字母语言代码指定语言。 例如，英语的语言代码是 EN。 默认为 EN（英语）。 尽管是可选项，但应始终指定语言。 通常，将 setLang 设置为 mkt 指定的同一语言，除非用户希望用户界面字符串以其他语言显示。 此参数和 Accept-Language 标头相互排斥，不可同时指定两者。 用户界面字符串是用作用户界面中标签的字符串。 JSON 响应对象中有几个用户界面字符串。 此外，响应对象中 Bing.com 属性的任何链接均会应用指定的语言。
要执行的拼写和语法检查的类型。 以下是 (值不区分大小写) 的可能值。 默认值为 Proof。 1) 证明 - 查找大多数拼写和语法错误。 2) 拼写 - 查找大多数拼写错误，但找不到 Proof 捕获 (的部分语法错误，例如，大写和重复单词) 。 可能的值包括：“proof”、“spell”
- pre_context_text
- str
为文本字符串提供上下文的字符串。 例如，文本字符串花瓣有效。 但是，如果将 preContextText 设置为 bike，上下文将更改，文本字符串将变为无效。 在这种情况下，API 建议将花瓣更改为踏板 (，就像在自行车踏板) 中一样。 不会检查此文本是否存在语法或拼写错误。 文本字符串、preContextText 字符串和 postContextText 字符串的组合长度不能超过 10,000 个字符。 可以在 GET 请求的查询字符串或 POST 请求的正文中指定此参数。
- post_context_text
- str
为文本字符串提供上下文的字符串。 例如，读取的文本字符串有效。 但是，如果将 postContextText 设置为 carpet，则上下文将更改，文本字符串将变为无效。 在这种情况下，API 建议将读取更改为红色 (，如红地毯) 所示。 不会检查此文本是否存在语法或拼写错误。 文本字符串、preContextText 字符串和 postContextText 字符串的组合长度不能超过 10,000 个字符。 可以在 GET 请求的查询字符串或 POST 请求的正文中指定此参数。
- operation_config
操作配置替代。
返回
SpellCheck 或 ClientRawResponse（如果 raw=true）
返回类型
例外
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈