Unicode関数
Unicode関数は、システムによる保存方法ではなく、読み手による認識方法に基づいてテキストを処理します。これらの関数は、英語以外のテキスト、見た目は同一だが等しくない文字列、および外部ソースからの潜在的に不正なテキストに使用します。
機能の提供状況
WELは現在、一部のお客様にご利用いただけます。ご利用のワークスペースで利用可能かどうかを確認するには、Customer Success Representativeにお問い合わせください。
書記素クラスター
書記素クラスターは、個々のコードポイントではなく、ユーザーが認識する文字を表します。家族の絵文字は1文字として表示されますが、複数のコードポイントで構成されています。アクセント付き文字は、1つのコードポイントとして保存することも、文字と結合記号として保存することもできます。
| Formula | 結果 |
|---|---|
grapheme_length('👨👩👧') | 1 |
length('👨👩👧') | 5 |
テキストを切り詰める場合や入力フィールドで文字数制限を適用する場合など、表示やユーザー向けの文字数カウントには書記素関数を使用します。
grapheme_length
ユーザーが認識する文字(書記素クラスター)をカウントします。
grapheme_length(text)| パラメーター | 説明 |
|---|---|
| テキスト | 測定する文字列。 |
家族の絵文字内の書記素クラスターをカウント
次の例では、複数のコードポイントで構成された家族の絵文字内の書記素クラスターをカウントします。
Formula
grapheme_length('👨👩👧')出力
1grapheme_substring
複数のコードポイントを含む文字を分割せずに、書記素クラスターのインデックスでテキストを抽出します。
負の開始位置は末尾からカウントします。開始位置が末尾と完全に一致する場合は空の文字列を返します。その他の範囲外の開始位置ではE201が発生します。
grapheme_substring(text, start, length)| パラメーター | 説明 |
|---|---|
| テキスト | 抽出元の文字列。 |
| start | ゼロ始まりの書記素インデックス。負の値は末尾から数えます。 |
| length | 省略可能な書記素クラスター数。 |
書記素インデックスで部分文字列を抽出
次の例では、アクセント付き単語から2書記素の部分文字列を抽出します。
Formula
grapheme_substring('héllo', 0, 2)出力
hégrapheme_reverse
書記素クラスター単位で文字列を反転します。
grapheme_reverse(text)| パラメーター | 説明 |
|---|---|
| テキスト | 反転する文字列。 |
書記素クラスター単位で文字列を反転
次の例では、書記素クラスター単位で文字列を反転します。
Formula
grapheme_reverse('abc')出力
cbagrapheme_lpadおよびgrapheme_rpad
文字列を書記素クラスターで測定した幅にパディングします。
非ASCIIテキストを含む固定幅の出力では、読み手に列がそろって見えるように、lpadおよびrpadではなくこれらを使用します。
grapheme_lpad(text, width, pad)
grapheme_rpad(text, width, pad)| パラメーター | 説明 |
|---|---|
| テキスト | パディングする文字列。 |
| width | 書記素クラスター単位のターゲット幅。 |
| pad | パディング文字列。 |
文字列の左側をパディング
次の例では、文字列の左側を幅5の書記素クラスターにパディングします。
Formula
grapheme_lpad('42', 5, '0')出力
00042文字列の右側をパディング
次の例では、文字列の右側を幅5の書記素クラスターにパディングします。
Formula
grapheme_rpad('42', 5, '0')出力
42000正規化
システムは、同じ表示テキストを異なる方法で保存できます。例えば、caféには単一のé、またはeに続く結合アクセントを含めることができます。これらの表現は見た目は同一ですが、等しくありません。この違いにより、既存のレコードのルックアップが失敗する可能性があります。
正規化によりテキストが標準形式に変換されるため、比較が機能します。
| フォーム | 機能 |
|---|---|
nfc | 合成: 記号を単一の文字に結合します。保存には通常この形式を選択します。 |
nfd | 分解: 文字を基底文字と結合記号に分割します。 |
nfkc | 合成し、全角から半角などの互換バリアントを畳み込みます。 |
nfkd | 分解し、互換バリアントを畳み込みます。 |
データの到着時にnfcに正規化すると、下流の比較が正常に動作します。
unicode_normalize
文字列を指定された正規化形式に変換します。
unicode_normalize(text, form)| パラメーター | 説明 |
|---|---|
| テキスト | 正規化する文字列。 |
| form | nfc、nfd、nfkc、またはnfkd。 |
合成形式の長さ
次の例では、合成形式の長さを測定します。
Formula
length('café')出力
4分解形式の長さ
次の例では、文字列をNFDに変換した後の長さを測定します。
Formula
length(unicode_normalize('café', 'nfd'))出力
5分解形式ではアクセントが個別の結合記号になるため、1単位長くなります。 2つの形式は画面上では同一に見えます。
unicode_normalized?
文字列がすでに指定された形式になっている場合はtrueを返します。
unicode_normalized?(text, form)| パラメーター | 説明 |
|---|---|
| テキスト | テストする文字列。 |
| form | nfc、nfd、nfkc、またはnfkd。 |
合成文字列はすでにNFC
次の例では、合成文字列をNFC形式に対してテストします。
Formula
unicode_normalized?('café', 'nfc')出力
true分解文字列はNFCではありません
次の例では、分解文字列をNFC形式に対してテストします。
Formula
unicode_normalized?(unicode_normalize('café', 'nfd'), 'nfc')出力
falseunicode_compare
両方の文字列を正規化した後に比較し、-1、0、または1を返します。
unicode_compareは、2つの異なるシステムからのテキストを比較する信頼できる方法です。通常の==は保存されている内容を比較します。 unicode_compareは書かれている内容を比較します。
unicode_compare(first, second, form)| パラメーター | 説明 |
|---|---|
| first | 最初の文字列。 |
| second | 2番目の文字列。 |
| form | 省略可能な正規化形式。デフォルトはnfcです。 |
合成文字列と分解文字列を比較
次の例では、合成文字列をその分解形式と比較します。
Formula
unicode_compare('café', unicode_normalize('café', 'nfd'))出力
02つの引数は異なる方法で保存されていますが、等しいものとして比較されます。これがこの関数の要点です。
不正なテキストの検出
外部から到着するテキストは、それを読む人を誤解させるように構成されている場合があります。これらの関数はその意図を明らかにします。
unicode_contains_suspicious?
双方向オーバーライド、ゼロ幅文字、紛らわしい類似文字、Zalgoスタッキング、私用領域のコードポイントなど、人を欺くように設計されたテキストを検出します。
unicode_contains_suspicious?(text)
unicode_contains_suspicious?(text, options)| パラメーター | 説明 |
|---|---|
| テキスト | テストする文字列。 |
| options | チェックごとに1つのBooleanスイッチを含む、省略可能なマップ。
|
通常のドメインは疑わしくありません
次の例では、すべてラテン文字で構成されたドメインをテストします。
Formula
unicode_contains_suspicious?('paypal.com')出力
false類似ドメインは疑わしい
次の例では、キリル文字の類似文字を含むドメインをテストします。
Formula
unicode_contains_suspicious?('pаypal.com')出力
trueこの2つの文字列は同じではありません
2番目には、ラテン文字のaの代わりにキリル文字のаが含まれています。ほとんどのフォントでは同一に表示されるため、それを承認する人は違いを見分けられません。
支払いのサプライヤー名、通知のドメイン、承認リクエストの表示名など、信頼できないソースからのテキストに対しては、人が対応する前にこのチェックを実行します。
unicode_contains_bidi?
右から左に記述する文字を検出します。
右から左に記述する文字は、アラビア語およびヘブライ語のテキストでは正当なものです。また、文字列を保存されている順序とは異なる順序で表示させる攻撃の背後にある仕組みでもあります。そのため、trueの結果はそれ自体がエラーではなく、確認するためのシグナルとして扱います。
unicode_contains_bidi?(text)| パラメーター | 説明 |
|---|---|
| テキスト | テストする文字列。 |
通常のASCIIテキストには双方向文字がありません
次の例では、通常のASCIIテキストをテストします。
Formula
unicode_contains_bidi?('hello')出力
falseunicode_contains_emoji?
絵文字を検出します。
unicode_contains_emoji?(text)| パラメーター | 説明 |
|---|---|
| テキスト | テストする文字列。 |
絵文字を含むテキスト
次の例では、絵文字を含む文字列をテストします。
Formula
unicode_contains_emoji?('ok 👍')出力
true絵文字を含まないテキスト
次の例では、絵文字を含まない文字列をテストします。
Formula
unicode_contains_emoji?('plain')出力
false日本語テキスト
日本語システムでは、2つのかな表記と2つの文字幅を区別し、多くの場合、特定の組み合わせが必要です。これら6つの関数は、それらの間で変換します。
hiragana_to_katakanaおよびkatakana_to_hiragana
2つのかな表記の間で変換します。
hiragana_to_katakana(text)
katakana_to_hiragana(text)| パラメーター | 説明 |
|---|---|
| テキスト | 変換する文字列。 |
ひらがなをカタカナに変換
次の例では、ひらがなをカタカナに変換します。
Formula
hiragana_to_katakana('ひらがな')出力
ヒラガナカタカナをひらがなに変換
次の例では、カタカナをひらがなに変換します。
Formula
katakana_to_hiragana('カタカナ')出力
かたかなto_fullwidth_asciiおよびto_halfwidth_ascii
ASCII文字を全角形式と半角形式の間で変換します。
to_fullwidth_ascii(text)
to_halfwidth_ascii(text)| パラメーター | 説明 |
|---|---|
| テキスト | 変換する文字列。 |
ASCIIを全角に変換
次の例では、ASCII文字を全角形式に変換します。
Formula
to_fullwidth_ascii('AB1')出力
AB1ASCIIを半角に変換
次の例では、全角文字を半角ASCII形式に戻します。
Formula
to_halfwidth_ascii('AB1')出力
AB1to_fullwidth_katakanaおよびto_halfwidth_katakana
カタカナを全角形式と半角形式の間で変換します。
to_fullwidth_katakana(text)
to_halfwidth_katakana(text)| パラメーター | 説明 |
|---|---|
| テキスト | 変換する文字列。 |
カタカナを全角に変換
次の例では、半角カタカナを全角形式に変換します。
Formula
to_fullwidth_katakana('カタカナ')出力
カタカナカタカナを半角に変換
次の例では、全角カタカナを半角形式に変換します。
Formula
to_halfwidth_katakana('カタカナ')出力
カタカナユースケース: システム間で照合する前に名前を正規化
2つのシステムが同じ顧客を保持していますが、一方では名前が分解形式で保存されています。 Unicode関数を使用して両方の名前を正規化し、照合が成功するようにします。また、自動的に照合すべきでないものにはフラグを付けます。
入力
{
"crm_name": "café",
"erp_name": "café"
}Formula
{
equal_as_stored: _.crm_name == _.erp_name,
equal_normalized: unicode_compare(_.crm_name, _.erp_name) == 0,
needs_review: unicode_contains_suspicious?(_.erp_name)
}出力
{
"equal_as_stored": false,
"equal_normalized": true,
"needs_review": false
}入力内の2つの名前は同じバイトではありません。 CRMではéを1文字として保存し、ERPではeと結合アクセントとして保存しています。これらは同一に表示され、いくら見ても違いは分かりません。
そのため、通常の==ではこれらは異なる顧客だと判断されます。その誤った結果がバグです。重複レコードが作成され、その後内容がずれていくためです。
関連情報
- 文字列関数:
length、substring、lpadと、それらのバイト指向の動作。 - エンコーディング関数: 名前付きエンコーディングでテキストをバイトに変換します。
- 共通関数: データ型全体にわたる
lengthに関する情報。 - エラーコード:
E201などのジョブ失敗をトラブルシューティングします。
最終更新日: