問題タブ [ucs2]

SortableIntFieldのソース コードを読んでいるときに、整数を文字列に変換するときに、このクラスが「UCS-16 サロゲート」を回避していることに気付きました ( NumberUtils.javaint int2sortableStr(int, char[], int)のメソッドを参照)。

これらのキャラクターはどのような問題を提起しますか?

http://www.python.org/dev/peps/pep-0100/

PEP 100 は、内部形式の Python Unicode が UTF-16 エンコーディングを保持すると述べていますが、値は UCS-2 (または flag でコンパイルされた場合は UCS-4 --enable-unicode=ucs4) として扱われます。

UCS-2 (固定長) ではなく、UTF-16 (可変長形式) が選択されなかったのはなぜですか?

2 つのエンコーディングはほとんど同じですが、PEP-100 が公開されたとき (2000 年 3 月)、UTF-16 はすでに 4 歳でした。Python Unicode は後方互換性の問題に対処するためのものでしたか?

エンコードされたデータを内部に保存するために、この（一見）ハイブリッドアプローチを使用してPythonの内部フォーマットが実装された理由について、私は本当に興味がありますか？

私の質問をするより良い方法は次のとおりです: PEP 100 が UTF-16 を使用する代わりに UCS-2 として UTF-16 を扱うことを選択した理由を具体的に述べている公式文書からの引用またはリンクを誰かが持っていますか?

私はそれを呼び出してそれにテキストを渡すPHPのコード/ライブラリを探しています、そしてそれは私に教えてくれます：

1. このテキストをSMS（7,8,16ビット）として送信するために使用する必要のあるエンコードは何ですか
2. このテキストを送信するために使用するSMSメッセージの数（ http://ozekisms.com/index.php?owpn=612のように「セグメント情報」を数えるのが賢明である必要があります）

私のためにこれを行うコード/ライブラリが存在するという考えはありますか？

繰り返しになりますが、テキストに関する情報を提供するためだけに、SMSの送信やSMSの変換を探しているわけではありません。

アップデート：

わかりました、私は以下のコードを実行しました、そしてそれはうまく働いているようです、あなたがより良い/最適化されたコード/ソリューション/libを持っているかどうか私に知らせてください

フラッシュアプ​​リとテキストフィールドがあります。システムトレイのロケールを変更して、Unicode文字を入力できます（たとえば、Windows -1251エンコーディングを使用）。jqueryを使用してユニコード化されたテキストを送信してデータベースに保存する場合、windows-1251エンコードまたはUTF-8などの他のエンコードとしてどのようにそこに到達しますか？

または、最初にどのエンコーディングでjqueryに到達するかを言いましょう。

データのリストがある場合:

$a = "hello";

$b= "4f60";

$c = "hi";

$d = "00480065006C006C006F";

$b と $d は UCS-2 文字列です。これらすべてのデータを表に表示したいのですが、どのデータが UCS-2 であるかを知り、表示する前に変換できるようにするにはどうすればよいですか? 出来ますか ？php.net で見つかったユニコードに対して mb_detect_encoding と preg_match を試しましたが、それでもユニコードと見なされる未知のシンボルです。

ありがとうございました。

大部分が英語ですが、場合によってはそうではないデータを、非常に大きくなる可能性のある SQL Server データベースに格納するオプションを調査している間、私はほとんどの文字列データを UTF-8 エンコードとして格納することに傾いています。

ただし、Microsoft が UCS-2 を選択した理由は、私が完全に理解していないためです。SQL Server 2012 のドキュメントにはUTF-8 UDTを作成する方法が示されていますが、UCS-2 の決定はおそらく SQL Server に浸透しています。

ウィキペディア(興味深いことに、UCS-2 は廃止され、UTF-16 が優先されていることに注意してください) では、UTF-8 は任意の Unicode データ ポイントをエンコードできる可変幅文字セットであり、provides the de facto standard encoding for interchange of Unicode text. したがって、どの Unicode 文字も UTF-8 で表現できるように感じられ、ほとんどのテキストは英語になるため、表現は UCS-2 の場合のほぼ 2 倍になります (ディスクが「安い」ことは知っていますが、ディスク キャッシュはそうではありません)。多くの操作は、ワーキング セットが使用可能な RAM よりも大きい場合、指数関数的に低下します)。

UCS-2 ストリームを泳ぐと、どのような問題が発生する可能性がありますか?

USSDメッセージが160バイトで構成されていることを理解しました。7ビットのデータコーディング方式の場合、最大文字数は160 * 8/7で、182文字になります。UCS2エンコーディングの最大文字数はわかりません。通常は160/2のようなものですが、これについてはさまざまな情報があります。

更新された質問¹

文字クラス、比較、並べ替え、正規化、および照合に関して、どの .NET プラットフォームでどの Unicode バージョンがサポートされていますか?

元の質問

.NET が Unicode バージョン 3.0 をサポートしていること、および内部の UTF-16 エンコーディングが実際には UTF-16 ではなく、実際には UCS-2 を使用していることを漠然と読んだことを覚えています。これは同じではありません。たとえば、U+FFFF を超える文字は使用できないようです。つまり、次のように考えてください。

そして、文字列を格納します"ᵽ9"。

私は基本的に、次の回答の決定的な参照を探しています。

• .NET の真の UTF-16 でない場合、それは何ですか?
• .NET でサポートされている Unicode のバージョンは何ですか?
• 最近のバージョンがサポートされていないか、近い将来に計画されていない場合、誰かが (非) 商用ライブラリを知っていますか、またはこの問題を回避する方法を教えてください。

¹）時間の経過とともに質問を更新しました。回答とより大きなコミュニティに関しては、より適切なようです。コメントで回答された部分の代わりに、元の質問を残しました。また、古い UCS-2 (サロゲートなし) は現在の古い 32 ビット Windows バージョンで使用され、.NET は常に内部で UTF-16 (サロゲートあり) を使用してきました。

技術的には UCS2-LE (BOM なし) ですが、UTF-16 の .NET で問題なくロードできるフラット ファイルがあります。これは、UCS-2 が UTF-16 よりも古い標準であるためだと理解しています。優先します。

ただし、私が興味を持っているのは、ファイルが実際に UCS-2 であるかどうかを判断できることです。私はこれが私が推測していることを意味することを知っています. 私は chardet の .NET ポート、IMultilang2 相互運用機能、および UTF-16 を介した UCS-2 の決定を引き出すために Novell によるいくつかのオープン ソースを試しましたが、成功しませんでした。UCS-2LE w/o BOM と無効/長すぎる UTF-8 の違いを判断できる手法は見つかりませんでした。

それらをバイトごとに検査し、それが可変長か固定長かを判断しようとする必要がありますか? 欠落しているコードポイントを探しますか? 問題は、これらのテキスト ファイルには特別なコードポイントがなく、標準的な西欧文字セットしかないことです。しかし、TextPad はそれらを BOM なしの UCS2-LE として保存し、UTF-16 に完全に準拠することを望むソフトウェアでの下流のファイル操作を複雑にします (ファイルを強制的にロードするだけでは機能しますが、ソフトウェアの要件では機能しません)。 ）。

SIM900 GPRS の SMS でこのメッセージを受け取ります。

07916698019021F00410D05479BDDC7CBBCB790008217002123430826A0049006E0063006F00720072006500630074002000700061007300730077006F00720064002E00200050006C050610306500065060740507202079060750702007001070730700F0700402001060010600E02

別のサンプル メッセージ:

07916698019021F00410D05479BDDC7CBBCB790008217002025501826A0049006E0063006F00720072006500630074002000700061007300730077006F00720064002E00200050006C06001073050200506E04065070200906F07072020700607307007060020600006007060090600E

このメッセージは Unicode UCS-2 形式で、タイ語だと思います。ただし、それを読み取り可能なものに変換することはできません。私はこの非常に便利なコードを見つけました:

前もって感謝します。