나는 (얼굴을 맞대고) 찾았다이것질문) 입력방법에 관련된 두 단어는 다음과 같습니다.심&음. 저는 X 입력 방식과 범용 입력 방식이라는 이름만 알고 있습니다.
나는 알고 싶다사용법, 기능 및 작업 측면에서 xim과 uim의 차이점은 무엇입니까?
답변1
가장 큰 차이점은 대부분의 입력 시스템이 서버-클라이언트 구현이고 uim은 단지 라이브러리라는 것입니다.
대부분의 사용자에게는 입력 방식 시스템이 전혀 필요하지 않거나 간단한 테이블 기반 변환기만 있으면 됩니다. 이러한 사용자는 복잡한 입력 방법 시스템을 설치할 필요도 없고 설치를 원하지도 않으므로 우리는 uim을 단순하게 유지하고 싶습니다.
Uim은 다양한 스크립트를 지원하고 anthy, canna, prime 또는 skk(일본어), pinyin(중국어), byeoru(한국어)를 포함한 다양한 입력 방법의 프런트 엔드로 사용할 수 있는 입력 방법 모듈 라이브러리입니다. 및 m17n(다른 많은 경우) 언어). 대부분의 기능은 솔루션을 사용하여 구현되므로 매우 간단하고 유연합니다.원천
XIM은 어떻습니까? XIM은 상당히 오래된 입력 방법 프로토콜입니다. ibus 및 fcitx는 레거시 지원 이유로만 이를 구현합니다. 이제 이 두 가지 대신 XIM을 사용할 이유가 없습니다. GTK_IM_MODULE="xim"을 설정하려는 유일한 이유는 GTK의 하드 코딩된 ComposeKey 설정을 재정의하기 위한 것입니다.원천
답변2
이 질문에 답하는 방법은 다양합니다. 이것은 불완전하고 편향된 답변입니다.
긴 이야기 짧게심오래되고 구식이며 텍스트 교환에 유니코드를 사용하는 다국어 세계에는 적합하지 않습니다.음이러한 모든 제한 사항을 해결하도록 설계된 다국어 키보드 입력이 앞으로 나아갈 길입니다.
ASCII 문자 집합으로 이야기를 시작하겠습니다. 1970년대와 그 이전의 ASCII에는 일련의 문자를 8비트로 인코딩하는 두 가지 방법이 있었으며 또 다른 경쟁자는 EBCDIC이었습니다. 내 생각에는 ASCII가 EBCDIC보다 승리하게 된 원인은 두 가지였습니다. 첫 번째는 ASCII에는 7비트만 필요하므로 8번째 비트를 패리티에 사용할 수 있다는 것입니다. 데이터 연결이 초당 300비트를 전송하고 오류가 발생하기 쉬운 모뎀을 사용할 때 12.5% 압축을 달성하고 오류 감지 및 수정 기능을 제공하는 것이 중요합니다. EBCDIC은 8비트를 모두 사용합니다. 또 다른 점은 EBCDIC가 당시 큰 독점이었던 IBM에 의해 설계되고 홍보되었다는 것입니다(많은 사람들은 Windows가 거의 독점에 가까운 승리를 거두지 못했고 단지 자체 독점에서 벗어나기 위해 IBM에 제공했다고 말합니다). ) 비록 ASCII가 텔레타이프 기계에서 유래했지만 AT&T는 그것과 많은 관련이 있었고 AT&T는 IBM에게도 비우호적이었고 Unix를 발명했습니다.
어떤 이유에서든 ASCII는 인터넷, Unix, 결국 Windows 및 Apple 컴퓨터에서 승리했습니다. 그러나 이러한 도구가 확산되면서 표준 로마 문자 이외의 문자를 포함해야 할 필요성이 생기기 시작했습니다. 민족 중심적이지만 당시 관심을 끌었던 실용적인 해결책은 ASCII(256자는 8비트 또는 1바이트(컴퓨터 처리의 자연 단위)로 표시됨)에 예약된 128자 공간을 사용하여 영어 이외의 언어 변형을 추가하는 것이었습니다. à, ç, ñ, Ö 등과 같은 로마 알파벳 이는 당시에는 좋은 일이었지만 나중에 유니코드에 심각한 문제를 일으켰습니다.
그럼에도 불구하고 XIM은 어떤 면에서는 X11의 원래 입력 방법인 고대의 것이며 이 시대정신에 구축되었습니다. 여기서 "문자"는 8비트와 문자 인코딩 테이블로 표현된다고 가정했습니다. (문자 인코딩 테이블을 사용하면 128개의 비ASCII 문자 코드를 다르게 해석할 수 있습니다. 유명한 Windows 사용윈도우-1252Apple이 사용할 때마이크 로만. ISO는 다음을 통해 표준화를 시도합니다.ISO-8859-1그러나 그것은 효과가 없었고, 결과적으로 유니코드와 UTF-8이 탄생했는데, 이는 여전히 우리의 기대를 뛰어넘었습니다. )
그 이후로 수년 동안 유니코드 컨소시엄은 전 세계 모든 언어(및 일부 구성 언어)의 모든 문자소를 포괄하는 동시에 수십 년간의 레거시 코드 이전 버전과의 호환성을 유지하는 문자 인코딩 시스템을 설계하는 훌륭한 작업을 수행해 왔습니다. . 바이트당 한 문자입니다. 심처럼요. ASCII는 여전히 컴퓨팅 분야에서 지배적인 영어로 작성되었기 때문에 많은 사람들이 계속해서 이전 도구를 사용하여 오늘날에도 여전히 찾아볼 수 있습니다.
유니코드에 대한 지원을 추가하는 것은 언어가 복잡하고 수많은 규칙을 가지고 있기 때문에 어렵습니다. 일부는 왼쪽에서 오른쪽으로, 일부는 오른쪽에서 왼쪽으로, 일부는 양방향으로, 일부는 위에서 아래로 진행됩니다. 그런 다음 문자에 추가 표시가 있습니다. 예를 들어 ¨독일어에서는 에서처럼 움라우트이지만 ü네덜란드에서는 에서처럼 트레마입니다 ë. 그러면 독일어로 u와 ü를 어떻게 정렬합니까? 네덜란드어의 e와 ë에도 동일한 규칙이 적용되나요? 이것은 계속해서 진행됩니다. 따라서 이런 종류의 작업에 대해 다양한 지원을 제공하는 많은 도구가 있습니다.
특히 xim 및 uim의 경우 초기에 잘린 문자(예: î 및 ñ)는 오늘날 대부분의 소프트웨어에서 문자로 간주하는 단일 유니코드 "코드 포인트"로 표시됩니다. 유니코드에서 ñ를 찾아보면 "물결표가 있는 라틴 소문자 N"이라는 코드 포인트라는 것을 알 수 있습니다. 그러나 어느 시점에서 유니코드는 문자와 토큰의 조합이 너무 많아서 단일 코드 포인트로 만들기에는 너무 많다는 것을 깨달았습니다. 그래서 그들은 "분음 부호를 결합한다"는 아이디어를 내놓았습니다. 문자와 표시를 결합하여 표시 문자를 형성하는 방법입니다. 사람들이 문자라고 생각하는 것(유니코드에서는 문자소라고 함)은 이제 문자와 하나 이상의 결합 토큰으로 구성될 수 있습니다. 이는 다음과 같이 다양한 문자소를 생성하는 방법을 제공합니다.이 게시물. 이제 ñ(U+00F1) 또는 ñ(U+006E U+0303)을 입력할 수 있고 모양과 의미도 동일하지만 컴퓨터에서 다르게 처리하기 때문에 여전히 문제가 있습니다. 그러나 적어도 이제는 유니코드 컨소시엄에 다른 문자 쌍을 추가하도록 요청할 필요 없이 Gə 또는 gə를 입력할 수 있습니다.
그러나 그렇게 하면 단일 문자가 단일 코드 포인트와 동일하다는 xim 및 많은 관련 코드가 작성되는 기본 가정이 깨집니다. X11과 xim은 단일 문자 ñ 출력에 적응할 수 있지만 ~n이는 상당한 재작성 없이 달성할 수 있는 한계입니다. uim은 모든 유니코드 복잡성을 처리하기 위해 유니코드 세계에 구축된 재정의입니다.
xim 대신 uim을 사용하려면 프로필, xprofile 또는 xinitrc에 다음을 추가하세요.
export GTK_IM_MODULE=uim
export QT_IM_MODULE=uim
uim-xim &
export XMODIFIERS=@im=uim
이는 시스템마다 다르지만 Google을 통해 특정 상황에 맞는 더 완전한 지침을 찾을 수 있습니다.