MySQLの文字セットと照合の問題は、主にデータストレージ、比較、移行に影響します。 1.文字設(shè)定レベルには、サーバー、データベース、テーブル、フィールドが含まれ、優(yōu)先度には段階的に上書きされます。デフォルト値の依存関係を回避するために、作成時(shí)に文字セットを明示的に指定することをお?jiǎng)幛幛筏蓼埂?2. UTF8MB4_UNICODE_CI（ケース非感受性）やUTF8MB4_BIN（ケース非感受性）などのソートルールは、クエリの結(jié)果に影響します。変更時(shí)には、インデックスと制約の動(dòng)作に注意してください。 3。データ送信は、接続段階で文字セットが一貫していることを確認(rèn)する必要があり、プログラム構(gòu)成には、セット名やJDBC構(gòu)成などの文字セットパラメーターを含める必要があります。 4.既存のデータを移行する場合、文字セットを直接変更することはできません。コードのリスクを回避するために、インポートする前にエクスポートしてからトランスコードする必要があります。計(jì)畫の初期段階にある統(tǒng)一された基準(zhǔn)は、フォローアップの問題を減らすことができます。

MySQLのキャラクターセットと照合問題は、それを率直に言うと、データを保存して比較するときに「単語を認(rèn)識(shí)する方法」と「ソートする方法」です。設(shè)定に注意を払わないと、中國語のコードを簡単に入手できます。また、誤った問い合わせの結(jié)果である場合、インデックスが失敗するか、データが覆されます。

次の重要なポイントは、MySQLを使用する際にトラップを打つ可能性が最も高い場所であり、関連する問題のトラブルシューティングをしているときに注意を払う必要があるものでもあります。

1.文字セットレベルは明確ではありません

MySQLの文字セットは、サーバー、データベース、テーブル、フィールド、さらには接続段階の複數(shù)のレベルで設(shè)定できます。それらの間に優(yōu)先関係があります：

• サーバーレベルのデフォルト文字セット（ character_set_server ）
• データベースの作成時(shí)に指定されたデフォルトの文字セット
• テーブル作成時(shí)に指定された文字セット
• 列（フィールド）定義で個(gè)別に指定された文字セット

各レイヤーが指定されていない場合、デフォルト値は1つずつ検索されます。最も一般的な問題は、データベースが構(gòu)築された後にのみ、文字セットが正しくないことがわかりますが、変更後、全身に影響します。

提案：

• データベースを作成するときは、 CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
• テーブルを作成するときに文字セットとソートルールも明示的に指定されており、デフォルト値に依存しません。
• 現(xiàn)在の設(shè)定を表示するには、 SHOW VARIABLES LIKE 'character_set%';

2。照合ルールの誤った選択は、クエリの動(dòng)作に影響します

ソートルールは、文字列の比較方法と並べ替えの方法を決定します。たとえば、 utf8mb4_unicode_ciとutf8mb4_binは完全に異なります。

• _ciはケース非感受性、 a = A returems trueです
• _binは、バイナリ比較、ケースに敏感、言語の詳細(xì)です

同じクエリが異なる環(huán)境で異なる方法で戻ることがわかります。これは、異なるソートルールが原因である可能性があります。

例えば：

 select * fromユーザーname = 'tom';

フィールドがutf8mb4_binを使用している場合、 tomやTOMのようなレコードとは一致しません。ただし、フィールドが_ciルールを使用している場合、すべて一致します。

提案：

• ケース感度が必要な場合は、フィールドを_binに設(shè)定します
• 通常のテキスト検索の場合は、通常、 utf8mb4_unicode_ci使用することをお?jiǎng)幛幛筏蓼?/li>
• インデックスの動(dòng)作と一意の制約に影響を與える可能性のある照合を変更するときは注意してください

3.データ送信中の一貫性のないエンコード

データベース、テーブル、およびフィールドが正しい文字セットで設(shè)定されている場合でも、クライアントが接続時(shí)にエンコードを設(shè)定しない場合でも問題が発生します。

一般的な現(xiàn)象は次のとおりです。

• 中國語を疑問符または文字化けコードに挿入します
• それは明らかに存在していましたが、チェックできませんでした
• ログは正常に表示されますが、ページには文字化けコードが表示されます

これは、使用される文字セットが接続時(shí)に正しく宣言されていないため、多くの場合です。たとえば、プログラムでSQLを?qū)g行する前に、次のようなものを?qū)g行しません。

名前 'utf8mb4'を設(shè)定します。

または、次のようなJDBC、PHP、その他のドライバー構(gòu)成にパラメーターは追加されていません。

• jdbc： ?characterEncoding=UTF-8&useUnicode=true
• PHP PDO：DSNにcharset=utf8mb4を追加します

提案：

• 各接続の直後に文字セットを設(shè)定して、フロントとバックの終わりの一貫性を確保する
• プログラム接続文字列は、文字セットの構(gòu)成を持つのに最適です
• さまざまなクライアント（NAVICAT、コマンドライン、コードなど）が一貫しているかどうかをテストします

4.既存のデータを新しい文字セットに移行するときの変換に注意してください

すでに多くのデータを持っていて、 latin1からutf8mb4変更したい場合は、フィールド屬性を直接変更することはできません。 MySQLは自動(dòng)的にエンコード変換を?qū)g行しないため、元々 latin1にutf8mb4として保存されているバイトを解析する可能性があり、結(jié)果は文字化けされます。

それを行う正しい方法は次のとおりです。

1. 元のデータをエクスポートします（元のエンコーディングを維持）
2. テキストツールまたはスクリプトを?qū)g際のUTF-8形式に変換します
3. 元のテーブルを削除するか、データをクリアします
4. 文字セットを変更してから、リムポートします

または、コンバート関數(shù)を使用してフィールドコンテンツを処理しますが、リスクは高いため、操作前に必ずバックアップしてください。

基本的にそれだけです。 MySQLの文字セットと照合の問題は複雑ではありませんが、特に複數(shù)の環(huán)境を展開したり、複數(shù)の人々と協(xié)力したりする場合は、詳細(xì)を無視するのは簡単です。開発、展開、メンテナンスの段階で、最初に明確に計(jì)畫し、統(tǒng)一された基準(zhǔn)を統(tǒng)合する限り、多くのトラブルを回避できます。

以上がMySQL文字セットと照合の問題を理解するの詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。