Android问题解决：android.util.Base64.encode 导致签名不匹配 SignatureDoesNotMatch

小咪咪 2023-10-07 18:44 6阅读 0赞

#### 文章目录 ####

*  前文：遇到问题
 *  一问：为什么SignatureDoesNotMatch
 *  二问：为什么SignatureDoesNotMatch
 *  三问：Signature请求参数为什么多了%0A
 *  四问：Signature为什么多了换行
 *  五问：android.util.Base64.encode的用法

## 前文：遇到问题 ##

> 在折腾《[ESP32-C3入门教程——导读][ESP32-C3]》时，需要对接阿里云物联网平台。  
> 想要通过Android App直接调用[阿里云物联网云端API][API]。  
> 阿里云并没有直接提供对应的云端开发的Android SDK，就只能自己写了。  
> 结果就遇到了这么一个大坑。签名不匹配，校验不通过。

> 今天博文，咱们换种写法，5why分析法。  
> 话说每个问题多问几个why，在第5个why的时候，你就能找到根源。

`SignatureDoesNotMatch : Specified signature is not matched with our calculation`

{
        
    	    "RequestId":"DD7C6D23-8236-5152-85FB-A7869342B749",
    	    "Message":"Specified signature is not matched with our calculation. server string to sign is:XXXXXXXXX",
    	    "Recommend":"https://troubleshoot.api.aliyun.com?q=SignatureDoesNotMatch&product=Iot",
    	    "HostId":"iot.cn-shanghai.aliyuncs.com",
    	    "Code":"SignatureDoesNotMatch"
        }

![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5bCP5bq35biI5YWE_size_20_color_FFFFFF_t_70_g_se_x_16]

## 一问：为什么SignatureDoesNotMatch ##

**分析：**

*  为什么`SignatureDoesNotMatch`，`签名不匹配`？
 *  大概率是`Signature`计算错误？
 *  直接看[签名机制][Link 1]其中的`Signature`参数的计算过程

**验证：**  
做个对比测试，验证我们计算的`Signature`是否正确

*  下载官方提供的java sdk
 *  设定一模一样的参数，分别运行java和android
 *  打印输出，皆是：`seuSaBh1s8fZ4MGayjxYv4wc3JY=`

## 二问：为什么SignatureDoesNotMatch ##

**分析：**  
第一步排查直接失败，方向错误，没法接着深挖。

*  换个方向继续问：`Signature`签名正确，为什么还会提示`SignatureDoesNotMatch`？
 *  难道是提交给阿里云的请求字符串错误？

**验证：**  
同上一样，做一个对比测试，验证我们最终得到的请求字符串是否一致。

*  下载官方提供的java sdk
 *  设定一模一样的参数，分别运行java和android
 *  打印输出，分别如下：

`http://iot.cn-shanghai.aliyuncs.com/?SignatureVersion=1.0&Action=QueryDevicePropertyStatus&Format=JSON&SignatureNonce=2E68FD84-A0BE-4D86-BDB2-7578F20290E6&Version=2018-01-20&AccessKeyId=XXXXXXXXX&Signature=seuSaBh1s8fZ4MGayjxYv4wc3JY%3D%0A&SignatureMethod=HMAC-SHA1&RegionId=cn-shanghai&Timestamp=2022-04-21T15%3A30%3A27Z&ProductKey=XXXXXXXXX&DeviceName=XXXXXXXXX`

`https://iot.cn-shanghai.aliyuncs.com/?AccessKeyId=XXXXXXXXX&Action=QueryDevicePropertyStatus&DeviceName=XXXXXXXXX&Format=JSON&ProductKey=XXXXXXXXX&RegionId=cn-shanghai&SignatureMethod=HMAC-SHA1&SignatureNonce=2E68FD84-A0BE-4D86-BDB2-7578F20290E6&SignatureVersion=1.0&Timestamp=2022-04-21T15%3A30%3A27Z&Version=2018-01-20&Signature=seuSaBh1s8fZ4MGayjxYv4wc3JY%3D`

*  经过细致的观察和对比，很快发现Android打印输出的是`Signature=seuSaBh1s8fZ4MGayjxYv4wc3JY%3D%0A`
 *  而Java打印输出的是`Signature=seuSaBh1s8fZ4MGayjxYv4wc3JY%3D`

## 三问：Signature请求参数为什么多了%0A ##

**分析：**

*  `Signature`原先的计算结果是`seuSaBh1s8fZ4MGayjxYv4wc3JY=`。
 *  根据[签名机制][Link 1]要求，需要将其按照RFC3986的规则进行URL编码后，再添加到请求参数中，即完成对请求签名的过程。
 *  `seuSaBh1s8fZ4MGayjxYv4wc3JY=`进行URL编码后得到`seuSaBh1s8fZ4MGayjxYv4wc3JY%3D`。
 *  那么java程序运行的结果是没毛病的，Android运行结果为什么多了`%0A`。
 *  由URL编码得知，%0A是换行符经过URL编码得来的。
 *  那么得到的结论是Android计算`Signature`的结果是多了一个换行符。
 *  这也反推到第一个为什么的猜测是正确的，只是因为换行符靠打印是看不出来的。

## 四问：Signature为什么多了换行 ##

**分析：**

*  android的Signature计算代码很多也是借鉴[签名机制][Link 1]这边的Java代码示例。
 *  基本没有修改，唯一修改的地方在于`return new String(Base64.encodeBase64(bytes, false), CHARSET_UTF8);`
 *  因为android没有该函数，所以我将其改成`return new String(Base64.encode(bytes, Base64.DEFAULT), CHARSET_UTF8);`
 *  如果代码中哪里有问题，那么最有可能出问题的地方就在这里。

**验证：**

*  将`return new String(Base64.encode(bytes, Base64.DEFAULT), CHARSET_UTF8);`
 *  改成`return new String(Base64.encode(bytes, Base64.NO_WRAP), CHARSET_UTF8);`
 *  问题解决，撒花~

## 五问：android.util.Base64.encode的用法 ##

**分析：**

但是，我们不禁还是要问：为什么呢？

从`android.util.Base64.java`的源码中得到

/**
     * Utilities for encoding and decoding the Base64 representation of
     * binary data.  See RFCs <a
     * href="http://www.ietf.org/rfc/rfc2045.txt">2045</a> and <a
     * href="http://www.ietf.org/rfc/rfc3548.txt">3548</a>.
     */
    public class Base64 {
        
        /**
         * Default values for encoder/decoder flags.
         */
        public static final int DEFAULT = 0;
    
        /**
         * Encoder flag bit to omit the padding '=' characters at the end
         * of the output (if any).
         */
        public static final int NO_PADDING = 1;
    
        /**
         * Encoder flag bit to omit all line terminators (i.e., the output
         * will be on one long line).
         */
        public static final int NO_WRAP = 2;
    
        /**
         * Encoder flag bit to indicate lines should be terminated with a
         * CRLF pair instead of just an LF.  Has no effect if {@code
         * NO_WRAP} is specified as well.
         */
        public static final int CRLF = 4;
    
        /**
         * Encoder/decoder flag bit to indicate using the "URL and
         * filename safe" variant of Base64 (see RFC 3548 section 4) where
         * {@code -} and {@code _} are used in place of {@code +} and
         * {@code /}.
         */
        public static final int URL_SAFE = 8;
    
        /**
         * Flag to pass to {@link Base64OutputStream} to indicate that it
         * should not close the output stream it is wrapping when it
         * itself is closed.
         */
        public static final int NO_CLOSE = 16;
       
       ......

<table> 
 <thead> 
  <tr> 
   <th>flags</th> 
   <th align="left">注释</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>DEFAULT</td> 
   <td align="left">Default values for encoder/decoder flags.</td> 
   <td>默认</td> 
  </tr> 
  <tr> 
   <td>NO_PADDING</td> 
   <td align="left">Encoder flag bit to omit the padding ‘=’ characters at the end of the output (if any).</td> 
   <td>省略末尾填充的=</td> 
  </tr> 
  <tr> 
   <td>NO_WRAP</td> 
   <td align="left">Encoder flag bit to omit all line terminators (i.e., the output will be on one long line).</td> 
   <td>省略所有的终止符</td> 
  </tr> 
  <tr> 
   <td>CRLF</td> 
   <td align="left">Encoder flag bit to indicate lines should be terminated with a CRLF pair instead of just an LF. Has no effect if NO_WRAP is specified as well.</td> 
   <td>指示行的编码器标志位用CRLF替代LF</td> 
  </tr> 
  <tr> 
   <td>URL_SAFE</td> 
   <td align="left">Encoder/decoder flag bit to indicate using the “URL and filename safe” variant of Base64 (see RFC 3548 section 4) where - and _ are used in place of + and /</td> 
   <td>URL和文件名安全方式，替换其中不符合url安全的字符如+和/</td> 
  </tr> 
  <tr> 
   <td>NO_CLOSE</td> 
   <td align="left">Flag to pass to Base64OutputStream to indicate that it should not close the output stream it is wrapping when it itself is closed.</td> 
   <td>传递给Base64OutputStream标记以指示它本身关闭时不应关闭它正在包装的输出流</td> 
  </tr> 
 </tbody> 
</table>

在这里大概明白了，

*  `DEFAULT`默认会在base64字符串结果添加换行。
 *  而选择`NO_WRAP`会省略掉这个结尾的换行。
 *  所以，问题就出在这。
 *  该问题刚好在5why分析法的第五个为什么结束的时候，完美结题！

***觉得好，就一键三连呗（点赞+收藏+关注）***

[ESP32-C3]: https://blog.csdn.net/kangweijian/article/details/120248230
[API]: https://help.aliyun.com/document_detail/30559.html
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5bCP5bq35biI5YWE_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/56380dd60aa545378b1ab145ff44053d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5bCP5bq35biI5YWE,size_20,color_FFFFFF,t_70,g_se,x_16
[Link 1]: https://help.aliyun.com/document_detail/30563.html