2015-10-14 65 views
0

我有一個Unicode字符串 - 在Python 2.7下。爲lzma壓縮編碼一個unicode字符串

我今天也很頭疼 - 一個並非由Unicode引起的真正問題 - 並且無法像我所需要的那樣把重點放在問題上。在花粉計數下降之前,我比思想家更無腦無力。

我需要使用backports.lzma來壓縮我的「字符串」。偶爾我會得到一個錯誤,因爲'string'不是一個兼容ASCII的String,而是一個Unicode對象,它使用了一些當前未知的字符集(可能是UTF-8但不能保證)。 lzma.compress想要一個Stringbytes()兼容對象。

在我的代碼中,我不一定有unicode的字符編碼。我只知道這是一個unicode對象。通常在類似的情況下,我知道編碼並可以適當地採取行動。我通常也不關心在轉碼中丟失一兩個字符。這一次我很在乎。

這使我幾個問題:

•有沒有一種安全的編碼選擇,也將在一定程度上尺寸最小的(對於大多數UTF-8文檔的)?

•我是否需要擔心解碼的向後兼容性與我壓縮的早期文檔?我沒有完全閱讀lzma文檔(我的壞),並沒有意識到它需要String

回答

1

壓縮對字節進行操作,而不是文本,所以自然需要一個str(2.x)或bytes(3.x)對象。您不需要關心內部文本表示是什麼,因爲您將自己對文本進行編碼/解碼。

  • 是否有一個安全的編碼選擇,也將在一定程度上尺寸最小的(對於大多數UTF-8文檔的)?

沒有。只需編碼爲UTF-8並完成它。

  • 我需要擔心向後兼容解碼上的VS較早版本的文檔,我壓縮?我沒有完全閱讀lzma文檔(我的壞),並沒有意識到它需要一個字符串。

如果你只壓縮ASCII文本,那麼你可以爲UTF-8沒有問題解碼,因爲UTF-8和ASCII編碼ASCII文本完全相同的方式。

+0

謝謝。我知道UTF8超過了ASCII碼,但是擔心如果我需要選擇其他編碼來確保一切都可以通過。順便說一句,你的答案簡潔令人難以置信的完美。 –

+0

按照定義,所有UTF編碼都可以編碼所有Unicode字符。在編碼ASCII文本時,UTF-8是最不浪費的。 –