問題タブ [latin1]

MySQLにはデフォルトでlatin1エンコーディングがあり、文字をlatin1に格納するには 1 バイト、文字をutf-8に格納するには 3 バイトかかるようです。これは正しいですか?

私は、世界中で使用されることを願っているサイトに取り組んでいます。utf-8が絶対に必要ですか? または、latin1 を使用して逃げることができますか?

また、いくつかのテーブルをlatin1からutf8に変更しようとしましたが、次のエラーが発生しました: Speficief key was too long; max key length is 1000 bytes 誰かがこれに対する解決策を知っていますか? そして、私は本当にそれを解決する必要がありますか、それともlatin1で十分でしょうか?

ありがとう、アレックス

WebRequestC#の a に問題があります。グーグルのページです。

ヘッダーの状態

ウェブサイトの状態

そして最後に、デバッガーと正規表現で期待される結果のみを取得しますEncoding.Default。System.Text.SBCSCodePageEncoding

今、私は何をしますか？これがどのように発生するのか、またはこの問題をどのように解決できるのか、ヒントはありますか?

ページの実際のエンコーディングは UTF-8 のようです。少なくとも FF は、Windows-Whatever やLatin1ではなく、UTF-8 で正しく表示します。

URLはこちら

問題は、すべてのドイツ語のウムラウトと同様に € 記号です。

私を真剣に夢中にさせているこの問題について、あなたの助けを前もってありがとう!

更新:文字列を出力するとき

それはすべて正常に動作します。

したがって、問題は、デバッガーが正しいエンコーディングを表示せず、正規表現も表示しないことです。

C# に RegEx を UTF-8 として処理するように指示するにはどうすればよいですか?

特定のデータベースをセットアップして実行するのに問題があります。他の人から入手した postgreSQL ダンプを復元しようとしています。私は無駄にいくつかの方法を試しました。

1. pg_restore から直接

   pg_restore -C -d postgres --exit-on-error maggie_prod_20111221.dump.sql

2. 最初にデータベースとテーブルスペースを作成する

   createdb -T template0 maggieprod -E LATIN1

   SQL:CREATE TABLESPACE magdat OWNER maggie LOCATION '/somewhere/magdat';

   pg_restore -v -d template1 maggie_prod_20110121.dump.sql

最初の方法を使用すると、次のようになります。

pg_restore: [archiver (db)] Error while PROCESSING TOC:

pg_restore: [archiver (db)] Error from TOC entry 2308; 1262 16386 DATABASE maggieprod postgres

pg_restore: [archiver (db)] could not execute query: ERROR: encoding LATIN1 does not match locale en_CA.utf8

DETAIL: The chosen LC_CTYPE setting requires encoding UTF8. Command was: CREATE DATABASE maggieprod WITH TEMPLATE = template0 ENCODING = 'LATIN1' TABLESPACE = magdat;

2番目を使用して、データベースを作成しようとすると、次のようになります。

createdb: database creation failed: ERROR: encoding LATIN1 does not match locale en_CA.utf8

DETAIL: The chosen LC_CTYPE setting requires encoding UTF8.

LATIN1 エンコーディング データベースを作成できないようです。何故ですか？私はロケールとエンコーディングに不慣れで、それらについてあまり知りません。ダンプが LATIN1 データベースから作成されたことはわかっています。

の出力localeは次のとおりです。

LANG=en_CA.utf8 LC_CTYPE="en_CA.utf8" LC_NUMERIC="en_CA.utf8" LC_TIME="en_CA.utf8" LC_COLLATE="en_CA.utf8" LC_MONETARY="en_CA.utf8" LC_MESSAGES="en_CA.utf8" LC_PAPER="en_CA.utf8" LC_NAME="en_CA.utf8" LC_ADDRESS="en_CA.utf8" LC_TELEPHONE="en_CA.utf8" LC_MEASUREMENT="en_CA.utf8" LC_IDENTIFICATION="en_CA.utf8" LC_ALL=

そしての出力locale -aは次のとおりです。

C en_AG en_AG.utf8 en_AU.utf8 en_BW.utf8 en_CA.utf8 en_DK.utf8 en_GB.utf8 en_HK.utf8 en_IE.utf8 en_IN en_IN.utf8 en_NG en_NG.utf8 en_NZ.utf8 en_PH.utf8 en_SG.utf8 en_US.utf8 en_ZA.utf8 en_ZW.utf8 POSIX

2 番目のコマンドに LATIN1 が表示されません。もしそうなら、どうやって追加しますか？コンピュータのロケールを変更する必要があると考えるのは正しいですか? もしそうなら、postgreSQL に対してのみそれを行う方法はありますか? また、ダンプを開こうとすると、大量の文字化けが表示されます。これはエンコーディングが原因であると想定していますが、どうすれば適切に表示できますか?

助けてくれてありがとう。

da_DK.utf8 ロケールで作成された PostgreSQL 8.4 データベースがあります。

文字が異なる列で注文するテーブルから何かを選択すると、IMO で奇妙な動作が発生します。結果を並べ替えるとき、PostgreSQL は値の前にあるダッシュを無視します。たとえば、次のようになります。

次のようなものを返す場合があります

ダッシュ接頭辞は無視されているようです。

注文時に列を latin1 に変換することで、この問題を解決できます。

次のように期待される結果が得られます。

ダッシュ接頭辞がデフォルトで無視されるのはなぜですか? その行動を変えることはできますか？

レポート用に2つの異なるサブシステムからのデータを統合するクロスデータベースビューを構築しています。

どちらのテーブルも、utf8_general_cl照合を使用したUTF8エンコーディングを使用しています。

問題は、一方のデータベースがutf8であるのに対し、もう一方のデータベースはlatin1_swedish_clが設定されたlatin1であるということです。

その結果、両方のテーブルがutf8であるにもかかわらず、アクセント付き文字などがlatin1データベースのテーブルから破損して取得されます。

データベース全体の文字セットを変更することはオプションではないと思います。

文字列をその場で変換できますか？convert（）を試しましたが、効果がないようです。

デフォルトで LATIN1 エンコーディングに設定されているか、少なくともそれをサポートする新しいデータベース クラスタを postgresql で作成しようとしています。使用できるロケールを誰か知っていますか? 私はWindows 7 64ビットを使用しています

ありがとう

QString を utf8 または latin1 QByteArray に変換したいのですが、今日はすべてを utf8 として取得しています。

そして、0x7f よりも高い latin1 の上位セグメントにある char を使用してこれをテストしています。ドイツ語の ü が良い例です。

私がこれを好きなら：

次の出力が得られます。

ご覧のとおり、どこでも unicode 0xc3bc を取得していますが、ステップ 2 と 3 で Latin1 0xfc を取得すると予想されます。

私の推測では、次のようなものを取得する必要があります。

ここで何が起こっているのですか？

/ありがとう

いくつかの文字テーブルへのリンク:

• http://www.utoronto.ca/web/HTMLdocs/NewHTML/iso_table.html
• http://www.utf8-zeicentabelle.de/

このコードは、Ubuntu 10.04 ベースのシステムでビルドおよび実行されました。

そして、私が使用しようとすると

私はこの出力を得る

したがって、latin1 は Unicode であり、utf8 は二重にエンコードされています...

これは、いくつかのシステム設定に依存する必要がありますか?

これを実行すると (ビルドする .name() を取得できませんでした)

次に、これを取得します。

解決

私が使用しているUTF-8であることを指定すると、さまざまなクラスがこれを認識し、機能します。

次に、次の出力を取得します。

そして、それはそうあるべきであるように見えます。

mb_detect_encoding() 関数を使用して、文字列に latin1 (ISO-8859-1) 以外の文字が含まれているかどうかを確認しています。

日本語は latin1 の一部ではないため、テスト文字列内のテキストとして使用していますが、文字列が関数に渡されると、ISO-8859-1 に対して OK を返すようです。コード例:

「ISO-8859-1」の代わりに「ASCII」を使用してみましたが、これは正しく false を返します。矛盾を説明できる人はいますか？

BiRT でレポートを生成するために使用される JDBC を使用して、MySQL データベースから結果セットを取得しようとしています。接続文字列は BiRT で設定されます。

データベースは latin1 です。

そのため、返される奇妙に見えるエンコード結果 (ドイツ語の文字) を修正しようとしています。次のように、結果セットを「latin1」として取得する「characterSetResults」プロパティが理にかなっていると思いました。

この接続文字列は失敗し、推論により、それが次のプロパティであることがわかりました。

接続が失敗する原因となっています。エラーは長い Java エラーで、私にはほとんど意味がありません。それでは始まります：

これを次のように変更すると:

接続文字列はエラーなしで接続されますが、エンコードの問題は残ります。

latin1 を取得する正しい方法を知っている人はいますか? はい、UTF8 を使用することは知っていますが、これは私のデータベースではありません....

これを読んでくれてありがとう、スティーブン

共有サーバーで OAuth サポートをセットアップしている最中です。インストールしようとしているサーバー側の PHP OAuth ライブラリは次のとおりです。

http://code.google.com/p/oauth-php/downloads/list

そして、私はここにあるインストールノートに従っています:

http://code.google.com/p/oauth-php/wiki/ConsumerHowTo

メモには、インストール パッケージにある SQL スクリプトを使用して、テーブルとデータベースをセットアップするためのヒントがありました。phpMyAdmin にあるインポート (SQL) 機能を使用してスクリプトを実行しようとすると、テーブルの 1 つで「キーが長すぎます」というエラーが発生しました。つまり、MySQL/InnoDB テーブルを使用しているときに見られる最大キー長の制限にぶつかりました。

この問題を回避するために、「charset=latin1」の「charset=utf8」のすべてのインスタンスを置き換えました。これは、utf8 は 1 文字あたり 3 バイトを必要とし、latin1 は 1 文字あたり 1 バイトであるためです。スクリプトは正常に実行され、すべてのテーブルが正しく作成されました。

私が見る限り、テーブルで使用されているすべてのフィールドは、マルチバイト国際文字のサポートを必要としません。問題が発生する唯一の方法は、アクセスする OAuth 接続サービスの 1 つがコンシューマ キーまたはシークレットで国際文字を使用している場合であり、これまでのところ、そのような状況に遭遇したことはまったくありません。

この回避策がいつでも私の裏側を噛むかどうか、またそれがどこにあるのか誰か教えてもらえますか? また、utf8 文字セットの使用を犠牲にすることなく「キーが長すぎる」問題を解決するためのより良い解決策がある場合は、それについて知りたいです。