![한 번의 키를 누르면 몇 바이트가 반환될 수 있습니까? 메타 키가 더 많은 것을 반환해야 합니까?](https://linux55.com/image/62209/%ED%95%9C%20%EB%B2%88%EC%9D%98%20%ED%82%A4%EB%A5%BC%20%EB%88%84%EB%A5%B4%EB%A9%B4%20%EB%AA%87%20%EB%B0%94%EC%9D%B4%ED%8A%B8%EA%B0%80%20%EB%B0%98%ED%99%98%EB%90%A0%20%EC%88%98%20%EC%9E%88%EC%8A%B5%EB%8B%88%EA%B9%8C%3F%20%EB%A9%94%ED%83%80%20%ED%82%A4%EA%B0%80%20%EB%8D%94%20%EB%A7%8E%EC%9D%80%20%EA%B2%83%EC%9D%84%20%EB%B0%98%ED%99%98%ED%95%B4%EC%95%BC%20%ED%95%A9%EB%8B%88%EA%B9%8C%3F.png)
나는 이 도구를 사용해 왔다.독자 입력최근의. 현재는 실행 중에 누르는 모든 키에 대해 stdout에 보고서를 인쇄하지만, 잘 진행되는 것 같으면 곧 더 높은 목적으로 업그레이드하고 싶습니다. 지금까지는 몇 가지 장점이 있습니다.
- 모든 출력은 단일 파이프의 여러 동시 프로세스의 결과입니다.
- 각 키를 누른 직후에 각 키 누름을 해석하고 보고합니다.
- 그것(내가 아는 한)키를 누를 때마다 전송된 바이트 수를 보고합니다.
예를 들어, 실행하고 다음 키/키 조합을 순서대로 누르면...
- a
- CTRL+J
- ALT+SPACE
- UP
- ALT+UP
...키를 누를 때마다 한 줄씩, 키를 누를 때마다 즉시 터미널 화면에 다음을 인쇄합니다.
a:97
\n:10
\240:160
\e:27 [:91 A:65
\e:27 [:91 1:49 ;:59 5:53 A:65
...각 키 누르기의 각 바이트는 다음과 같이 인쇄됩니다...
<space>(printable char|\C-escape|\octal-escape):[decimal byte value]
...내 생각에는 그게 적절하다고 생각해요.
그러나 그들 중 일부는 나를 혼란스럽게 합니다.
- 모든 키를 시도해 본 것 같고 명시적으로
stty
8비트 문자를 보내 도록 설정했지만(가져오다cs8
), ALT+ SPACE조합은 ASCII 십진수 127 이상의 구성 바이트를 보고하는 유일한 조합인 것 같습니다.- ALT수정자와 관련이 있다고 생각했기 때문에 특히 혼란스럽습니다.원비행(나는 이 개념에 대해 거의 모른다는 것을 인정합니다)키 시퀀스이지만 다른 모든 경우 ALT+는 단지 시퀀스 접두사를 붙이 anykey거나 이미 이스케이프된 시퀀스를 미묘하게 수정합니다.ESC
- ~해야 한다ALT 아니요전송된 시퀀스를 더 높은 128 - 255 범위로 이동하시겠습니까?
- (아래 derobert의 의견에서 독자는 멀티바이트 UTF-8
compose
시퀀스를 성공적으로 해석하고 보고했습니다.) 참고: 다음으로 설정된locale
모든 카테고리를 보고합니다 .LC_*
en_US.UTF-8
- 또한 우려되는 점은 각 키 누르기에 대한 모든 바이트를 가져오는 것처럼 보이지만 현재 형식에서는 내 스크립트가 키 누르기를
8바이트(현재 최대 32바이트)로 구분한다는 것입니다.- 나는 전에 생각했다8바이트그것만으로도 충분하지만, 이제 다른 로케일의 멀티바이트 문자가 내가 본 더 긴 이스케이프 시퀀스와 결합될 수 있는지 고려할 때 회의적입니다. 그래서 버퍼를 확장했습니다. 하지만 원래 나에게 주어진 8바이트만큼 결정적이지는 않습니다.
- 한 번의 키 누름으로 전송할 수 있는 바이트 수에 상한이 있습니까?
답변1
이것은 실제로 몇 가지 질문입니다. 일부는 터미널별 동작을 처리하고 일부는 조합을 처리합니다.
Alt첫째, 수식어로 사용될 때 예상되는 행위에 대한 질문이 있다 . 어떤 사람들은 Alt키(많은 키보드에 표시됨)를 키 Meta(터미널 키보드에 표시되는 경우가 거의 없음)와 동일시합니다. 어떤 사람들은 더 나아가 이를 이스케이프 문자와 동일시합니다. 불러라전통적인사용. 적어도 xterm에서는 연관을 구성할 수 있습니다(왜냐하면패치 번호 122, 1999metaSendsEscape
, 리소스 가 있고패치 번호 225, 2007추가 altIsNotMeta
및 altSendsEscape
리소스). 다른 터미널 에뮬레이터(및 해당 사용자)는 유연성이 없습니다. 그래서 거기에관습이는 이스케이프 및 메타와 동일합니다. 컨벤션은 표준이 아닙니다.
메타 키의 로깅 동작은 다음 위치에 있습니다.terminfo(5) 매뉴얼 페이지:
터미널에 있는 경우"메타 키"전송된 문자의 8번째 비트를 설정하는 Shift 키 역할을 한다는 사실을 사용할 수 있습니다.
km
. 그렇지 않으면 소프트웨어는 비트 8이 패리티 비트라고 가정하고 일반적으로 지워집니다. 이 "메타 모드"를 켜고 끄는 문자열이 있는 경우 다음과 같이 지정할 수 있습니다.smm
그리고rmm
.
메타모드가 꺼진 경우에는 표준 동작(관례만 있음)이 없습니다.
eightBitInput
xterm의 리소스 에 따라 128보다 높은 메타키 생성자를 사용할 수 있습니다. 예를 들어,패치 번호 183, 2003, 이 변경은 메타모드가 불법적인 UTF-8을 생성하는 것을 방지하기 위해 이루어졌습니다.
- UTF-8 모드에서 EveryBitInput 리소스 처리를 수정하고 값을 UTF-8로 변환합니다. 그렇지 않으면 불법 UTF-8 코드가 애플리케이션으로 전송됩니다(Bram Moolenaar 보고).
그러나 일반적으로 터미널 및 터미널과 함께 사용할 수 있는 대부분의 이스케이프 시퀀스는전통적인키보드에서 반환된 이스케이프 시퀀스는 7비트 ASCII를 사용합니다. VT100도 예외는 아닙니다.2002년 패치 번호 177:
- 잘못된 제어 시퀀스 감지 기능을 향상시키기 위해 파서 테이블을 수정하여 xterm이 실제 DEC 터미널처럼 작동하도록 만듭니다(Paul Williams 패치).
즉, 파서 테이블은 다음과 같습니다.최대조직에서는 입력 문자의 8번째 숫자를 무시합니다. 다른 터미널에서는 이 측면을 무시할 수 있지만 여전히 xterm 키보드에 사용되는 이스케이프 시퀀스를 복사합니다. 결과는 당신이다최대7비트 ASCII를 참조하세요.
여러분이 보게 될 대부분의 동작은 xterm으로 시작하기 때문에 xterm을 예로 사용하고 있습니다.유지하다rxvt에서). xterm을 사용하면 키에서 상당히 긴 이스케이프 시퀀스를 얻는 여러 상황에 직면할 수 있습니다. 예를 들어,
- 패턴을 사용하여
modifyOtherKeys
키보드의 (대부분) 키에 이스케이프 시퀀스를 할당합니다. translations
"모든" 문자 시퀀스를 보낼 수 있는 리소스 사용- 이
DECUDK
함수를 사용하여 응용 프로그램에서 정의한 문자열(16진수 시퀀스)을 보냅니다.
다른 터미널(예: OSX Terminal.app 및 iTerm2)도 사용자 구성 가능한 문자열을 보낼 수 있습니다. 이러한 관점에서 볼 때 키가 전송하는 바이트 수에는 명확하게 정의된 제한이 없습니다.
반면에 compose는 더 명확하게 정의되어 있습니다. 결과는 주어진 인코딩의 문자(또는 여러 문자?)입니다. 문자가 하나만 있다고 가정합니다. 최대값기준UTF-8로 인코딩된 문자의 길이는 4바이트입니다. 때를할 수 있다사용자가 구성한 키가 이 데이터를 보내는 것을 보면 대부분의 경우(호환성 및 규칙으로 인해) 두 가지(이스케이프 시퀀스 및 인코딩된 문자)가 함께 혼합된 것을 볼 수 없습니다.
추가 자료:
- bash에서 Alt 키가 작동하지 않습니다(ncurses FAQ)
- UTF-8로 인코딩된 문자의 최대 바이트 수는 얼마입니까?