Squeak Monticello 문자 인코딩

Question

업무용 프로젝트에서 (디스플레이리스, 원격) 리눅스 서버에 헤드리스 스퀵을 사용하고 Windows developer-machine에서 Squeak을 사용하고 있습니다.

개발자 컴퓨터의 코드는 Monticello를 사용하여 관리합니다. 불행히도 SFTP를 사용하여 mcz를 서버에 복사해야합니다 (예 : 서버의 푸시 저장소가 보안상의 이유로 불가능한 경우). 코드는 다음 예에 의해 병합 : 일반적으로 작동

MczInstaller installFileNamed: 'name-b.18.mcz'.

합니다.

불행히도 우리의 코드베이스에는 Umlaut와 다른 비 ASCII 문자가 포함 된 문자열이 포함되어 있습니다. Monticello-다시 가져 오기 중 중 일부는 다른 문자로 대체되고 일부는 아무것도 대체되지 않습니다.

나는 또한 시도했다.

MczInstaller installStream: (FileStream readOnlyFileNamed: '...') binary

(노트 .mcz 년대는 실제로 바이너리가 적절해야하므로, 나는 어쨌든 기본 추측,의를 .zip으로) 몬티 첼로의 전송 보존을 만드는 방법을 내부 스퀵을 찾기

- non-ascii의 인코딩이 주 입니다. 목표 내 질문입니다. 수동적 인 노동이 필요하기 때문에 모든 소스 코드를 단지 ASCII 코드를 사용하도록 변경하는 것은 (적어도이 코드베이스에서는) 훨씬 덜 바람직합니다. 그것은이 보조 노트를 읽고,이 경우 간단한 그렙 -replace이없는 이유 당신이 에 관심이 있다면 :

(사이드 참고 : (A 단순화/특별한 경우) 코드베이스는 해변의하는 #text를 사용합니다 : 메서드를 사용하여 html로 이스케이프해야하는 문자가 포함 된 문자열을 렌더링 할 수 있습니다.이 비 ASCII에서 잘 작동합니다 ä을 ä으로 변환합니다. 리터럴의 ä를 ä으로 grep-replace하면 명시 적으로 사용해야합니다. 그러나 #html : 메소드 대신에 (예 : double-escape) html로 이스케이프해야하는 다른 모든 문자를 대체해야합니다 (예 : &). 그런 다음 소스 코드 it 자체에는 그러한 문자가 포함되어 있습니다. #text : 타사 문자열을 사용하는 경우와 같이 # html로 대체되지 않을 수도 있습니다.)

Answer 1

Squeak는 문자열의 문자 인코딩에 내부적으로 유니 코드 (ISO 10646)를 사용합니다.
범위가 16r80 ~ 16r9F 인 문자는 CP1252와 같은 확장자를 사용할 수 있지만 더 이상 확실하지 않습니다.

문자 코드는 그대로 source.st 스트림에 기록되며이 코드는 모든 문자가 < = 16rFF 인 경우 ByteString에 대한 단일 바이트로 구성됩니다. 이 경우 파일은 ISO-8859-L1 또는 CP1252로 인코딩 된 것처럼 보입니다.

문자 코드가 16rFF보다 큰 경우 Squeak에서 WideString이 사용됩니다. 다시 한 번 코드는 source.st 스트림에 쓰여지지만 이번에는 32 비트 코드 (빅 엔디 언 순서로 작성)입니다. 기술적으로 인코딩은 UTF-32BE입니다.

이제 MczInstaller는 무엇을합니까? 그것은 snapshot/source.st 파일을 사용하고, UTF-8 또는 MacRoman 중 하나 인이 파일을 읽기 위해 setConverterForCode을 사용합니다. 따라서 비 ASCII 문자가 변경 될 수 있으며, WideString의 경우에는 -ByteString으로 해석됩니다.

MC 자체는 아카이브의 snapshot/source.st 멤버를 사용하지 않습니다.
대신 snapshot.bin을 사용합니다 (MCMczReader, MCMczWriter의 코드 참조).
이 형식의 형식이 DataStream에 의해 제어되는 이진 파일입니다.

사용해야하는 조각은 오히려입니다 :

MCMczReader loadVersionFile: 'YourPackage-b.18.mcz' 

Answer 2

Monticello는 실제로 문자 인코딩을 인식하지 못합니다. 나는 끽끽 소리에있는 현재 상황을 모른다. 그러나 내가 마지막으로 그것을 조사했을 때 latin1의 문자 인코딩을 가정했다. 그러나 그것은 당신의 상황에서 완벽하게 작동해야한다는 것을 의미합니다.

동일한 종류의 이미지를 쓰고 읽는 중 어쨌든 작동해야합니다. 적절한 문자 인코딩이 실패하면 대개 내부 바이트 표현이 메모리에서 디스크로 기록됩니다. 이것은 패키지의 교차 교환 (cross dialect) 교환을 방지하지만 동일한 이미지 종류를 사용하는 경우 작동합니다.

어쨌든 은 또는 일 수 있습니다. 일 수 있지만 종종 잘못됩니다. 그래서 대부분의 프로젝트는 코드에서 7 비트가 아닌 문자를 사용하지 않기 위해 노력합니다. 7 비트가 아닌 문자를 HTML 엔터티로 변환 할 필요가 없습니다.비 7 비트 문자를 사용하지 않고 코드에서 ä을 생성하려면

Character value: 228 

을 사용할 수 있습니다. 모든 문자에 당신은 당신이 내가이 일부 싶어 할 대답의 종류 아니라는 것을 알고

$ä asciiValue => 228 

을 할 수있는 변환을 추가 할. 그러나 monticello는 적절한 문자 인코딩을 위해 여전히 조정될 필요가있는 이러한 것들 중 하나입니다.