人們如何在Smalltalk中實現UTF-8？

我一直在做一些初步努力，實施UTF8String，我不得不解決與消息有關的問題，如#size,#at:,#do:等，其中有一些我找不到一個好的解決方案。示例包括#new:（類方）和#at:put:（實例），因爲它們需要（或使用）的字節數取決於字符串最終將包含的實際字符。人們如何在Smalltalk中實現UTF-8？

我們可以考慮的一個想法是在尾部分配額外的（未使用的）空字節，實際上它們不是字符串的一部分，只有在空行使用空位時才使用#become:。這是一個好的（或壞的）想法嗎？如何正確的實施工作？

來源

2016-09-22 Leandro Caniglia

一種解決方案是將字節序列保存到一個實例變量（一個ByteArray），然後使用一個正常的基於指針的子類而不是使用variableByteSubclass。

然後預分配額外的字節的策略可以很容易地實現，因爲你將有效的大小存儲到另一個實例變量。由您來調整代碼複雜性/效率，內存/速度平衡。

其優點是避免與其他VM原語混淆，如copyReplaceFrom：to：with：startingAt：它可以將原始編碼從一個字節類轉移到另一個類，這可能會對編碼產生錯誤的解釋。

另一個優點是你不需要調用become：super-power。

來源

2016-09-23 07:47:03

謝謝aka.nice。我已經考慮過了，但沒有嘗試（到目前爲止），因爲新類不會從String繼承，並且可能會產生一些同步問題（兩個類一起演變）以及似乎是代碼的重要副本（不太確定這雖然）。 –

@LeandroCaniglia好的，可能是Cuis中的一個問題，在這個模式中，String就像Squeak一樣需要一個抽象（指針）類，UTF8String一個variableByteSubclass和另一個ByteString（帶有一些衆所周知的編碼約定）。 –

哦，是的。你是對的！我沒有考慮過這種可能性。我沒有使用Cuis，但在我的系統中，抽象類String是字節。現在，您對重構的想法對我來說很有意義。 –

恕我直言，最好只使用UTF8導入和導出。內部使用32位字符。

來源

2016-09-22 22:42:48

我同意。我正在爲此工作的原因是爲檢查和調試用於導入/導出目的的UTF-8序列提供一些基本設施。 –

在Python中，他們通過在內部使用UTF-32（基本上是Bert的建議）解決了這個問題，這是一種固定寬度編碼（儘管它們通過丟棄未使用的字節進行優化）。請參閱legacy.python.org/dev/peps/pep-0393。 –

雖然我同意伯特，但要小心。即使使用32位代碼點也不能保證一個32位代碼點總是一個字符。 :) – Tobias

如果你可以承擔花費的精力，你可以比所有角色的32位做得更好。實際文本是全部ASCII（英文，程序），有一些非ASCII字符（德語，法語）或幾乎完整的多字節。對於那些少數非ascii，你可以保留一個支持數據結構來幫助#at：等。

來源

2016-09-23 13:08:55

任何關於您將保留數據結構的位置的建議？我能想到的唯一的一個屬性（在字節對象中沒有實例變量。）這是你所建議的嗎？ –

用特殊的方式使用第一個字節的東西，我會說。 –

人們如何在Smalltalk中實現UTF-8？

回答

相關問題