web-dev-qa-db-ja.com

\ u202b RLEと\ u202c PDEのUnicode対応データベースへのUnicodeストレージ？

私はトポニム用の新製品を作成しており、その中でアラビア語は次のようなものを示しています。

^IArabic^I<202b>ﺰﻤﺑﺎﺑﻮﻳ<202c>^I<202b>ﺞﻫﻭﺮﻳﺓ ﺰﻤﺑﺎﺑﻮﻳ<202c>$

実はそれほどでもない。これは、ASCII表示端末の実際の問題なので、例外とスクリーンショットのテキストを作成します。

Arabic

私の質問は、それらについて 202B "右から左への埋め込み"（RLE） と 202C "ポップ方向の書式設定"（PDF） です。それらはデータとして保存されますか？私の最初の仮定は、キャラクターはファイルではなくレンダリングされたものであるということでした。

360    5E03 97E6 5171 548C 56FD 000A 0009 0041 0072 0061 0062 0069 0063 0009 202B 0632    布韦共和国..Arabic..ز
.............................................................................^HERE
389    0645 0628 0627 0628 0648 064A 202C 0009 202B 064F 062C 0647 0648 0631 064A 0629    مبابوي...ُجهورية
.....................................^HERE.....^HERE
422    0020 0632 0645 0628 0627 0628 0648 064A 202C 000A 0009 004E 006F 0074 0065 0073    .زمبابوي...Notes
...............................................^HERE

アラビア語をデータベースに格納する場合、通常\u202b、\u202c？技術的にデータではなく、キャラクターをレンダリングしているように見えますか？私は単にこのテキストを処理してデータベースにスローしたいのですが、これらの文字がデータベースに存在するのか、それとも挿入前に削除されるのか疑問に思っています。

バックグラウンド

postgresqlencodingunicode
4
Evan Carroll

アラビア語（およびヘブライ語とシリア語）は、右から左へ記述する言語です。したがって、それらは、バイトが物理的に格納されているのとは反対の方向で表示されます。適切な表示を行うことは、フォント/レンダリングシステムによってのみ解釈される印刷不可能な文字によって制御されます。特にこれらの2つの文字は、これを制御するために使用されます（初心者向けの元のUnicode仕様を参照： https://www.unicode.org/charts/PDF/U2000.pdf ）、特に埋め込みのコンテキストでは左から右へのテキストと同じ段落内の右から左へのテキスト（およびその逆）。

そのため、それらを保存しておく必要があります。そうしないと、後でこのデータを表示しようとすると、言語の表示方法が逆になり、データの損失と見なされます。これらは、印刷不可/ゼロ幅の多くのフォーマット制御文字の1つです。

Unicodeコンソーシアムによる、これらの文字の操作方法に関する「公式」の説明は次のとおりです（「 第23章：特殊領域とフォーマット文字 ページ868の上部から取得）：

他のフォーマット制御文字と同様に、双方向の順序制御はそれらが含まれるテキストのレイアウトに影響しますが、ソートや検索などの他のテキストプロセスでは無視する必要があります。ただし、テキストコンテンツを変更するテキストプロセスでは、これらの文字を正しく維持する必要があります。双方向の順序付けコントロールの対応するペアを調整して、双方向テキストのレイアウトと解釈を妨げないようにする必要があるためです。 lre、rle、lro、またはrloの各インスタンスは、通常、対応するpdfとペアになります。同様に、lri、rli、またはfsiの各インスタンスは、通常、対応するpdiとペアになります。

これらの隠されたフォーマットコードポイントを保持する（破棄しない）重要性に関して、セクション「 2.7マークアップとフォーマット文字 」の「Unicode®標準付属書＃9：UNICODE BIDIRECTIONAL ALGORITHM」=状態（強調鉱山） ：

明示的な書式設定文字は、プレーンテキストに状態を導入します。これは、テキストを編集または表示するときに維持する必要があります。この状態を認識せずにテキストを変更しているプロセスは、PDFを削除するなどして、テキストの大部分のレンダリングに誤って影響を与える可能性があります。

そして：

マークアップ（ed：HTMLおよび/またはCSS）を含むドキュメントからプレーンテキストが生成されるときは常に、正しい順序付けが失われないように、同等のフォーマット文字を導入する必要があります。

Cal Henderson（O.P.の回答から引用）による（優れた） " nderstanding Bidirectional（BIDI）Text in Unicode "）文書にさらに説明があります。

...これらの明示的な文字（U + 202A-U + 202E）を禁止することもできますが、これはかなり簡単です。これは、アラビア語のユーザー名の端にニュートラルを含めるためにそれらを使用することを望む誰もが不運になることを意味します-そして、それが彼らが投稿しているコメントであるとき、それはもっと悪いことです、そこで期間は「の始まり」にジャンプしますテキスト。

これらの文字の使用を許可する場合、解決策はかなり単純です（実装が難しい場合）。すべての開始マーカーにペアの終了マーカー（PDF）があることを確認して、文字列から出てくる状態スタックがまた、Pushマーカーを伴わずにPDFを使用できないように注意する必要があります。そうしないと、ブロックの外で自分自身を使用できません。

したがって、特定のセルのテキストが完全に右から左への言語であると想定されている場合でも、これらのマーカーを削除するとニュートラルの配置が変わる可能性があります文字（句読点など）。例（SQL Serverを使用）：

SELECT NCHAR(0x0671) + NCHAR(0x0679) +  N'!';
-- ٱٹ!

SELECT NCHAR(0x202B) + NCHAR(0x0671) + NCHAR(0x0679) + N'!' + NCHAR(0x202C);
-- ‫ٱٹ!‬

それらを後で追加することを計画したり、クライアントアプリでそれらを追加したりすることは、それらが使用されていること、および使用されている場合はそれらが配置されていることを知る固有の手段がないため、機能しません。

safestアプローチは、これらの文字を保持することです

たとえば、このテキストの一部を質問の上部に含めようとしています：

^IArabic^I<202b>ﺰﻤﺑﺎﺑﻮﻳ<202c>^I<202b>ﺞﻫﻭﺮﻳﺓ ﺰﻤﺑﺎﺑﻮﻳ<202c>$

しかし、それが正しい順序で表示されていないことは明らかです。ただし、バイトは正しい順序です。

最初の<202b>...<202c>セクションだけを見ます（ここでも、SQL Serverを使用しているため、リトルエンディアンです）。

SELECT CONVERT(VARBINARY(MAX), N'<202b>ﺰﻤﺑﺎﺑﻮﻳ<202c>');

バイトは次のとおりです。

3C00 3200 3000 3200 6200 3E00 B0FE E4FE 91FE 8EFE 91FE EEFE F3FE 3C00 3200 3000 3200 6300 3E00
<    2    0    2    b    >    .    .    .    .    .    .    .    <    2    0    2    c    >

ご覧のとおり、追加のフォーマット文字はありません。アラビア語の文字は右から左に強いため、後続の文字– <202 –はニュートラル（<）および弱い（202）であり、左側に見出しを表示し続けます（<を>に変換することもできます）。そして明確にするために、202自体は左から右に表示されますが、その数が回文ではなかった場合はより明確になります。数値が203の場合でも、302ではなく203と表示されます。ただし、cは左から右に強いため、期待どおりに表示されます（およびそれに続く文字）。

直し方？アラビア語の直後に暗黙の左から右へのマーカーを追加して、右から左への方向性がそのポイントで終了することを示します。これらの2つのセグメントそれぞれの最後のアラビア文字の後（および<の直前）にコードポイントU + 200Eを追加すると、次のようになります。

^IArabic^I<202b>ﺰﻤﺑﺎﺑﻮﻳ‎<202c>^I<202b>ﺞﻫﻭﺮﻳﺓ ﺰﻤﺑﺎﺑﻮﻳ‎<202c>$

ここで、StackOverflowが書式設定を削除すると、誤った表示に戻り、プログラムで検出できる、ここで何が必要かという意図が示されません。

書式設定を削除して後で追加したい場合、これらの文字が存在する理由について100％確信していますか？それらが常に使用されるわけではないので、それらが存在するときにそれらが使用される理由をどうやって知るのですか？アラビア語以外の文字は存在しないと思いませんか？では、<202>をどのように分類しますか？ 「b」と「c」を省略したのは、ラテン文字を含まない句読点と数字があり、「完全にアラビア語」のままであるためです。

これが私がそれらを保つことは行くための「最も安全な」ルートであると言った理由です。唯一のルートではありません。しかし、入力値を制御しないと、データの意味を誤って変更しないことを保証できる方法がわかりません。

6
Solomon Rutzky

U + 202BとU + 202Cの文字を処理するだけの問題よりも、状況が深刻です。私はまずあなたの最も近い質問に答え、それからより重要な答えに行きます。

データベースにアラビア語を保存する場合、通常 + 202B "右から左への埋め込み"（RLE） および + 202C "ポップ方向のフォーマット"（PDF） を保存する必要があります=文字？いいえ。データ値のプレーンテキストを言語に依存しない方法で保存します。 U + 202BとU + 202Cは、異なる方向性の文字が混在するデータ値内にある場合にのみ保存します。

これらの文字が入力データに存在するのはなぜですか？入力データはPDFファイルから抽出されたようです。PDFファイルは、PDFビューアで正しく表示するためにのみ作成されたと思います。抽出したテキストが転用に使用できるとわかった場合は、幸運です。 PDFファイルから抽出されたテキストをクリーンアップする必要があることを期待してください。

抽出されたテキストは、左から右の方向性を持つラテン語のスクリプトテキストと、右から左の方向性を持つアラビア語のスクリプトテキストが混在していることに注意してください。テキストを作成したどのソフトウェアでも、U + 202BとU + 202Cの文字がその目的に役立つことがわかったようです。キャラクターがあなたの目的に役立つということにはなりません。 U + 0009 TAB文字を除外するのと同じように、方向性フォーマット文字を適切に除外します。

アラビア語のテキストをチェックして、読み取り順にファイルに保存されていることを確認します。テキストはPDFファイルから抽出されるため、表示順に保存される場合があります。つまり、アラビア語の文字が抽出で逆の順序になる可能性があります。

さて、あなたが尋ねなかった重要な質問に対するいくつかの回答。

これらの文字はすべてのアラビア語テキストの表示と処理に必要ですか？いいえ。しかし、それらはしばしば必要です。

これを理解するのに最適な場所は AX＃9Unicode Bidirectional Algorithm です。アラビア語の正書法は、右から左に表示されるアラビア文字と数字と左から右に表示されるラテン文字を組み合わせているため、アラビア語のテキストはbidirectionalと呼ばれます。

Unicode標準は、文字のプロパティを定義します。これらのプロパティの中には、双方向タイプがあります。キャラクターには、左から右または右から左のタイプ、弱いタイプ、またはニュートラルタイプがあります。文字は、双方向タイプに関係なく、読み取り順に格納されます。 Unicode双方向アルゴリズムは、文字を読み取り方向から始めて、正しい方向の組み合わせで表示する方法を指定します。 U + 202BやU + 202Cのような双方向フォーマット文字は、双方向型だけでは不十分なときにアルゴリズムが正しい結果を得るのに役立ちます。

入力からStackExchange Webフォームにラインを貼り付けた結果、「ASCIIスピーチターミナル」とは異なる結果になったのはなぜですか。 StackExchange WebフォームをレンダリングするブラウザーがUnicode双方向アルゴリズムを適用するためです。アラビア語が読めないのでわかりませんが、アラビア語のテキストが「<」、「2」、「0」、「2」の部分に分割された後の「<202c>」が表示されているようです。右から左、「c」、「>」の部分が左から右に表示されます。また、「<」は右から左へ「>」として表示されます。一方、端末では、Unicode Bidirectional Algorithmを適用せずに、各文字をストレージ順に個別に表示する可能性があります。

現地の言語で地名を取得したい場合、国連が作成したPDFファイルからテキストを削り取ったままにしませんか？いいえ。ローカライズされた場所名の他の2つのソースは Wikidata と Common Locale Data Repository です。ウィキデータには ザンビア のページがあり、国のローカライズされた名前がさまざまな言語で表示されています。このデータを機械可読形式で抽出するクエリがあります。 CLDRは アラビア語での多くの国の名前 を簡単に示します。すべての言語のこのデータをクエリすることにより、ザンビアまたはすべての国の名前をすべての使用可能な言語で持つようにリファクタリングできます。

このアラビア語のテキストをデータベースフィールドに格納する方法を理解しているだけなら、おそらく良い結果が得られますか？私は恐れていません。

あなたのデータベースと、データベースからのデータを表示するWebページまたはアプリケーションは、これまで左から右へのテキストしか処理していなかったと思います。アラビア語のテキストを追加することで、データベースだけでなく、アプリケーションにも双方向テキストが発生します。データベースとアプリが解決する必要がある双方向性に関連する新しい問題があります。データ要素を表示するときに方向性コンテキストをどのように決定しますか？システムのどのソフトウェアがUnicode Bidirectional Algorithmを実行しますか？使用する言語と文字に基づいて、データ項目に適切なフォントをどのように選択しますか？アプリまたはWebページに右から左へのレイアウトで表示する機能を追加しますか？

方向フォーマット文字を削除してアラビア語のテキストをデータベースに投げるだけで十分な結果が得られることを願っています。このテキストを含めると、双方向性について今まで心配する必要がなかった質問に直面する必要があることを覚悟しておいてください。

4
Jim DeLaHunt

これを行うには明らかに3つのアプローチがあり、正しい答えはありません、

  1. ファーストストロング。 Unicodeには強い、弱い、中立的な文字があることがわかります。アラビア文字は「強い」です。このスキームでは、最初のストロングキャラクターを探し、それがデフォルトの方向性であると想定します。特別なフォーマット文字はデータベースに保存されません。
    • マーカーでFirst-strongを増強する。このスキームでは、RLMやLRMのようなものを格納し、高度な局所性を備えた基本フォーマットをオーバーライドします。
  2. ペアのフォーマット。コントロールポイントを使用して、文字列自体の具体的な基本方向を示します。これは、「明示的な方向の埋め込み」、「明示的な方向のオーバーライド」で確認できます。基本的に、テキストのリフロー中に新しい方向性をプッシュしてから、元の方向性にポップします。したがって、THIS IS ENGLISH <tempchange>this is something a non-ASCII spewing person would write</tempchange> MORE ENGLISHのようなものを使用できます。上記では、MORE ENGLISHに到達すると、THIS IS ENGLISHの方向に戻ります。これには上記のPDFが含まれます。
  3. メタデータ。言語のメタデータを保存し、スマートクライアント（templete以降のコンシューマ）がそのメタデータを使用して文字列をレンダリングできるようにします。これは、変換テーブルが機能するように聞こえる方法です。

それでも説得力がない場合は、 Unicode仕様 からのこの直接引用を検討してください。

国際化のベストプラクティスは、言語に依存しないデータを格納して通信し、そのデータをクライアント用にフォーマットすることです。このフォーマットは、システム内のコンポーネントの数。サーバーは、ユーザーのロケールに基づいてデータをフォーマットする場合と、クライアントマシンがフォーマットする場合があります。データの解析やロケールに依存したデータの分析についても同様です。

そしてまた、

そのデータをエンドユーザーのできるだけ近くにローカライズしてください。

私の見方では、これを読む方法の一般的なルールは、セルが双方向ではない場合、つまり、セルが完全にLTRまたはRTLであり、文字の言語から推測できることです（これらは強い次に、英語とアラビア語で）、クライアントにその処理を実行させ、方向性を指定するこれらの文字を取り除いてから格納します。ドキュメントのベース言語の外でテキストをレンダリングする必要がある場合は、末尾のニュートラル文字がジャンプしないようにテキストを追加する必要があります （ジムの回答で述べたように） 。

思考実験のために、LRMマークがあります。したがって、技術的には英語のみのフレーズを保存し、方向性を明示的に宣言することができます。しかし、データベースでそれを見た場合は、それらの制御文字も削除します。ラテン系のアルファベットでは方向性が暗示されているからです。

こちらもご覧ください

3
Evan Carroll