명심해야 할 극단적인 경우. 부품 텍스트

소프트웨어 개발자, 카피라이터, 이메일을 작성하는 사람 모두 텍스트에는 주의해야 할 함정이 많이 있습니다. 일부는 앱의 버그부터 시각적 인공물, 심지어 피해자까지 수많은 문제를 일으킬 수 있습니다. 이를 방지할 수 있는 방법을 살펴보겠습니다.

배경

텍스트(일명 문자열)는 프로그래밍 언어, 플랫폼 등에 관계없이 hello-worlds와 같은 한 줄짜리 코드부터 수십억 줄의 코드가 포함된 엔터프라이즈 시스템에 이르기까지 거의 모든 소프트웨어 프로젝트에 존재합니다. 텍스트는 단지 문자의 연속이므로 로켓 과학이 되어서는 안 됩니다. 그렇죠? 어떤 함정을 만날 수 있는지 살펴보겠습니다!

레터 케이스

세계의 일부 알파벳(영어 포함)은 양원제입니다. 즉, 대문자와 소문자를 모두 포함합니다.
예를 들어, a는 소문자이고 A는 대문자입니다. 한 문자 대소문자를 다른 문자로 변환하는 것은 매우 일반적인 작업입니다.

대소문자 구분은 사소해 보일 수 있습니다. 한 문자가 다른 문자로 변환(매핑)됩니다. 1이나 + 등과 같이 문자가 아닌 경우 자체적으로 문자일 수도 있습니다. 또한 이 매핑은 언제든지 간단하게 되돌릴 수 있습니다. A->a 및 a->A. 그래서 언뜻 보면 모든 것이 괜찮아 보입니다. 글쎄요, 사실과 더 다를 수는 없습니다!

대소문자 오류로 인해 사망할 수 있음

이것은 농담이 아니며 분노한 문법 나치에 대해 말하는 것이 아닙니다. 이 기사에서 읽을 수 있듯이 케이싱 결함으로 인해 2명의 피해자가 발생하고 3명이 추가로 감옥에 갇혔습니다.

어떻게 된 거죠? 음, 터키어(및 아제르바이잔어)에는 점이 있는(닫힌) 문자와 점이 없는(열린) 문자 2개가 있습니다. 영어 및 기타 라틴 알파벳의 경우 소문자는 항상 점으로 표시되고 대문자는 점이 없습니다. 모든 내용은 표 1과 온라인 데모에 설명되어 있습니다.

표 1. 점선과 점이 없는 i 글자.

	Lowercase	Uppercase
English	i dotted	I dotless
Turkish	i dotted	İ dotted
Turkish	ı dotless	I dotless

보시다시피 대소문자 변경 결과는 컨텍스트에 따라 달라지며, 이는 현재 언어에 따라 더욱 달라집니다. 인간을 대상으로 한 텍스트를 작성할 때는 적절한 언어를 사용하는 것이 중요합니다. 이를 신경쓰지 않으면 당신의 말이 의도한 것과는 다른 의미를 갖게 될 수도 있습니다.

반면에 HTTP 헤더나 JSON 키와 같이 기계가 읽을 수 있는 텍스트는 언어 중립적인 방식으로 처리되어야 합니다. 그렇지 않으면 출력에 ASCII가 아닌 문자가 표시되어 애플리케이션 논리가 중단될 수 있습니다. 수천(또는 수백만)개의 프로젝트에서 사용되는 라이브러리인 GSON에서 바로 그러한 상황이 발생했습니다.

분음 부호의 비밀

발음 부호가 있는 문자는 ó와 같이 미리 구성되거나 ó와 같은 표시를 결합하여 생성될 수 있습니다. 이 페이지를 읽으면 둘 다 같은 캐릭터처럼 보입니다. 그러나 두 번째 항목의 hexdump를 보거나 이 데모에서와 같이 프로그래밍 방식으로 길이를 얻으려고 시도하면 라틴 소문자 o와 결합된 악센트라는 두 개의 개별 문자로 구성되어 있음을 알 수 있습니다. 마찬가지로 각 한글(한국어 알파벳) 음절 블록은 고유한 자모스 개별 문자/문자의 조합으로 미리 구성되거나 작성될 수 있습니다.

부호를 결합하는 것이 왜 그렇게 중요한가요? 발음 구별 부호가 있는 대부분의 문자를 작성하는 방법에는 두 가지가 있습니다(예: 폴란드어, 헝가리어 또는 체코어 알파벳). 이를 통해 정렬, 검색 또는 텍스트 길이 측정과 같은 작업이 간단해집니다. 일반적으로 최상의 사용자 경험을 얻으려면 텍스트를 정규화(정규 형식 중 하나로 변환)해야 합니다. 그렇지 않으면 사용자가 여러 개의 "다른" 로그인이나 동일해 보이는 파일 이름을 볼 때 혼란을 겪을 수 있습니다. 이에 대한 좋은 예는 Slack이 채널 이름을 처리하는 방법입니다. 채널 생성 이전에 정규화되기 때문에 같은 이름이 다른 방식으로 쓰여지는 상황은 공존할 수 없습니다.

일부 캐릭터는 다른 캐릭터보다 더 평등합니다.

캐릭터 동등성에는 2가지 레벨이 있습니다. 정규적 동등성은 문자가 의미와 모양 모두 동일하다고 가정할 때 발생합니다. 앞서 언급한 ó와 ó는 (기술적) 작성 방식만 다릅니다. 반면, 호환성은 문자가 뚜렷하게 보이지만 동일한 의미를 가질 수 있음을 의미합니다. 예를 들어 합자 ffi는 세 개의 서로 다른 문자 ffi와 호환되지만 정식으로 동일하지는 않습니다. 유니코드 정규화에 대한 자세한 내용은 표준 문서에서 확인할 수 있습니다.

각 2개 수준의 합성 형식과 분해 형식이 모두 표준화되어 있으므로 총 4개의 정규 형식이 있지만 정규화가 항상 되돌릴 수 있는 것은 아닙니다. 예를 들어 옹스트롬 기호 Å는 라틴어 대문자 A A와 ̊ 위의 결합 고리로 분해되며, 이는 원래 옹스트롬 기호가 아니라 Å 위에 고리가 있는 라틴어 대문자 A로 다시 구성됩니다.

콤보 정규화 버그로 인해 모험이 발생함

특정 텍스트를 공유하는 모든 애플리케이션이 동일한 정규화 방법을 사용하는 것도 중요합니다. 그렇지 않으면 미묘한 오류 및/또는 소리 없는 데이터 손실이 발생할 수 있습니다. 적어도 개별적으로 실행할 때는 각 응용 프로그램이 완벽하게 작동하기 때문에 이러한 버그를 발견하기 어려울 수 있습니다. 이러한 경우 응용 프로그램은 종종 "충돌"하지 않고 원래 데이터와 다른 데이터를 보내거나 수신하여 의도하지 않은 결과를 초래하는 경우가 많습니다. 그러한 예 중 하나가 nettalk의 버그입니다.

앞서 언급한 활자체 합자는 서로 인접해 있어 잘 보이지 않는 특정 문자의 시각적 모양을 개선하는 데 사용됩니다. 대부분의 사용자는 합자에 대해 걱정할 필요가 없습니다. 합자는 소프트웨어에 의해 개별 문자에서 자동으로 생성되기 때문입니다. TeX는 기본적으로 합자를 생성합니다. 그러나 이러한 도구의 개발자는 경우에 따라 합자가 부적절하고 오류가 발생할 수 있다는 점을 고려해야 합니다.

이것 좀 보세요: fi. 두 번째 글자는 점선인가요, 점이 없나요? 터키어를 사용하는 독자들은 혼란스러울 수 있습니다. i가 포함된 합자는 일부 상황에서 사용하면 안 됩니다.

내 대문자는 어디에 있나요?

라틴어 및 그리스어와 같은 일부 문자(소위 양원제)에는 두 가지 경우의 문자가 포함되어 있습니다. 거의 모든 문자에는 소문자와 대문자가 있습니다. 사실상… 그러나 전부는 아닙니다!
소문자 세트는 항상 존재하지만 대문자에는 해당되지 않습니다. 그렇다면 소문자만 있는 문자가 있는 경우 이를 대문자로 변환하려고 하면 어떻게 될까요? 작업이 실패하게 만드는 오류일까요? 캐릭터는 그대로 유지되나요? 대답은 그런 것이 아닙니다!

가장 눈에 띄는 예 중 하나는 독일의 샤프 s — ß입니다. 소문자이며, 대문자로 변환하면 이중 S - SS가 됩니다. 해당 변환은 되돌릴 수 없습니다. SS는 ss가 됩니다. 온라인에서 확인하세요. TL;DR 유니코드 5.1에는 ẞ(라틴 대문자 SHARP S)가 도입되었지만 일반적으로 문자 매핑 측면에서 ß의 대문자로 간주되지 않습니다. 이는 최근(2016년) SS의 유효한 형식으로 독일 철자법 규칙 세트에 추가되었습니다.

다른 많은 소문자 합자에는 미리 구성된 대문자 형식이 없습니다. 전체 목록은 유니코드 특수 케이스 문서에서 찾을 수 있습니다.

이중 또는 삼중 문제

몇몇 대문자가 빠졌는데 어쩌죠? 합자는 2~3자로 구성될 수 있으므로 대문자 텍스트는 원래 소문자보다 3배 더 길어질 수 있습니다. 이는 결과 텍스트 길이가 제한되어 있는 경우 매우 중요합니다. 예를 들어 bitrise.io의 이 버그와 같은 아바타 또는 이니셜 생성기에서 사용됩니다.

myσteriouς 세 번째 사례

그리스어 알파벳에는 대문자 Σ와 같은 시그마 문자가 포함되어 있습니다. 소문자 형태는 무엇입니까? 글쎄요, 상황에 따라 다릅니다! 보통 σ(끝이 아님)이지만 단어 끝에는 ς(끝)이 붙습니다. 그러나 시그마가 유일한 문자이거나 단어가 모두 대문자로 작성된 경우 최종 위치에서도 항상 최종 버전이 아닌 버전이 사용됩니다. 대화형 예시를 확인하세요.

또 다른 극단적인 경우

물결표 Ĩ가 있는 라틴 대문자 i의 소문자는 무엇인가요? 짐작하셨겠지만, 대답은 그렇게 사소하지 않습니다. 해당 소문자 형식이 존재합니다. 두 가지 형태 모두 점이 없지만 완벽하게 정상입니다. i와 j 모두 발음 구별 부호가 붙어 있으면 점이 없습니다. 그렇다면 여기서 문제는 무엇입니까?

터키어 외에도 리투아니아 철자법 규칙도 I 문자의 경우 예외적입니다. 후자의 경우 점은 악센트 아래에 유지됩니다. 예를 들어, 앞서 언급한 Ĩ가 리투아니아어 문맥에서 소문자로 표시되면 i̇̃가 됩니다. 주의 깊게 살펴보면 라틴어 소문자 i, 위의 결합 점, 위의 결합 물결표 등 3개의 문자가 있음을 알 수 있습니다. (다시) 글의 길이가 3배나 늘어났습니다.

합자와 다중 그래프를 계속 사용하세요

단 6글자만으로 7글자로 구성된 단어를 어떻게 쓸 수 있나요? 미리 구성된 합자와 다중 문자(두문자, 삼중문자 등)를 사용하세요! 물론 결합된 문자의 가능한 각 조합에 대해 미리 구성된 문자는 없습니다. 그러나 기존 항목을 사용하여 텍스트 길이 제한을 효과적으로 늘릴 수 있습니다. 예를 들어, 실레지아어 단어 dzbonek(화분)은 7자로 구성되지만 6자만 사용하여 τbonek으로 쓸 수 있습니다. 온라인에서 확인하세요. γ는 합자가 아니라 이중문자입니다.

이제 140자 이상의 트윗 메시지를 작성할 수 있습니다! 사전 구성된 유니코드 이중 문자 및 합자의 목록은 여기에서 찾을 수 있습니다.

거의 알려지지 않은 알파벳 순서 방법

가나다순은 보통 초등학교 초에 가르칩니다. A, B, C, D… 그리고 Z까지. 파이만큼 쉽습니다!

아쉽게도 알파벳 순서는 언어에 따라 다릅니다. 분음 부호 없이 기본 라틴 문자의 위치도 다를 수 있습니다. 예를 들어 에스토니아어에서는 문자 Z가 S와 T 사이에 있습니다.

발음 부호가 있는 문자의 위치도 보편적이지 않습니다. 여러 가지 가능한 계획이 있습니다:

1. 몰타어와 같이 해당 기본 문자 앞: W, X, Ż, Z

2. 폴란드어와 같이 해당 기본 문자 뒤에 A, Ą, B, C, Ć.

3. 스웨덴어처럼 알파벳 끝에는 Z, Å, ä가 있습니다.

4. 헝가리어처럼 기본 문자와 동일한 위치(조합 목적으로): O=Ó.

동일한 문자가 다양한 언어에서 다르게 조합될 수 있으며, 상황에 따라 동일한 언어에서도 다를 수 있습니다!. 예를 들어, 슬로바키아어에서는 움라우트가 있는 A가 항상 A 뒤에 위치합니다. 그러나 독일어에서는 움라우트가 없는 버전과 동일한 값을 가질 수도 있고 그 뒤에 위치하거나 A+E로 처리될 수도 있습니다. 어떤 경우에 어떤 방식이 사용되는지에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

빵, 금전 등록기 및 카지노

조합 대상은 개별 문자뿐만이 아닙니다. 다중 그래프에는 자체 규칙이 있을 수도 있습니다. 슬로바키아어에서 CH는 H와 I 사이에 조합됩니다. 따라서 예를 들어 chlieb(빵)이라는 단어는 hodina(1시간) 뒤에 조합됩니다. 반면 폴란드어에서는 이중 문자가 두 개의 별도 문자인 C와 H처럼 취급되므로 특별한 조합 규칙이 없습니다. 온라인에서 만나보세요.

헝가리 문자에는 이중 이중 문자도 있으며 각 문자에는 고유한 조합 규칙이 있습니다. 이로 인해 복잡한 사례가 많이 발생합니다. 한 가지 가능한 예를 고려해 보겠습니다. SZ 이중그래프가 있습니다. S 다음에 정렬됩니다. 이중 버전(SZ + SZ)은 SSZ입니다. 이는 kaszinó(카지노)라는 단어가 kassza(금전 등록기) 앞에 와야 함을 의미합니다. 일반적으로 Z는 S 뒤에 오지만 여기서는 첫 번째 단어에 K A SZ I가 있고 두 번째 단어에 K A SZ SZ가 있습니다.

게다가, 동일한 문자 그룹은 문맥에 따라 (이중) 이중 문자일 수도 있고 아닐 수도 있습니다. 예를 들어 앞서 언급한 슬로바키아어 CH는 일부 단어에서 C와 H라는 두 개의 별도 문자로 처리됩니다. viachlas(다성음악). 일반적으로 헝가리어에서는 mennybolt(천국)라는 단어처럼 NNY = NY + NY입니다. 그러나 NNY = N + NY인 tizennyolc(18)도 있으므로 단일 문자 N과 단일 이중 문자 NY가 있습니다.

ΤНΙЅ ІЅ NОТ WНΑТ ΥОҍ ТНІNΚ ІТ ΙЅ

위의 헤드라인이 평범한 라틴 문자로만 구성되어 있다고 생각할 수도 있습니다. 실제로 대부분은 그리스어, 키릴 문자 또는 아르메니아어 대문자입니다. 일부 라틴 문자의 동형문자일 뿐입니다.

따라서 A(라틴어 대문자 A)는 Α(그리스어 대문자 알파) 또는 А(키릴어 대문자 A)와 동일하지 않습니다. 이것이 왜 중요합니까? 구별이 불가능하기 때문에 IDN 동형어 공격에 사용될 수 있습니다. 예를 들어 라틴 문자만 포함된 도메인bank.com은 라틴어 소문자 A 대신 키릴 문자 소문자 A를 포함하는 bаnk.com과 거의 동일해 보입니다. 이러한 도메인은 피싱에 사용될 수 있습니다.

마무리

경우에 따라 텍스트를 처리하는 것이 까다로울 수 있습니다. 특히 다국어 환경에서 작업하는 경우 더욱 그렇습니다. 경험상 모든 구성은 주어진 상황에 적합해야 합니다. 예를 들어, 사용자에게 표시되는 텍스트를 처리할 때는 사용자의 현재 언어를 고려해야 하며, 기계가 읽을 수 있는 텍스트는 언어 중립적인 방식으로(또는 가능하지 않은 경우 영어를 사용하여) 처리해야 합니다. 선택한 데이터 정렬 설정은 실제 사용량과도 일치해야 합니다. 텍스트는 필요할 때 정규화되어야 하며 선택한 정규화 방법은 전체 시스템에서 일관되어야 합니다.
더 많은 극단적인 경우에 대해 알고 싶으십니까? 2부가 곧 시작됩니다!

위 내용은 명심해야 할 극단적인 경우. 부품 텍스트의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!