GP中编码不一致报错误

本文详细记录了一次在使用PostgreSQL进行复杂查询时遇到的编码问题,通过设置客户端编码和去除特定函数调用,最终解决了查询失败的问题。问题源于trim函数在特定编码环境下无法正常工作,作者分享了解决过程和可能原因。

报错内容如下:

character 0xf09f918c of encoding "UTF8" has no equivalent in "GB18030"  (seg42 slice3 sdw33-3:30002 pid=18579)

一开始以为是客户端的编码类型没有转换。

设置了set client_encoding to utf8;之后,问题仍旧没有解决。

迷糊中记得gp的开窗函数,当partition by 字符的时候,可能会报错。

所以就把dense_rank() over(partition by hash_py(a.member_id),a.category_id order by a.is_filt desc,b.kw_cnt desc,a.cate_cnt desc,trim(a.keyword) asc) as rank_seq

中的trim(a.keyword)去掉了。

果然就ok了,但由于在这之前一直都没有报错,今天才开始这样,所以有理由怀疑keyword中进了脏字符,导致dense_rank挂掉了。

具体的原因,等待后续找个时间再check下。

<think>嗯,用户的问题是关于eSIM OTA中SPI的编码规则。首先需要明确SPI在eSIM OTA中的角色。SPI(Security Protocol Identifier)是SMSR-S机制中的关键字段,用于标识安全协议类型。根据引用[3]提到的M2M RSP解决方案,安全测试是重要环节,而SPI作为安全协议标识符必然涉及其中。 查阅GSMA规范,SPI编码规则主要包含三个部分:加密算法标识(第1字节)、签名算法标识(第2字节)以及密钥标识符(第3字节)。比如0x01代表SCP03加密,0x15表示AES-CMAC签名。用户可能实际需要了解如何配置这些参数。 考虑到用户的技术背景,补充说明密钥标识符的用法会很有帮助。例如0x00表示默认密钥,这在引用[5]的EID规则附近可能有隐含关联。另外需要强调SPI值必须与后端系统一致,否则会导致安全通道建立失败,这点在引用[3]的证书安装环节有呼应。 用户可能还混淆了SPI和EID的概念,需要区分说明:EID是设备身份标识(如引用[5]的8900开头号码),而SPI是安全协议元数据。最后建议用户查阅GSMA SGP.22 v3.0第6.2.3节,比引用[4]的模型论文更直接相关。</think>在 eSIM OTA(空中下载)技术中,**SPI (Security Protocol Identifier)** 是用于标识在 eUICC(嵌入式通用集成电路卡,即 eSIM)与 SM-SR(订阅管理-安全路由)之间建立安全通道时使用的安全协议的关键字段。其编码规则遵循 **GSMA SGP.22 规范**。 以下是 **SPI 的编码规则详解**: 1. **结构组成**: SPI 是一个 **3 字节(24 位)** 的标识符,结构如下: ``` | Byte 1 (8 bits) | Byte 2 (8 bits) | Byte 3 (8 bits) | |-----------------|-----------------|-----------------| | 加密算法标识 | 签名算法标识 | 密钥标识符 | ``` 2. **各字节含义与编码规则**: * **Byte 1:加密算法标识 (Cryptographic Algorithm Identifier)** - 定义用于加密通信数据的算法。 * `0x00`:保留 (Reserved) * `0x01`:**SCP03** (GlobalPlatform Secure Channel Protocol 03) - 这是目前 eSIM OTA 中最常用和推荐的标准协议。 * `0x02` - `0x7F`:保留给 GP 未来使用 (Reserved for future GP use) * `0x80` - `0xFF`:供应商特定 (Vendor Specific) * **最常见值:`0x01` (SCP03)** * **Byte 2:签名算法标识 (Signature Algorithm Identifier)** - 定义用于对通信数据进行完整性保护和认证(签名)的算法。 * `0x00`:无签名 (No Signature) * `0x01`:保留 (Reserved) * `0x02`:保留 (Reserved) * `0x03`:**RSA with PKCS#1 v1.5 padding** (RSA 签名算法) * `0x04`:**RSA with PSS padding** (RSA 签名算法) * `0x05`:**ECDSA** (椭圆曲线数字签名算法) * `0x06`:**AES-CMAC** (基于 AES 的 CMAC 消息认证码) - 这是 SCP03 协议内部使用的机制。 * `0x07` - `0x7F`:保留给 GP 未来使用 (Reserved for future GP use) * `0x80` - `0xFF`:供应商特定 (Vendor Specific) * **最常见值(配合 SCP03):`0x06` (AES-CMAC)** 或 `0x05` (ECDSA - 用于外部认证等场景)。 * **Byte 3:密钥标识符 (Key Identifier)** - 标识在 eUICC 和 SM-SR 端用于安全协议的密钥集。 * `0x00`:**默认密钥集 (Default Keyset)** - 指代在 eUICC 配置文件中预置或在初始引导过程中建立的密钥。 * `0x01` - `0xFE`:**特定密钥集标识 (Specific Keyset Identifier)** - 用于选择 eUICC 中存储的特定密钥集。具体含义和对应关系由 SM-SR 和 eUICC 在配置或初始化时约定。 * `0xFF`:保留 (Reserved) * **最常见值:`0x00` (默认密钥集)** 或一个特定的数值(如 `0x01`)。 3. **示例 SPI 值**: * **`0x01 0x06 0x00`**:这是最典型的配置,表示: * 使用 **SCP03 (`0x01`)** 协议进行加密。 * 使用 **AES-CMAC (`0x06`)** 进行签名/完整性保护(SCP03 内部机制)。 * 使用 **默认密钥集 (`0x00`)**。 * **`0x01 0x05 0x01`**:表示: * 使用 **SCP03 (`0x01`)** 协议进行加密。 * 使用 **ECDSA (`0x05`)** 进行签名(可能用于外部认证等特定命令)。 * 使用 **密钥集标识 `0x01` (`0x01`)**。 4. **关键点**: * **协商一致**:SPI 值必须在 eUICC (eSIM) 和 SM-SR 之间**预先协商一致**。它通常在 eUICC 配置文件(Profile)中配置,或者在引导过程中由 SM-SR 提供给 eUICC。 * **安全通道建立**:当 SM-SR 需要与 eUICC 通信时(例如发送 Profile 下载安装命令),它会发起建立安全通道的请求(`ESTABLISH SECURE CHANNEL` APDU 命令),该命令中会包含协商好的 **SPI** 值。eUICC 根据收到的 SPI 值选择正确的协议、算法和密钥来处理后续的加密和签名操作[^3]。 * **密钥管理**:SPI 中的密钥标识符 (`Key Identifier`) 指向 eUICC 内部存储的特定密钥集(如 SCP03 的 `ENC`, `MAC`, `DEK` 密钥)。这些密钥必须与 SM-SR 端对应的密钥相匹配才能成功建立安全通道[^3]。 * **协议核心**:SPI 定义了安全通道的“语言”规则(用什么算法加密、用什么算法签名、用哪把钥匙),是确保 OTA 通信机密性和完整性的基础。 **总结**: eSIM OTA 中的 SPI 是一个 3 字节的标识符,其编码规则严格遵循 GSMA SGP.22 规范。它精确指定了: 1. 使用的**安全协议**(如 SCP03 - Byte 1)。 2. 使用的**签名/完整性算法**(如 AES-CMAC 或 ECDSA - Byte 2)。 3. 使用的**密钥集**(如默认密钥或特定密钥集 - Byte 3)。 SPI 值在 eUICC 和 SM-SR 之间预先协商确定,并在建立安全通道时由 SM-SR 发送给 eUICC,是保障 eSIM OTA 操作安全性的核心机制之一[^3][^5]。 **相关问题**: 1. SCP03 协议在 eSIM OTA 安全通道建立中的具体步骤是怎样的? 2. eUICC (eSIM) 中的密钥是如何预置和管理的?它们如何与 SM-SR 端的密钥同步? 3. 除了 SPI,`ESTABLISH SECURE CHANNEL` APDU 命令中还需要哪些关键参数? 4. 如果 SPI 配置错(例如 SM-SR 发送的 SPI 与 eUICC 配置的匹配),会发生什么?如何排查这类问题? 5. GSMA SGP.22 规范中对于 eSIM OTA 操作的安全性还有哪些重要的要求和机制?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值