을 구현하기 위해 사전 준비 작업을 해왔습니다. 예를 들어 #size, #at:, #do: 등과 같은 메시지 관련 문제를 해결해야했습니다. 그 중에서도 좋은 해결책을 찾을 수없는 것들이 있습니다. 예를 들어 #new: (클래스면)과 #at:put: (인스턴스)이 필요합니다 (사용하는 바이트 수는 결국 문자열에 포함될 실제 문자에 따라 다름).사람들은 스몰 토크에서 UTF-8을 어떻게 구현합니까?
고려할 수있는 한 가지 아이디어는 실제로 문자열의 일부가 아닌 추가 (사용되지 않은) null 바이트를 꼬리에 할당하고 null 위치에서 하나가 부족한 경우에만 #become:을 사용하는 것입니다. 이것은 좋은 (또는 나쁜) 아이디어입니까? 적절한 구현은 어떻게해야합니까?
하나의 해결 방법은 variableByteSubclass를 사용하는 대신 일반 포인터 기반 서브 클래스를 사용하여 인스턴스 변수 (ByteArray)에 바이트 시퀀스를 유지하는 것입니다.
그러면 유효 크기를 다른 인스턴스 변수에 저장하기 때문에 추가 바이트를 미리 할당하는 전략을 쉽게 구현할 수 있습니다. 코드 복잡도/효율성, 메모리/속도 균형을 조정할 수 있습니다.
장점은 copyReplaceFrom : to : with : startingAt :와 같은 다른 VM 기본 요소를 사용하지 않는 것입니다. 원시 기본 인코딩을 한 바이트 지향 클래스에서 다른 클래스로 전달할 수 있으며 잠재적으로 인코딩의 잘못된 해석을 만들 수 있습니다.
또 다른 장점은 다음과 같이 호출해야 할 필요가 없다는 것입니다.
IMHO 가져 오기 및 내보내기에만 UTF8을 사용하는 것이 가장 좋습니다. 내부적으로 32 비트를 문자로 사용하십시오.
동의합니다. 이 작업을 수행하는 이유는 가져 오기/내보내기 용도로 사용되는 UTF-8 시퀀스를 검사하고 디버깅하기위한 몇 가지 기본 기능을 제공하기 위해서입니다. –
파이썬에서는 고정 너비 인코딩인데 (사용되지 않는 바이트를 삭제하여 최적화 함) UTF-32를 내부적으로 사용하여이 문제를 해결했습니다 (기본적으로 Bert가 제안한대로). legacy.python.org/dev/peps/pep-0393을 참조하십시오. –
Bert와 동의하는 동안 조심하십시오. 코드 포인트에 대해 32 비트를 사용한다고해서 하나의 32 비트 코드 포인트가 항상 한 문자가되는 것은 아닙니다. :) – Tobias
노력을 기울이면 모든 문자에 대해 32 비트를 사용하는 것보다 훨씬 나아질 수 있습니다. 실제 텍스트는 all-ascii (영어, 프로그램)이거나 ascii가 아닌 문자 (독일어, 프랑스어)가 있거나 거의 완전한 멀티 바이트입니다. 아스키가 아닌 사용자의 경우 #at : 등을 돕기 위해 지원 데이터 구조를 유지할 수 있습니다.
데이터 구조를 어디에 보관할 것인지 제안하십시오. 유일하게 생각할 수있는 것은 속성입니다 (바이트 객체에는 인스턴스 변수가 없습니다.) 이것이 사용자가 제안한 것입니까? –
뭔가 특별한 방법으로 첫 번째 바이트 (들)을 사용하여 뭔가, 나는 말하고 싶지만. –
감사합니다. aka.nice. 나는 이것을 고려했지만 시도하지 않았다. 왜냐하면 새로운 클래스가 String으로부터 상속받지 않을 것이기 때문에 동기화 문제 (두 클래스가 함께 진화하는 것)와 코드의 중요한 중복 인 것처럼 보인다. 이 비록). –
@LeandroCaniglia ok, Cuisine의 문제 일 수 있습니다.이 스킴에서는 String이 추상 (포인터) 클래스이고, UTF8String은 variableByteSubclass이고, ByteString은 Squeak과 같이 다른 잘 알려진 인코딩 규칙을 따릅니다. –
오 예. 당신 말이 맞아요! 나는 그 가능성을 고려하지 않았다. 나는 Cuis를 사용하고 있지는 않지만 내 시스템에서 추상 클래스 인'String'은 바이트입니다. 리펙토링에 대한 귀하의 생각은 나에게 많은 의미를 부여합니다. –