タグ付けされた質問 「utf-8」

最近、クエリパラメータ「utf8 =✓」を含むURIをいくつか見ました。私の最初の印象（「うーん、かっこいい」と思った後）は、これを使用して壊れた文字エンコードを検出できるということでした。 それで、これは文字エンコーディングの潜在的な問題を解決するより良い方法ですか、それとも単にハックを楽しんでいる開発者ですか？

569 validation  http-request  utf-8 

私のファイルシステム（Windows 7）には、いくつかのテキストファイルがあります（重要な場合、これらはSQLスクリプトファイルです）。 Notepad ++で開くと、「エンコード」メニューで「UCS-2リトルエンディアン」と「BOMなしのUTF-8」のエンコードが報告されます。 ここの違いは何ですか？それらはすべて完全に有効なスクリプトのようです。Notepad ++なしでファイルにどのエンコーディングが含まれているかをどのように確認できますか？

115 file-systems  character-encoding  utf-8  notepad++ 

ASCIIのすべての文字は、ストレージを増やすことなくUTF-8を使用してエンコードできます（どちらも1バイトのストレージが必要です）。 UTF-8には、「ASCII文字」を超える文字サポートの利点があります。その場合は、なぜ我々がします今までに UTF-8を超えるASCIIエンコードを選ぶのか？ UTF-8の代わりにASCIIを選択するユースケースはありますか？

91 character-encoding  utf-8  ascii 

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

86 unicode  utf-8 

私が働いている会社でMySQLを使用しており、Ruby on Railsを使用してクライアント向けアプリケーションと内部アプリケーションの両方を構築しています。 ここで働き始めたとき、私は今まで遭遇したことのない問題に遭遇しました。実稼働サーバー上のデータベースはLatin-1に設定されます。これは、ユーザーがUTF-8文字をコピーして貼り付けるユーザー入力があるたびに、MySQL gemが例外をスローすることを意味します。 私の上司は、これらのほとんどが印刷できない文字であるため、これらの「悪い文字」と呼び、それらを取り除く必要があると言います。これを行う方法はいくつかありますが、最終的にはUTF-8文字が必要な状況に陥りました。さらに、特にこの問題について読んだ唯一の解決策はデータベースをUTF-8に設定することであるように思えるので、少し面倒です（私にとって理にかなっています）。 Latin-1に固執することについて聞いた唯一の議論は、印刷できないUTF-8文字を許可すると、MySQLでテキスト/フルテキスト検索が台無しになる可能性があるということです。これは本当ですか？ UTF-8ではなくLatin-1を使用する他の理由はありますか？それが優れており、よりユビキタスになることは私の理解です。

65 database  mysql  ruby-on-rails  utf-8  ascii 

私の大嫌いな人は、文字セットをサポートするための山のようなコードを持つ非常に多くのソフトウェアプロジェクトを見ています。誤解しないでください、私はすべて互換性があるので、テキストエディタを使用して複数の文字セットでファイルを開いたり保存したりできることを嬉しく思います。私を悩ますのは、非ユニバーサル文字エンコーディングの急増が「問題」ではなく「適切な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 

ウィキペディアの記事によると、UTF-8の形式は次のとおりです。 最初のコード最後のコードバイトバイト1バイト2バイト3バイト4 ポイントポイント使用済み U + 0000 U + 007F 1 0xxxxxxx U + 0080 U + 07FF 2 110xxxxx 10xxxxxx U + 0800 U + FFFF 3 1110xxxx 10xxxxxx 10xxxxxx U + 10000 U + 1FFFFF 4 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx xは、このビットを使用してコードポイントを選択することを意味します。 これにより、各継続バイトで2ビット、最初のバイトで1ビットが無駄になります。UTF-8が次のようにエンコードされないのはなぜですか？ 最初のコード最後のコードバイトバイト1バイト2バイト3 ポイントポイント使用済み U + 0000 U + …

16 character-encoding  utf-8  text-encoding 

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 

多くの場合、コードの形式を実際に選択しないと思います。つまり、過去の私のツールのほとんどが私のために決定したということです。または私は本当にそれについてさえ考えていません。先日WindowsでTextPadを使用していて、ファイルを保存していると、ASCII、UTF-8 / 16、Unicodeなどについてプロンプトが表示されました... 書かれたコードのほとんどすべてがASCIIであると想定していますが、なぜそれがASCIIである必要があるのですか？ソースコードに実際にUTF-8ファイルを使用する必要がありますか。その理由は何ですか。これは多言語チームに役立つかもしれないと思います。多言語チームが変数/関数などに名前を付ける方法に関連する標準はありますか？

10 coding-standards  source-code  character-encoding  utf-8 

私はUTF-8イテレーターアダプターに取り組んでいます。つまり、イテレータをaに、charまたはunsigned charシーケンスをイテレータからシーケンスに変換するアダプタを意味しchar32_tます。ここでの私の仕事は、オンラインで見つけたこのイテレータに触発されました。 ただし、独自の実装を開始するときに標準を調べたところ、C ++がイテレータに課す要件に準拠しながら、このようなアダプタを実装することはできないようです。 たとえば、InputIterator要件を満たすUTF-8イテレータを作成できますか？はい。ただし、指定されたイテレータ自体がInputIteratorではない場合に限ります。どうして？ InputIteratorは、同じイテレータを複数回逆参照する機能を必要とするためです。それらがすべて等しい場合、そのイテレータの複数のコピーを逆参照することもできます。 もちろん、UTF-8イテレーターアダプターを逆参照するには、基本イテレーターの逆参照と、場合によっては増分を行う必要があります。そして、そのイテレーターがInputIteratorである場合、元の値をインクリメントした後に戻すことはできません。また、コピーが機能する必要があるという事実char32_tは、以前にデコードされた値を表すをローカルに保存できないことを意味します。あなたはこれを行うことができたでしょう： auto it = ... auto it2 = it; //Copies an empty `char32_t`. *it; //Accesses base iterator, storing `it.ch`. *it; //Doesn't access the base iterator; simply returns `it.ch`. *it2; //Cannot access `it.ch`, so must access base iterator. わかりました。InputIteratorsは使用できません。しかし、ForwardIteratorはどうでしょうか？UTF-8文字シーケンスでForwardIteratorを適応できるForwardIteratorアダプターを作成することは可能ですか？ またはを生成するに*itは操作が必要なため、これも問題です。InputIteratorsはに変換可能である何かを吐き出すことができますが、[forward.iterators] /1.3実際の参照を提供するために必要とされます。value_type&const value_type&value_typeForwardIterator Xが可変イテレータである場合、referenceはへの参照Tです。Xが定数イテレータの場合、referenceはへの参照ですconst T ここでの唯一の手段は、そのようなすべてのイテレータがを持ち運ぶchar32_tことです。これは、その参照用のストレージを提供するためだけに存在します。その場合でも、イテレータインスタンスがインクリメントされ、逆参照されるたびに、その値を更新する必要があります。これは古い参照を事実上無効にし、標準はそれを明示的に許可していません（無効化はイテレータが破棄された場合、またはコンテナがそうした場合にのみ発生します）。 …

8 c++  c++11  unicode  utf-8