あなたがソフトウェア開発者であっても、コピーライターであっても、あるいは単に電子メールを書いているだけであっても、テキストには注意しなければならない多くの罠があります。アプリのバグから視覚的なアーティファクト、さらには被害者に至るまで、多数の問題を引き起こす可能性があります。それらを回避する方法を見てみましょう。
テキスト (別名文字列) は、プログラミング言語やプラットフォームなどに関係なく、hello-worlds のようなワンライナーから数十億行のコードを含むエンタープライズ システムに至るまで、事実上すべてのソフトウェア プロジェクトに存在します。テキストは単なる文字の連続ですから、これはロケット科学ではありませんよね?どのようなトラップに遭遇するかを見てみましょう!
世界のアルファベットの一部 (英語を含む) は二院制であり、大文字と小文字の両方が含まれています。
たとえば、a は小文字、A は大文字です。ある大文字と小文字を別の文字に変換することは、非常に一般的な操作です。
大文字と小文字の区別は些細なことのように思えるかもしれません。ある文字が別の文字に変換 (マッピング) されているだけです。 1 や + などの文字でなくても、それ自体が文字である場合もあります。さらに、このマッピングはいつでも簡単に反転できます。 A->a および a->A。したがって、一見するとすべてが順調に見えます。まあ、これ以上真実からかけ離れたものはありません!
これは冗談ではなく、激怒したナチスの文法について話しているわけでもありません。この記事にあるように、筐体の不具合により 2 人の犠牲者が発生し、さらに 3 人が刑務所に入れられました。
どうしてそうなったのですか？トルコ語 (およびアゼルバイジャン語) には、点線 (閉じた) と点なし (開いた) という 2 つの異なる i 文字があります。英語およびその他のラテン文字では、小文字には常にドットが付きますが、大文字にはドットがありません。すべては表 1 とオンライン デモに示されています。
表 1. ドット付きおよびドットなしの i 文字。
| 小文字 | 大文字 | |
|---|---|---|
| 英語 | 点在しました | ドットレス |
| トルコ語 | 点在しました | 点点 |
| トルコ語 | ドットレス | ドットレス |
ご覧のとおり、大文字と小文字の変更結果はコンテキストに依存し、さらに現在の言語に依存します。人間向けの文章を作成するときは、適切な言語を使用することが重要です。これを無視すると、あなたの言葉が意図とは異なる意味になってしまう可能性があります
一方、HTTP ヘッダーや JSON キーなどの機械可読テキストは、言語に依存しない方法で処理する必要があります。そうしないと、出力に非 ASCII 文字が表示され、アプリケーション ロジックが破損する可能性があります。まさにその状況が、数千 (あるいは数百万) のプロジェクトで使用されるライブラリである GSON で発生しました。
発音記号の秘密 発音記号を含む文字は、ó のように事前に合成することも、ó のような記号を組み合わせて作成することもできます。このページを読むと、どちらも同じキャラクターに見えます。しかし、2 番目の 16 進ダンプを見るか、このデモのようにプログラムでその長さを取得しようとすると、それが 2 つの個別の文字で構成されていることがわかります: ラテン語の小文字 o とアキュートアクセントの組み合わせです。同様に、各ハングル (韓国語のアルファベット) 音節ブロックは、事前に構成することも、個別の jamos の個々の文字の組み合わせとして記述することもできます。 なぜマークを組み合わせることがそれほど重要なのでしょうか?そうですね、発音記号を使用してほとんどの文字を書くには 2 つの方法があります (たとえば、ポーランド語、ハンガリー語、またはチェコ語のアルファベットから)。これにより、並べ替え、検索、テキストの長さの測定などの操作が重要になります。通常、最高のユーザー エクスペリエンスを実現するには、テキストを正規化する (通常の形式の 1 つに変換する) 必要があります。そうしないと、たとえば、同じように見える複数の「異なる」ログイン名やファイル名を見たときにユーザーが混乱する可能性があります。この好例は、Slack がチャネル名を処理する方法です。チャンネル作成前に正規化されるため、同じ名前が異なる方法で書かれている状況は共存できません。 一部のキャラクターは他のキャラクターよりも平等です キャラクターの同等性には2つのレベルがあります。正規等価性は、文字の意味と外観の両方が同じであると想定される場合に発生します。前述の ó と ó は、(技術的な) 書き方が異なるだけです。一方、互換性は、文字が異なって見えるが、意味は同じである可能性があることを意味します。たとえば、合字 は 3 つの異なる文字 ffi と互換性がありますが、これらは標準的に同等ではありません。 Unicode 正規化の詳細については、標準ドキュメントを参照してください。
各 2 レベルの合成形式と分解形式の両方が標準化されているため、合計 4 つの正規形式がありますが、正規化は常に可逆であるとは限りません。たとえば、オングストローム記号 Å は、ラテン大文字 A A と ̊ の上の環を組み合わせたものに分解され、元のオングストローム記号ではなく、Å の上に環をもつラテン大文字 A に再構成されます。 コンボ正規化バグが冒険を引き起こす 特定のテキストを共有するすべてのアプリケーションが同じ正規化方法を使用することも重要です。そうしないと、微妙なエラーが発生したり、サイレントなデータ損失が発生したりする可能性があります。各アプリケーションは、少なくとも個別に実行している場合には問題なく動作するため、このようなバグを発見するのは難しい場合があります。このような場合、アプリケーションは多くの場合「クラッシュ」せず、本来とは異なるデータを送受信するだけで、予期せぬ結果を引き起こします。そのような例の 1 つは、nettalk のこのバグです。 前述のタイポグラフィーの合字は、相互に隣接すると見にくい特定の文字の見た目を改善するために使用されます。合字はソフトウェアによって個々の文字から自動的に生成されるため、ほとんどのユーザーは合字について心配する必要はありません。 TeX はデフォルトで合字を生成します。ただし、このようなツールの開発者は、場合によっては合字が不適切でエラーが発生する可能性があることを考慮する必要があります。 これを見てください: 2 番目の文字は点付きですか、それとも点なしですか?トルコ語を話す読者は混乱するかもしれません。 i を含む合字は、状況によっては使用しないでください。 私の大文字はどこにありますか？ ラテン語やギリシャ語などのいくつかの文字 (いわゆる二院制) には 2 つの格の文字が含まれています。事実上すべての文字には小文字と大文字があります。事実上…しかし、絶対にすべてというわけではありません!小文字セットは常に存在しますが、大文字には当てはまりません。では、小文字しかない文字がある場合、それを大文字に変換しようとするとどうなるでしょうか?操作が失敗する原因となるエラーでしょうか?性格はそのままでしょうか？答えはそんなものではありません！
가장 눈에 띄는 예 중 하나는 독일의 샤프 s — ß입니다. 소문자이며, 대문자로 변환하면 이중 S - SS가 됩니다. 해당 변환은 되돌릴 수 없습니다. SS는 ss가 됩니다. 온라인에서 확인하세요. TL;DR 유니코드 5.1에는 ẞ(라틴 대문자 SHARP S)가 도입되었지만 일반적으로 문자 매핑 측면에서 ß의 대문자로 간주되지 않습니다. 이는 최근(2016년) SS의 유효한 형식으로 독일 철자법 규칙 세트에 추가되었습니다.
다른 많은 소문자 합자에는 미리 구성된 대문자 형식이 없습니다. 전체 목록은 유니코드 특수 케이스 문서에서 찾을 수 있습니다.
일부 대문자가 빠졌는데 어쩌죠? 합자는 2~3자로 구성될 수 있으므로 대문자 텍스트는 원래 소문자보다 3배 더 길어질 수 있습니다. 이는 결과 텍스트 길이가 제한되어 있는 경우 매우 중요합니다. 예를 들어 bitrise.io의 이 버그와 같은 아바타 또는 이니셜 생성기에서.
그리스어 알파벳에는 대문자 Σ와 같은 시그마 문자가 포함되어 있습니다. 소문자 형태는 무엇입니까? 글쎄요, 상황에 따라 다릅니다! 보통 σ(끝이 아님)이지만 단어 끝에는 ς(끝)이 붙습니다. 그러나 시그마가 유일한 문자이거나 단어가 모두 대문자로 작성된 경우 최종 위치에서도 항상 최종 버전이 아닌 버전이 사용됩니다. 대화형 예시를 확인하세요.
라틴어 대문자 i에 물결표 Ĩ가 있는 소문자는 무엇인가요? 짐작하셨겠지만, 대답은 그렇게 사소하지 않습니다. 해당 소문자 형식이 존재합니다. 두 가지 형태 모두 점이 없지만 완벽하게 정상입니다. i와 j 모두 발음 구별 부호가 붙어 있으면 점이 없습니다. 그렇다면 여기서 문제는 무엇입니까?
터키어 외에도 리투아니아 철자법 규칙도 I 문자의 경우 예외적입니다. 후자의 경우 점은 악센트 아래에 유지됩니다. 예를 들어, 앞서 언급한 Ĩ가 리투아니아어 문맥에서 소문자로 표시되면 i̇̃가 됩니다. 주의 깊게 살펴보면 라틴어 소문자 i, 위의 결합 점, 위의 결합 물결표 등 3개의 문자가 있음을 알 수 있습니다. 텍스트 길이가 (다시) 3배로 늘어났습니다.
단 6글자만 사용하여 7글자로 구성된 단어를 어떻게 쓸 수 있나요? 미리 구성된 합자와 다중 문자(두문자, 삼중문자 등)를 사용하세요! 물론 결합된 문자의 가능한 각 조합에 대해 미리 구성된 문자는 없습니다. 그러나 기존 항목을 사용하여 텍스트 길이 제한을 효과적으로 늘릴 수 있습니다. 예를 들어, 실레지아 단어dzbonek(화분)은 7자로 구성되지만 6자만 사용하여ϳbonek로 쓸 수 있습니다. 온라인에서 확인하세요. γ는 합자가 아니라 이중문자라는 점에 유의하세요.
이제 예를 들어 140자 이상의 문자를 포함하는 트윗 메시지를 작성할 수 있습니다! 사전 구성된 유니코드 이중 문자 및 합자의 목록은 여기에서 찾을 수 있습니다.
알파벳순은 보통 초등학교 초에 가르칩니다. A, B, C, D… 그리고 Z까지. 파이만큼 쉽습니다!
안타깝게도 알파벳 순서는 언어에 따라 다릅니다. 분음 부호 없이 기본 라틴 문자의 위치도 다를 수 있습니다. 예를 들어 에스토니아어에서 문자 Z는 S와 T 사이에 있습니다.
발음 구별 부호가 있는 문자의 위치도 보편적이지 않습니다. 몇 가지 가능한 계획이 있습니다:
몰타어와 같이 해당 기본 문자 앞: W, X, Ż, Z.
폴란드어와 같이 해당 기본 문자 뒤에 A, Ą, B, C, Ć.
스웨덴어처럼 알파벳 끝에: Z, Å, ä.
헝가리어처럼 기본 문자와 동일한 위치(조합 목적으로): 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가 있습니다.
위의 헤드라인이 평범한 라틴 문자로만 구성되어 있다고 생각할 수도 있습니다. 실제로 대부분은 그리스어, 키릴 문자 또는 아르메니아어 대문자입니다. 일부 라틴 문자의 동형문자일 뿐입니다.
따라서 A(라틴어 대문자 A)는 Α(그리스어 대문자 알파) 또는 А(키릴어 대문자 A)와 동일하지 않습니다. 이것이 왜 중요합니까? 구별이 불가능하기 때문에 IDN 동형어 공격에 사용될 수 있습니다. 예를 들어 라틴 문자만 포함된 도메인bank.com은 라틴어 소문자 A 대신 키릴 문자 소문자 A를 포함하는 bаnk.com과 거의 동일해 보입니다. 이러한 도메인은 피싱에 사용될 수 있습니다.
어떤 경우에는 텍스트를 처리하는 것이 까다로울 수 있습니다. 특히 다국어 환경에서 작업하는 경우 더욱 그렇습니다. 경험상 모든 구성은 주어진 상황에 적합해야 합니다. 예를 들어, 사용자에게 표시되는 텍스트를 처리할 때는 사용자의 현재 언어를 고려해야 하며, 기계가 읽을 수 있는 텍스트는 언어 중립적인 방식으로(또는 가능하지 않은 경우 영어를 사용하여) 처리해야 합니다. 선택한 데이터 정렬 설정은 실제 사용량과도 일치해야 합니다. 필요할 때 텍스트를 정규화해야 하며 선택한 정규화 방법은 전체 시스템에서 일관되어야 합니다.
더 많은 극단적인 경우에 대해 알고 싶으십니까? 2부가 곧 시작됩니다!
위 내용은 명심해야 할 극단적인 경우. 부품 텍스트의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
