タグ付けされた質問 「unicode」

「おそらく最も人気のあるエンコーディングの1つであるUTF-16は有害と見なされるべきですか？」 なぜこの質問をするのですか？ UTF-16が実際に可変長エンコードであるという事実を知っているプログラマーは何人いますか？これにより、サロゲートペアとして表されるコードポイントがあり、複数の要素を取ることができます。 知っている; Javaの文字列、C＃の文字列、Win32 API、Qt GUIライブラリ、ICU Unicodeライブラリなど、多くのアプリケーション、フレームワーク、およびAPIはUTF-16を使用します。しかし、すべての処理には、処理に多くの基本的なバグBMP以外の文字（2つのUTF-16要素を使用してエンコードする必要のある文字）。 たとえば、次の文字のいずれかを編集してみてください。 𝄞（U + 1D11E）音楽記号Gクレフ U（U + 1D565）数学的なダブルトラックスモールT 𝟶（U + 1D7F6）数学的なモノスペースDIGIT ZERO 𠂊 （U + 2008A）ハン・キャラクター インストールしたフォントによっては、見逃す場合があります。これらのキャラクターはすべてBMP（Basic Multilingual Plane）の外部にあります。これらの文字が表示されない場合は、Unicode Character referenceでそれらを確認してみてください。 たとえば、Windowsでこれらの文字を含むファイル名を作成してみてください。「バックスペース」でこれらの文字を削除して、UTF-16を使用するさまざまなアプリケーションでの動作を確認してください。私はいくつかのテストを行いましたが、結果は非常に悪いです： Operaでの編集に問題があります（バックスペースで2回押す必要がある削除） メモ帳はそれらを正しく処理できません（バックスペースで必要な2つのプレスを削除します） ウィンドウダイアログでのファイル名の編集が壊れている（バックスペースで2回押す必要がある削除） すべてのQT3アプリケーションはそれらを処理できません-1 つのシンボルではなく2つの空の正方形を表示します。 u'X'!=unicode('X','utf-16')XがBMPの外の文字である場合、一部のプラットフォームで直接使用すると、Pythonはそのような文字を誤ってエンコードします。 Python 2.5 unicodedataは、PythonがUTF-16 Unicode文字列でコンパイルされている場合、そのような文字のプロパティを取得できません。 StackOverflowは、Unicode文字として直接編集された場合、これらの文字をテキストから削除するようです（これらの文字はHTML Unicodeエスケープを使用して表示されます）。 WinForms TextBoxは、MaxLengthで制限されている場合、無効な文字列を生成する場合があります。 このようなバグは、UTF-16を使用する多くのアプリケーションで非常に簡単に見つけることができるようです。 だから...あなたはUTF-16は有害と見なされるべきだと思いますか？

432 unicode 

エイリアンの侵入が発生し、既存のすべてのコンピューターシステムでそれらの言語をサポートすることを余儀なくされた場合、UTF-8は、おそらく大量の文字を許可するように設計されていますか？ （もちろん、エイリアンが実際に言語を持っているかどうか、コミュニケーションをするかどうか、またはその方法はわかりませんが、議論のために想像してください。） たとえば、言語が数百万の新しい発見されたグリフ、記号、および/または結合文字で構成されている場合、UTF-8は理論的にこれらの新しいグリフを含むように非破壊的な方法で拡張され、既存のすべてのソフトウェアをサポートできますか？ グリフが現在のサイズ制限をはるかに超えており、単一のグリフを表現するためにより多くのバイトを必要とするかどうかにより興味があります。UTF-8を展開できなかった場合、UTF-32に対する単一の利点は単に下位文字のサイズであることを証明していますか？

86 unicode  utf-8 

私は最近、ランキングアルゴリズムであるAllegSkillをPython 3に実装しようとしました。 数学は次のようになります。 いいえ、本当に。 これは私が書いたものです： t = (µw-µl)/c # those are used in e = ε/c # multiple places. σw_new = (σw**2 * (1 - (σw**2)/(c**2)*Wwin(t, e)) + γ**2)**.5 実際、Python 3が変数名を受け入れない、√または²変数名として受け入れないのは残念だと思いました。 >>> √ = lambda x: x**.5 File "<stdin>", line 1 √ = lambda x: x**.5 ^ SyntaxError: invalid character …

82 naming  unicode 

Unicodeは、以前の試み（ASCIIなど）のほとんどでアドレス空間（8ビット）が小さいため、多くの異なるエンコーディングを使用するという問題全体を回避するように設計されていると思いました。 では、なぜ多くのUnicodeエンコーディングがあるのですか？UTF-8、UTF-16などの（本質的に）同じバージョンの複数のバージョンでも

41 unicode  text-encoding 

基幹業務ソフトウェアを使用すると、ユーザーは特定のデータをCSVとして保存できます。野生ではさまざまなフォーマット（すべて「CSV」と呼ばれる）が使用されているため、「デフォルトのフォーマット」がどのように見えるかを決めようとしています。 行/フィールドの区切りとエスケープについては、使用できる標準があります：RFC 4180。 テキストエンコーディングに関して、UTF-8は過去10年で「デフォルトのテキストファイル形式」として登場したようです。そのため、これを使用します。 残っている質問は、最初にBOMを追加するかどうかです。一般にBOMの使用に関する複数の意見と賛否両論を読んでいますが、CSVファイルでのBOMの使用に関する「公式」の推奨事項または少なくとも何らかのコミュニティコンセンサスはありますか？

37 standards  unicode  csv  file-formats 

Unicode 利用規約では、データファイル（またはそれらの変更）を使用するソフトウェアにはUnicodeライセンスリファレンスを含める必要があると記載されています。ほとんどのUnicodeライブラリには、文字が数字、文字、記号などであるかどうかを確認する機能があるため、Unicodeデータファイルの変更（通常は表形式）が含まれているようです。それは、ライセンスが適用され、そのようなUnicodeライブラリを使用するすべてのアプリケーションがライセンスを保持する必要があることを意味しますか？ 確認したところ、ライセンスを保持しているユニコードプログラムはほとんどないようですが、ライセンスを保持していないもののほとんどはユニコードコンソーシアムのメンバーである企業のものです（ライセンスの免除は受けられますか？）。 一部（Mozillaなど）は「リエゾンメンバー」にすぎず、ソフトウェアはライセンスを保有していませんが（私の知る限り）、それらのデータファイルから派生したデータに依存しています。Mozillaはライセンスに違反していますか？ あらゆる形式の高度なUnicodeサポートを含む（つまり、Unicodeデータファイルに依存する必要がある）すべてのアプリでライセンスを保持する必要がありますか？または、何らかの形で広範な免除がありますか（ライセンスを保有するプログラムは非常に少ないため）。 この質問をUnicodeスタッフに転送しました。返信がある場合は、ここに投稿します。

35 unicode  licensing 

T-SQLを学んでいます。私が見た例から、varchar()セルにテキストを挿入するために、挿入する文字列だけを書くことができますが、nvarchar()セルの場合、すべての例は文字列の前に文字Nを付けます。 nvarchar()行があるテーブルで次のクエリを試しましたが、正常に機能するため、プレフィックスNは必要ありません。 insert into [TableName] values ('Hello', 'World') 私が見たすべての例で、文字列の先頭にNが付いているのはなぜですか？ このプレフィックスを使用することの長所と短所は何ですか？

34 sql  sql-server  character-encoding  unicode 

私の大嫌いな人は、文字セットをサポートするための山のようなコードを持つ非常に多くのソフトウェアプロジェクトを見ています。誤解しないでください、私はすべて互換性があるので、テキストエディタを使用して複数の文字セットでファイルを開いたり保存したりできることを嬉しく思います。私を悩ますのは、非ユニバーサル文字エンコーディングの急増が「問題」ではなく「適切なUnicodeサポート」とラベル付けされていることです。 たとえば、PostgreSQLとその文字セットサポートを選択します。PostgreSQLは2種類のエンコーディングを扱います。 クライアントのエンコード：クライアントとサーバー間の通信で使用されます。 サーバーのエンコード：データベースにテキストを内部的に保存するために使用されます。 多くのクライアントエンコーディングをサポートすることが良いことである理由を理解できます。UTF-8で動作しないクライアントは、変換を実行する必要なくPostgreSQLと通信できます。取得できないのは、PostgreSQLが複数のサーバーエンコーディングをサポートしている理由です。データベースファイルは（ほとんどの場合）PostgreSQLバージョン間で互換性がないため、ここではバージョン間の互換性は問題になりません。 UTF-8は、すべてのUnicodeコードポイントをエンコードできる唯一の標準のASCII互換文字セットです（間違っている場合はお知らせください）。私は、UTF-8が最高の文字セットであるという陣営にいますが、UTF-16やUTF-32などの他のユニバーサル文字セットに我慢します。 すべての非ユニバーサル文字セットは廃止されるべきだと思います。彼らがすべきではない説得力のある理由はありますか？

31 unicode  utf-8  character-encoding 

理由は、インデックスの文字へのアクセスのような高速配列だったと思いますが、一部の文字は16ビットに収まらないため、機能しません... とにかく特別なケースを処理する必要がある場合は、なぜUTF-8を使用しないのですか？

29 java  strings  unicode 

職場では、Shift-JISなどのエンコーディングの日本語のテキストファイルがたくさんあります。それは多くの原因が文字化け（判読できない文字）すべてのコンピュータユーザのための問題を。Unicodeは、すべての言語に単一の文字セットを定義することでこの種の問題を解決することを目的としており、インターネットでの使用にはUTF-8シリアル化が推奨されます。それでは、なぜ皆が日本語固有のエンコーディングからUTF-8に切り替えないのでしょうか？UTF-8のどのような問題や不利な点が人を引きつけていますか？ 編集：W3CはUnicodeに関するいくつかの既知の問題をリストしていますが、これも理由でしょうか？

24 legacy  unicode  character-encoding 

Unicodeにはおそらく50個のスペースがあります \ u0009 \ u000A- \ u000D \ u0020 \ u0085 \ u00A0 \ u1680 \ u180E \ u2000- \ u200A \ u2028 \ u2029 \ u202F \ u205F \ u3000] [\ u0009 \ u000A- \ u000D \ u0020 \ u0085 \ u0085 \ u00A0 \ u1680 \ u180E \ …

19 unicode 

PHPにはUnicodeに問題があることは誰もが知っています。Unicodeの実装が困難なため、バージョン6は事実上放棄されています。しかし、正確な理由は何か知っているのだろうか？アーキテクチャ/設計の問題、パフォーマンスの問題、コミュニティの問題（私は違います）、他に何か？

18 php  open-source  architecture  language-design  unicode 

Dev-DaysのJon Skeet（Tony the Ponyと一緒に）のプレゼンテーションを見ていました。 「文字列の逆関数を書く」はインタビュー101をコーディングしていますが、すべてのローカリゼーションとすべての文字列タイプで機能するものではなく、一般的な文字列の逆関数を書くことが実際に可能かどうかはわかりません。 入力文字列がASCII、UTF8、UTF16（固定長および可変長）などであるかどうかを検出することとは別に、 Jonが強調表示した「次の文字にアクセントを適用する」（U + 0301）コードがあります。次に、表示される場合とされない場合、または二重文字としてエンコードされる場合があります。 「文字列を逆にする」ことは、実際には難しいコンピューターサイエンスのタスクの1つであるようです。

16 algorithms  strings  unicode  localization 

UTF-16は固定幅ですか、可変幅ですか？さまざまなソースからさまざまな結果が得られました。 http://www.tbray.org/ongoing/When/200x/2003/04/26/UTFから： UTF-16は、Unicode文字を16ビットのチャンクに格納します。 http://en.wikipedia.org/wiki/UTF-16/UCS-2から： UTF-16（16ビットUnicode変換フォーマット）は、0〜0x10FFFFのUnicodeコードスペースで1,112,064 [1]数（コードポイントと呼ばれる）をエンコードできるUnicodeの文字エンコードです。コードポイントごとに1つまたは2つの16ビットコード単位の可変長の結果を生成します。 最初のソースから UTF-8には、エンコードの単位がバイトであるという利点もあるため、バイト順序の問題はありません。 UTF-8にバイト順の問題がないのはなぜですか？可変幅であり、1文字に複数のバイトが含まれている可能性があるため、バイトオーダーが依然として問題になると思いますか？ よろしくお願いします！

16 unicode  character-encoding  utf-8 

私はファイル形式を設計しており、それを正しく行いたいと思っています。バイナリ形式であるため、ファイルの最初のバイト（またはバイト）が有効なテキスト文字を形成しないようにする必要があります（PNGファイルヘッダー1のように）。これにより、形式を認識しないツールでも、最初の数バイトを調べることでテキストファイルではないことがわかります。 上記のコードポイント0x7Fはすべて無効なUS-ASCIIなので、簡単です。しかし、Unicodeの場合はまったく別の話です。別に有効なUnicode文字からある民間利用の文字、noncharactersと歩哨は私がに見られるような、Unicodeのプライベート用途のキャラクター、Noncharacters＆センチネルよくある質問。 無効なUS-ASCII、UTF-8、UTF-16LE、UTF-16BEになるファイルの先頭で使用できるバイトのセンチネルシーケンスは何でしょうか。 明らかに、最初のバイトは0x80有効なUS-ASCII（制御）文字になるため、以下の値を持つ0x00ことはできません。したがって、使用することはできません。 また、私用文字は有効なUnicode文字であるため、これらのコードポイントも使用できません。 それはリトルエンディアンとビッグエンディアンの両方のUTF-16で動作しなければならないので、非文字などは、0xFFFEその逆としてもできません0xFEFF有効なUnicode文字です。 上記の質問には、任意の使用していないことを示唆しているnoncharacters何かのようなので、まだ、有効なUnicodeシーケンスにつながることなどを0xFFFF行う画像のもあります。 私が使用するために残されている将来の保証のセンチネル値は何でしょうか？ 1）PNG形式には、最初のバイトとして非ASCII 0x89値があり、その後に文字列が続きますPNG。PNGの最初の数バイトを読んだツールは、それが解釈できないのでそれがバイナリファイルであると決定するかもしれません0x89。一方、GIFファイルは、有効で読み取り可能なASCII文字列で始まり、GIFその後にさらに3つの有効なASCII文字が続きます。GIFの場合、ツールは読み取り可能なテキストファイルであると判断する場合があります。これは間違っており、非テクスチャバイトシーケンスでファイルを開始するというアイデアは、Andy McFaddenによるDesigning File Formatsから生まれました。

14 unicode