爲什麼string.encode（'utf-8'）！= bytes（map（ord，string））？

Question

我們認爲是什麼編碼bytes(map(ord, string))正在使用？爲什麼有時候這是string.encode('utf-8') != bytes(map(ord, string))？

當客戶端JavaScript與Django 1.5（Python 3）應用程序進行交互時，我遇到了這個問題。

基本上我使用ajax和jDataView上傳一個mp3文件作爲字符串（我找不到直接上傳文件的解決方案）。我使用jDataView將文件轉換爲字符串。在我的Django應用程序中，當我保存文件時，它改變了大小。但是，如果不使用string.encode('utf-8')我使用bytes(map(ord, string))文件可以很好地保存。這是爲什麼？爲什麼是string.encode('utf-8') != bytes(map(ord, string))？

我的客戶端代碼如下所示：

function send(file) { 
    var reader = new FileReader(); 
    reader.onload = function(event) { 
     var self = this; 
     $.ajax({ 
      url: 'upload/', 
      type: 'POST' 
      data: {contents: (new jDataView(self.result)).getString()} 
     }); 
    } 
    reader.readAsArrayBuffer(file); 
} 

和我的觀點收到像這樣的數據：

def upload(request): 
    contents = request.POST.get('contents') 
    track = Track.objects.all[0] # For testing only 
    contents = bytes(map(ord, contents)) 
    track.file.save('file.mp3', ContentFile(contents)) 

我檢查，並在這兩個JS代碼和Python代碼contents都一樣事情。它們具有相同的字節長度，並且通過適合我的屏幕上的第一個和最後幾個字符來判斷它們具有相同的內容。

如果我我的代碼更改爲

def upload(request): 
    contents = request.POST.get('contents') 
    track = Track.objects.all[0] # For testing only 
    contents = contents.encoding('utf-8') 
    track.file.save('file.mp3', ContentFile(contents)) 

文件大小的變化，不再有效的MP3文件。

Answer 1

UTF-8確實不是將Unicode碼點直接映射到字節。這僅適用於ASCII代碼點，範圍爲U + 0000至U + 007F。超出該範圍，UTF-8使用每碼點2首或更多個字節：

>>> '\u007f'.encode('utf8') 
b'\x7f' 
>>> '\u0080'.encode('utf8') 
b'\xc2\x80' 

您所想Latin-1編碼的代替，其中，所述代碼點U + 0000到U + 00FF不直接映射到字節：

>>> string = ''.join([chr(i) for i in range(0x100)]) 
>>> string.encode('latin-1') == bytes(map(ord, string)) 
True 

相反編碼的文字，你可以存儲的base64編碼前的二進制數據，也可以升級到1.6的Django，其中有一個binary field type。