Swift和golang编码base64给出了不同的结果

我正在用swift编码一幅图像

let base64String = data!.base64EncodedStringWithOptions(NSDataBase64EncodingOptions(rawValue: 0))

编码字符串的前222个字符是

/9j/4AAQSKZJRGABAAQAASABABAAD/4QBYRXHPZGATU0AKGAAAGAAGESAAMAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAKAAAAQAAAAABABLABAABLABAD/7QA4 UghVDG9ZAG9WIDMUMAA4QKLNBAQAAAAAAAAAAAAAAQKLNBCUAAAAAAAAAAAAAAABDUYZJYBOMACZJS+EJ.

我使用

sEnc := base64.StdEncoding.EncodeToString(imageData)

编码字符串的前224个字符为

/9j/2WCEAAGGGCGBQGHBWCJCQKDBQNDASLDBKSEW8UHROH0AHBWGJC4NICIXWCKDCPLDAXNDQ0HYC5PTGYPC4ZNDIBCQKJDASMGA0NGDIHCHCEYMJIYMJIYMJIYMJIYMJIYMJIYMJIYMJIYMJIYMJIYMJIYMJIYMJYMJYMJYMYMV/AABEIASWBBLAMBIGAGAEQEQEQEQE/XAGIAABB……

---

当我用swift解码图像时

let decodedData = NSData(base64EncodedString: base64String, options: NSDataBase64DecodingOptions(rawValue: 0))
var decodedimage = UIImage(data: decodedData!)

图像看起来完全一样

当我用

dec, err := base64.StdEncoding.DecodeString(imageData)

解码base64字符串时出错：

输入字节220处非法的base64数据，该字节是
+
字符。但当我解码golang生成的base64时，输出是正确的

为什么编码的字符串不同？我怎样才能修好它

编辑：

Swift最后10个字节
eqvr h/9k=


Golang最后10个字节
cvdR//2Q==

编辑2：

在Golang中，我使用
ioutil读取文件

b, err := ioutil.ReadFile(fileName)

编辑3：

添加了不同测试用例的结果
使用Swift编码字符串，这显然是在Photoshop中生成的JPEG（JFIF是JPEG传输签名）：

使用Golang生成的字符串，没有类似的内容：

$ echo '/9j/2wCEAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDIBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMv/AABEIASwBLAMBIgACEQEDEQH/xAGiAAABBQEBAQEB' | base64 -D | hexdump -C
00000000  ff d8 ff db 00 84 00 08  06 06 07 06 05 08 07 07  |................|
00000010  07 09 09 08 0a 0c 14 0d  0c 0b 0b 0c 19 12 13 0f  |................|
00000020  14 1d 1a 1f 1e 1d 1a 1c  1c 20 24 2e 27 20 22 2c  |......... $.' ",|
00000030  23 1c 1c 28 37 29 2c 30  31 34 34 34 1f 27 39 3d  |#..(7),01444.'9=|
00000040  38 32 3c 2e 33 34 32 01  09 09 09 0c 0b 0c 18 0d  |82<.342.........|
00000050  0d 18 32 21 1c 21 32 32  32 32 32 32 32 32 32 32  |..2!.!2222222222|
00000060  32 32 32 32 32 32 32 32  32 32 32 32 32 32 32 32  |2222222222222222|
*
00000080  32 32 32 32 32 32 32 32  ff c0 00 11 08 01 2c 01  |22222222......,.|
00000090  2c 03 01 22 00 02 11 01  03 11 01 ff c4 01 a2 00  |,.."............|
000000a0  00 01 05 01 01 01 01 01                           |........|
000000a8

$echo'/9j/2WCEAAGGGBGCGBQGHBJCQGKDQNDALDBKSEW8UHROH0AHBWGJC4NICIXWCKDCPLDAXNDQ0HYC5PTGYPC4ZNDIBCQKJDasmga0NGDIHHCEYMJIYMJIYMJIYMJIYMJIYMJIYMJIYMJIYMJIYMJYMJYMYMV/AABEIASWBBIGAMBIGACEQEQEQEQEQE/XAGIAAAAAAAAQEQEQEQEQEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
00000000 ff d8 ff db 00 84 00 08 06 06 05 07 ||
000000 10 07 09 09 08 0a 0c 14 0d 0c 0b 0b 0c 19 12 13 0f|
000000 2014 1d 1a 1f 1d 1a 1c 20 24 2e 27 20 22 2c美元",|
000000 30 23 1c 28 37 29 2c 30 31 34 34 1f 27 39 3d |#(7),01444。'9=|
000000 40 38 32 3c 2e 33 34 32 01 09 09 0c 0b 0c 18 0d | 82这两个文件似乎完全不同。你确定对这两个文件都进行相同的编码吗？@TimBiegeleisen我正在使用我提供的代码进行编码。解码也有问题，因为它们无法对彼此编码的字符串进行解码。@Thellim列出了Go的哪个版本您是否正在使用？swift输出中的空格看起来可疑：
…ACZjs EJ…
。base64编码字符串不应包含空格。请查看@Thellilist，您上载到dropbox的文件中没有空格。为什么此字符串中的“+”被替换为空格？您是否调用了URLDecode或类似功能？以及您上载的文件to dropbox是有效的base64文件，但它们是从不同的文件创建的。请描述确切的步骤，包括您如何获得错误的所有详细信息，否则无法回答错误。我为另一幅图像尝试了您的风格，这幅图像是JPG。由于它们的编码方式不同，我也无法解码。
$ echo '/9j/2wCEAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDIBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMv/AABEIASwBLAMBIgACEQEDEQH/xAGiAAABBQEBAQEB' | base64 -D | hexdump -C
00000000  ff d8 ff db 00 84 00 08  06 06 07 06 05 08 07 07  |................|
00000010  07 09 09 08 0a 0c 14 0d  0c 0b 0b 0c 19 12 13 0f  |................|
00000020  14 1d 1a 1f 1e 1d 1a 1c  1c 20 24 2e 27 20 22 2c  |......... $.' ",|
00000030  23 1c 1c 28 37 29 2c 30  31 34 34 34 1f 27 39 3d  |#..(7),01444.'9=|
00000040  38 32 3c 2e 33 34 32 01  09 09 09 0c 0b 0c 18 0d  |82<.342.........|
00000050  0d 18 32 21 1c 21 32 32  32 32 32 32 32 32 32 32  |..2!.!2222222222|
00000060  32 32 32 32 32 32 32 32  32 32 32 32 32 32 32 32  |2222222222222222|
*
00000080  32 32 32 32 32 32 32 32  ff c0 00 11 08 01 2c 01  |22222222......,.|
00000090  2c 03 01 22 00 02 11 01  03 11 01 ff c4 01 a2 00  |,.."............|
000000a0  00 01 05 01 01 01 01 01                           |........|
000000a8