পিএইচপি দিয়ে মাইএসকিউএল ব্যবহার করার জন্য সবচেয়ে ভাল কোলেশন কী? [বন্ধ]

Question

আমি ভাবছি যে কোনও সাধারণ ওয়েবসাইটের জন্য মাইএসকিউএলে কোলেশনের জন্য কোনও "সেরা" পছন্দ আছে যেখানে আপনি কী প্রবেশ করবেন তা সম্পর্কে 100% নিশ্চিত নন? আমি বুঝেছি যে সমস্ত এনকোডিংগুলি একই হওয়া উচিত, যেমন মাইএসকিউএল, অ্যাপাচি, এইচটিএমএল এবং পিএইচপি-র ভিতরে যে কোনও কিছু।

অতীতে আমি পিএইচপি "ইউটিএফ -8" এ আউটপুট সেট করেছিলাম তবে মাইএসকিউএলে কোন মিলটি এই মিলছে? আমি ভাবছি UTF-8 বেশী এক, কিন্তু আমি ব্যবহার করেছি utf8_unicode_ci, utf8_general_ciএবং utf8_binআগে।

Comments

পার্শ্ব দ্রষ্টব্য: মাইএসকিউএল এর "utf8" যথাযথ UTF-8 নয় (4+ বাইট ইউনিকোড অক্ষরের জন্য কোনও সমর্থন নয়) তবে "utf8mb4" হয়। Utf8 এর সাথে, প্রথম অসমর্থিত ইউনিকোড অক্ষর দিয়ে সন্নিবেশ করার সময় একটি ক্ষেত্রটি কেটে যাবে। mathiasbynens.be/notes/mysql-utf8mb4

— বেসিক 6

আমি ভাবছি যদি আমাদের সেই সমস্ত ইমোজিদের জন্য 5 বাইটের দরকার হয় ... দীর্ঘশ্বাস ফেলুন

— এলভারো গঞ্জালেজ

সম্পর্কিত প্রশ্ন: স্ট্যাকওভারফ্লো / প্রশ্ন / 38228335/… "কোন মাইএসকিউএল কোলেশন পিএইচপি-র স্ট্রিং তুলনার সাথে মেলে?"

— উইলিয়াম এন্টারিকেন

বুদ্ধিমান বিকল্পগুলির একটি সংক্ষিপ্তসার জন্য: monolune.com/mysql-utf8-charsets-and-colifications- বর্ণিত

— ফ্লাক্স

Answer 1

প্রধান পার্থক্য হ'ল যথার্থতা বাছাই করা (যখন ভাষার অক্ষরের সাথে তুলনা করা হয়) এবং কর্মক্ষমতা। কেবলমাত্র একমাত্র utf8_bin যা বাইনারি ফর্ম্যাটে অক্ষরের তুলনা করার জন্য।

utf8_general_ciএর চেয়ে কিছুটা দ্রুত utf8_unicode_ci, তবে কম নির্ভুল (বাছাইয়ের জন্য)। নির্দিষ্ট ভাষা UTF8 এনকোডিং (যেমন utf8_swedish_ci) যে তাদেরকে ঐ ভাষার জন্য বাছাই করতে সবচেয়ে সঠিক করতে অতিরিক্ত ভাষা নিয়ম ধারণ করে। আমি বেশিরভাগ সময় ব্যবহার করি utf8_unicode_ci(আমি ছোট পারফরম্যান্সের উন্নতির তুলনায় নির্ভুলতা পছন্দ করি), যদি না আমার কাছে নির্দিষ্ট ভাষা পছন্দ করার উপযুক্ত কারণ থাকে।

আপনি মাইএসকিউএল ম্যানুয়ালিতে নির্দিষ্ট ইউনিকোড অক্ষর সেটগুলি সম্পর্কে আরও পড়তে পারেন - http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

Comments

ছোট পারফরম্যান্স উন্নতি? আপনি যদি এই বিষয়ে নিশ্চিত ? publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/… আপনি যে কোলেশনটি নির্বাচন করেছেন তা ডেটাবেসে প্রশ্নের কার্যকারিতা উল্লেখযোগ্যভাবে প্রভাবিত করতে পারে।

— আদম রামধন

এটি মাইএসকিউএল নয় ডিবি 2 এর জন্য। এছাড়াও, কোনও কংক্রিট নম্বর বা মানদণ্ড নেই তাই আপনি এটি কেবল লেখকের মতের উপর ভিত্তি করে চলেছেন।

— ইরান গাল্পেরিন

মনে রাখবেন যে আপনি যদি ফাংশনগুলি ব্যবহার করতে চান তবে মাইএসকিউএল-এ (একটি বেশিরভাগ বর্তমানে বিতরণিত সংস্করণ) একটি বাগ রয়েছে যেখানে ফাংশন সর্বদা utf8_general_ci ব্যবহার করে স্ট্রিংটি ফেরত দেয়, যদি আপনি আপনার স্ট্রিংয়ের জন্য অন্য কোলেশন ব্যবহার করেন তবে সমস্যা সৃষ্টি করে - দেখুন bugs.mysql.com/ bug.php? id = 24690

— এল ইয়াবো

বিভিন্ন লোকেলের সাথে আমার অভিজ্ঞতা থেকে আমি সর্বদা ব্যবহার করবutf8_unicode_*

— শিপলু মোকাদ্দিম

আপডেট: নতুন সংস্করণগুলির জন্য, সুপারিশ করুন utf8mb4এবং utf8mb4_unicode_520_ci। এগুলি আপনাকে বাকী চাইনিজ, আরও উন্নত কোলেশন দেয়।

— রিক জেমস

Answer 2

আসলে, আপনি সম্ভবত ব্যবহার করতে চান utf8_unicode_ciবা utf8_general_ci।

• utf8_general_ci সমস্ত অ্যাকসেন্টগুলি সরিয়ে এবং বাছাই করে বাছাই করে যেমন এটি ASCII
• utf8_unicode_ci ইউনিকোড সাজানোর ক্রম ব্যবহার করে, তাই এটি আরও ভাষায় সঠিকভাবে সাজায়

তবে আপনি যদি কেবল ইংরেজী পাঠ্য সংরক্ষণ করার জন্য এটি ব্যবহার করছেন তবে এগুলি পৃথক হওয়া উচিত নয়।

Comments

আমি আপনার ব্যাখ্যা পছন্দ! ভাল একটা. তবে অ্যাকসেন্টগুলি সরে যাওয়ার চেয়ে কেন ইউনিকোড সাজানোর ক্রমটি সঠিকভাবে বাছাই করার ভাল উপায় তা সম্পর্কে আমার আরও ভাল বোঝার দরকার।

— ওয়েইয়া ডিজাইন করুন

@ অ্যাডাম এটি আপনার লক্ষ্য দর্শকদের উপর নির্ভর করে। সঠিকভাবে স্থানীয়করণের জন্য বাছাই করা একটি জটিল সমস্যা। উদাহরণস্বরূপ নরওয়েজিয়ান ভাষায় বর্ণমালার শেষ 3 টি Æ Ø Å হয় Utf8_general_ci এর সাথে, Ø এবং O O এবং A তে রূপান্তরিত হয়, যা সাজানোর সময় এগুলি পুরোপুরি ভুল অবস্থানে ফেলে দেয় (আমি নিশ্চিত না যে কীভাবে hand পরিচালনা করা হয়, কারণ এটি একটি লিগ্রেচার, একটি উচ্চারণযুক্ত চরিত্র নয়)। এই সাজানোর ক্রমটি প্রায় কোনও ভাষায় আলাদা, যেমন নরওয়েজিয়ান এবং সুইডিশের বিভিন্ন অর্ডার থাকে (এবং সামান্য আলাদা অক্ষর যা সমান বলে বিবেচিত হয়): Æ Ø Å সাজানো হয় Å Æ Ø (প্রকৃত অক্ষরগুলি Å Ä Ö)। ইউনিকোড এটি ঠিক করে।

— Vegard Larsen

সুতরাং আমি মূলত যা বলছি তা হ'ল আপনি যদি পারেন তবে সম্ভবত একটি ভাষা-নির্দিষ্ট সাজান ব্যবহার করা উচিত, তবে বেশিরভাগ ক্ষেত্রে অপ্রয়োজনীয় তাই ইউনিকোডের সাধারণ বাছাইয়ের জন্য যান। এটি কিছু ভাষায় এখনও অদ্ভুত হবে তবে এএসসিআইআইয়ের চেয়ে আরও সঠিক।

— Vegard Larsen

@ মানাট্যাক্স - যে কোনও ইউটিএফ 8_ কোলেশন সহ ডেটা ইউটিএফ 8 হিসাবে সংরক্ষণ করা হয়। কোলেশনটি ঠিক কী কী অক্ষরগুলির সমান বলে বিবেচিত হয় এবং কীভাবে তাদের আদেশ করা হয়।

— frymaster

@ ফ্রাইমাস্টার - সত্য অনুসারে: mathiasbynens.be/notes/mysql-utf8mb4 "মাইএসকিউএল এর ইউটিফ 8 আপনাকে কেবলমাত্র সম্ভাব্য ইউনিকোড কোড পয়েন্টের 5.88% সংরক্ষণ করতে দেয়"

— ডেটা

Answer 3

ব্যবহার করার সময় যে সমস্যাটি দেখা দিতে পারে সে সম্পর্কে খুব সচেতন থাকুন utf8_general_ci।

মাইএসকিউএল নির্বাচিত বিবৃতিগুলিতে কিছু অক্ষরের মধ্যে পার্থক্য করবে না, যদি utf8_general_ciকোলেশন ব্যবহৃত হয়। এটি খুব বাজে বাগের দিকে নিয়ে যেতে পারে - বিশেষত উদাহরণস্বরূপ, যেখানে ব্যবহারকারীর নাম জড়িত। ডেটাবেস টেবিল ব্যবহার করে এমন প্রয়োগের উপর নির্ভর করে, এই সমস্যাটি দূষিত ব্যবহারকারীদের প্রশাসকের অ্যাকাউন্টের সাথে মিলে একটি ব্যবহারকারী নাম তৈরি করতে দেয়।

এই সমস্যাটি খুব অল্প সময়ে 5.x সংস্করণগুলির মধ্যে নিজেকে প্রকাশ করে - আমি নিশ্চিত নই যে এই আচরণটি পরে পরিবর্তিত হয়েছে কিনা I'm

আমি কোনও ডিবিএ নই, তবে এই সমস্যাটি এড়াতে আমি সবসময় utf8-binকেস-সংবেদনশীল না হয়ে with

নীচের স্ক্রিপ্ট উদাহরণ দিয়ে সমস্যা বর্ণনা করে।

-- first, create a sandbox to play in
CREATE DATABASE `sandbox`;
use `sandbox`;

-- next, make sure that your client connection is of the same 
-- character/collate type as the one we're going to test next:
charset utf8 collate utf8_general_ci

-- now, create the table and fill it with values
CREATE TABLE `test` (`key` VARCHAR(16), `value` VARCHAR(16) )
    CHARACTER SET utf8 COLLATE utf8_general_ci;

INSERT INTO `test` VALUES ('Key ONE', 'value'), ('Key TWO', 'valúe');

-- (verify)
SELECT * FROM `test`;

-- now, expose the problem/bug:
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get BOTH keys here! MySQLs UTF8 collates that are 
-- case insensitive (ending with _ci) do not distinguish between 
-- both values!
--
-- collate 'utf8_bin' doesn't have this problem, as I'll show next:
--

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get just one key now, as you'd expect.
--
-- This problem appears to be specific to utf8. Next, I'll try to 
-- do the same with the 'latin1' charset:
--

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_general_ci

-- next, convert the values that we've previously inserted
-- in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_general_ci;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected). This shows 
-- that the problem with utf8/utf8_generic_ci isn't present 
-- in latin1/latin1_general_ci
--
-- To complete the example, I'll check with the binary collate
-- of latin1 as well:

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected).
--
-- Finally, I'll re-introduce the problem in the exact same 
-- way (for any sceptics out there):

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_generic_ci

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

-- now, re-check for the problem/bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Two keys.
--

DROP DATABASE sandbox;

Comments

-1: প্রাসঙ্গিক কলামে একটি অনন্য কী প্রয়োগ করে অবশ্যই এর প্রতিকার করা হবে। যদি দুটি মান হয় 'value'এবং আপনি একই আচরণ দেখতে পাবেন 'valUe'। একটি কোলেশনের পুরো বিষয়টি হ'ল দুটি স্ট্রিং একে অপরের সমান বিবেচিত হলে এটি (অন্যান্য জিনিসগুলির মধ্যে) জন্য বিধি সরবরাহ করে।

— হামারাইট

এটি ঠিক সেই সমস্যাটিই আমি উদাহরণস্বরূপ বোঝানোর চেষ্টা করছি - কোলেশন দুটি জিনিসকে সমান করে তোলে যখন তারা বাস্তবে মোটেও সমান হওয়ার উদ্দেশ্যে নয় (এবং এইভাবে, একটি অনন্য বাধা আপনি যেটি অর্জন করতে চান তার ঠিক বিপরীত)

— গিউস

তবে আপনি এটিকে একটি "সমস্যা" হিসাবে বর্ণনা করেন এবং "বাগগুলি" বাড়ে যখন আচরণটি হুবহু অর্জনের উদ্দেশ্যে যা করা হয় ঠিক তেমনই হয়। আপনার বিবরণটি সঠিক, তবে কেবলমাত্র ডিবিএর পক্ষ থেকে একটি অনুপযুক্ত কোলেশন নির্বাচন করা ত্রুটি।

— হ্যামারাইট

জিনিসটি হ'ল, যখন আপনি দুটি ব্যবহারকারী নাম প্রবেশ করান যা কোলেশন দ্বারা সমান বিবেচিত হয়, আপনি যদি কলউমন ব্যবহারকারী নামটি অনন্য হিসাবে সেট করেন তবে এটি অনুমোদিত হবে না যা অবশ্যই আপনার করা উচিত!

— শিক্ষার্থী

আমি এই উত্তর এবং @ হ্যামারাইটের মন্তব্য উভয়কেই উত্সাহিত করেছি, কারণ উভয়ই সম্মিলিতভাবে আমাকে জোটের বোঝাপড়াতে সহায়তা করেছে।

— নচট - মনিকা

Answer 4

utf8mb4কোলেশনের সাথে অক্ষর সেট ব্যবহার করা ভাল utf8mb4_unicode_ci।

অক্ষর সেট, utf8কেবলমাত্র ইউটিএফ -8 কোড পয়েন্টের সম্ভাব্য অক্ষরের প্রায় 6% সমর্থন করে। utf8কেবলমাত্র বেসিক বহুভাষিক প্লেন (বিএমপি) সমর্থন করে। সেখানে আরও 16 টি প্লেন রয়েছে। প্রতিটি বিমানের মধ্যে 65,536 টি অক্ষর রয়েছে। utf8mb4সমস্ত 17 প্লেন সমর্থন করে।

মাইএসকিউএল 4 বাইট ইউটিএফ -8 অক্ষরগুলি কেটে ফেলবে যার ফলে ক্ষতিগ্রস্ত ডেটা হবে।

utf8mb4অক্ষর সেট 2010-03-24 উপর মাইএসকিউএল 5.5.3 চালু করা হয়।

নতুন অক্ষর সেটটি ব্যবহার করতে প্রয়োজনীয় কিছু পরিবর্তন তুচ্ছ নয়:

• আপনার অ্যাপ্লিকেশন ডাটাবেস অ্যাডাপ্টারে পরিবর্তনগুলি করা দরকার হতে পারে।
• অক্ষর সেট সেট করা, কোলেশন এবং বারোডুডায় ইনোডাব_ফাইলে_ফর্ম্যাট পরিবর্তন সহ মাই সিএনএফ-তে পরিবর্তনগুলি করা দরকার
• এসকিউএল তৈরি বিবৃতি অন্তর্ভুক্ত করতে পারে: ROW_FORMAT=DYNAMIC
  • ডিআরএনমিক (VYCHAR) (192) এবং আরও বড় এর সূচকের জন্য প্রয়োজনীয়।

দ্রষ্টব্য: Barracudaথেকে স্যুইচ Antelopeকরার জন্য মাইএসকিউএল পরিষেবাটি একাধিকবার পুনরায় আরম্ভ করার প্রয়োজন হতে পারে। innodb_file_format_max: হওয়া পর্যন্ত মাইএসকিউএল সেবার পুনরায় আরম্ভ করা হয়েছে পরিবর্তন করে না innodb_file_format = barracuda।

মাইএসকিউএল পুরানো AntelopeInnoDB ফাইল ফর্ম্যাট ব্যবহার করে । Barracudaডায়নামিক সারি বিন্যাসকে সমর্থন করে, যা আপনি অক্ষরটিতে স্যুইচ করার পরে সূচি এবং কী তৈরির জন্য এসকিউএল ত্রুটিগুলি আঘাত করতে না চাইলে আপনার প্রয়োজন হবে:utf8mb4

• # 1709 - সূচী কলামের আকার খুব বড়। সর্বাধিক কলামের আকার 767 বাইট।
• # 1071 - নির্দিষ্ট কীটি দীর্ঘ ছিল; সর্বাধিক কী দৈর্ঘ্য 767 বাইট

নিম্নলিখিত পরিস্থিতিটি মাইএসকিউএল 5.6.17 এ পরীক্ষা করা হয়েছে: ডিফল্টরূপে, মাইএসকিউএল এভাবে কনফিগার করা হয়েছে:

SHOW VARIABLES;

innodb_large_prefix = OFF
innodb_file_format = Antelope

আপনার মাইএসকিউএল পরিষেবা বন্ধ করুন এবং আপনার বিদ্যমান মাই সিএনএফ এ বিকল্পগুলি যুক্ত করুন:

[client]
default-character-set= utf8mb4

[mysqld]
explicit_defaults_for_timestamp = true
innodb_large_prefix = true
innodb_file_format = barracuda
innodb_file_format_max = barracuda
innodb_file_per_table = true

# Character collation
character_set_server=utf8mb4
collation_server=utf8mb4_unicode_ci

এসকিউএল তৈরি বিবৃতি উদাহরণ:

CREATE TABLE Contacts (
 id INT AUTO_INCREMENT NOT NULL,
 ownerId INT DEFAULT NULL,
 created timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
 modified timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 contact VARCHAR(640) NOT NULL,
 prefix VARCHAR(128) NOT NULL,
 first VARCHAR(128) NOT NULL,
 middle VARCHAR(128) NOT NULL,
 last VARCHAR(128) NOT NULL,
 suffix VARCHAR(128) NOT NULL,
 notes MEDIUMTEXT NOT NULL,
 INDEX IDX_CA367725E05EFD25 (ownerId),
 INDEX created (created),
 INDEX modified_idx (modified),
 INDEX contact_idx (contact),
 PRIMARY KEY(id)
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ENGINE = InnoDB ROW_FORMAT=DYNAMIC;

• আপনি ক্রিয়েটিয়ান স্টেটমেন্ট থেকে অপসারণ করা INDEX contact_idx (contact)হলে # 1709 ত্রুটিটি দেখতে পাচ্ছেন ROW_FORMAT=DYNAMIC।

দ্রষ্টব্য: সূচক পরিবর্তন করে প্রথম 128 টি অক্ষরের সীমাবদ্ধ করতে contactব্যারাকুডা ব্যবহারের প্রয়োজনীয়তা বাদ দেয়ROW_FORMAT=DYNAMIC

INDEX contact_idx (contact(128)),

এছাড়াও দ্রষ্টব্য: যখন এটি বলছে ক্ষেত্রের আকার, এটি VARCHAR(128)128 বাইট নয়। আপনি 128, 4 বাইট অক্ষর বা 128, 1 বাইট অক্ষর ব্যবহার করতে পারেন।

এই INSERTবিবৃতিতে 2 সারির 4 বাইট 'পু' অক্ষর থাকা উচিত:

INSERT INTO `Contacts` (`id`, `ownerId`, `created`, `modified`, `contact`, `prefix`, `first`, `middle`, `last`, `suffix`, `notes`) VALUES
(1, NULL, '0000-00-00 00:00:00', '2014-08-25 03:00:36', '1234567890', '12345678901234567890', '1234567890123456789012345678901234567890', '1234567890123456789012345678901234567890', '12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678', '', ''),
(2, NULL, '0000-00-00 00:00:00', '2014-08-25 03:05:57', 'poo', '12345678901234567890', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', ''),
(3, NULL, '0000-00-00 00:00:00', '2014-08-25 03:05:57', 'poo', '12345678901234567890', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '123💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', '');

lastকলামটি ব্যবহৃত স্থানের পরিমাণটি দেখতে পাবেন :

mysql> SELECT BIT_LENGTH(`last`), CHAR_LENGTH(`last`) FROM `Contacts`;
+--------------------+---------------------+
| BIT_LENGTH(`last`) | CHAR_LENGTH(`last`) |
+--------------------+---------------------+
|               1024 |                 128 | -- All characters are ASCII
|               4096 |                 128 | -- All characters are 4 bytes
|               4024 |                 128 | -- 3 characters are ASCII, 125 are 4 bytes
+--------------------+---------------------+

আপনার ডাটাবেস অ্যাডাপ্টারে আপনি নিজের সংযোগের জন্য চরসেট এবং কোলেশন সেট করতে চাইতে পারেন:

SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'

পিএইচপি-তে, এটির জন্য সেট করা হবে: \PDO::MYSQL_ATTR_INIT_COMMAND

তথ্যসূত্র:

• মাইএসকিএল 5.6 রেফারেন্স ম্যানুয়াল: ইনোডিবি টেবিলগুলির সীমাবদ্ধতা
• মাইএসকিউএল ডাটাবেসে কীভাবে পূর্ণ ইউনিকোড সমর্থন করবেন

Comments

মাইএসকিউএল 5.6 রেফারেন্স ম্যানুয়ালে

— জেরেমি পোস্টলেথওয়েট

উইকিপিডিয়া: ইউনিকোড প্লেন

— জেরেমি পোস্টলেথওয়েট

utf8mb4_unicode_ci 2015 সালে নতুন প্রকল্পগুলির জন্য একেবারে প্রস্তাবিত কোলেশন হওয়া উচিত

— ট্রেভর গেহম্যান

আপডেট ... utf8mb4_unicode_520_ciভাল। ভবিষ্যতে, utf8mb4_unicode_800_ciমাইএসকিউএল ইউনিকোড স্ট্যান্ডার্ডকে ধরে রাখার সাথে সাথে (বা এর মতো কিছু হবে ) থাকবে।

— রিক জেমস

Answer 5

কোলেশনগুলি কীভাবে ডেটা বাছাই করা হয় এবং স্ট্রিংগুলি একে অপরের সাথে কীভাবে তুলনা করা হয় তা প্রভাবিত করে। এর অর্থ আপনার ব্যবহারকারীর বেশিরভাগ প্রত্যাশার সাহায্যে ব্যবহার করা উচিত।

চরসেট ইউনিকোডের জন্য ডকুমেন্টেশন থেকে উদাহরণ :

utf8_general_ci'ß' 's' এর সমান এবং 'ss' নয়, তবে জার্মান এবং ফরাসী উভয়ের জন্যই সন্তোষজনক। এটি যদি আপনার আবেদনের জন্য গ্রহণযোগ্য হয় তবে আপনার ব্যবহার করা উচিত utf8_general_ciকারণ এটি দ্রুত faster অন্যথায়, ব্যবহার করুন utf8_unicode_ciকারণ এটি আরও সঠিক।

সুতরাং - এটি আপনার প্রত্যাশিত ব্যবহারকারীর বেস এবং আপনার সঠিক বাছাইয়ের প্রয়োজনের উপর নির্ভর করে । ইংলিশ ব্যবহারকারী বেসের utf8_general_ciজন্য, সুইডিশের মতো অন্যান্য ভাষার জন্যও যথেষ্ট হওয়া উচিত।

Comments

আমি utf8_general_ci ব্যবহার করছিলাম এবং এটি বাছাইয়ের সময় এবং কয়েক মিনিট সময় নিয়েছিলো যদিও অস্ত্রিয়াই_জেনারাল_সি অত্যন্ত তাড়াতাড়ি করেছিল this কেন এমনটি হয়েছিল? আরও একটি প্রশ্ন, আপনি কী ভাবেন কোন

Answer 6

মূলত, আপনি কী স্ট্রিং সম্পর্কে ভাবেন তার উপর এটি নির্ভর করে।

আমি সবসময়ই ইউটিএফ 8_বিন ব্যবহার করি কারণ গুস হাইলাইট করা সমস্যার কারণে। আমার মতে, যতদূর ডাটাবেস সম্পর্কিত হওয়া উচিত, একটি স্ট্রিং এখনও একটি স্ট্রিং। একটি স্ট্রিং হ'ল সংখ্যার ইউটিএফ -8 অক্ষর। একটি চরিত্রের বাইনারি উপস্থাপনা থাকে তাই আপনি যে ভাষাটি ব্যবহার করছেন তা কেন এটি জানা দরকার? সাধারণত, লোকেরা বহুভাষিক সাইটগুলির সুযোগ সহ সিস্টেমগুলির জন্য ডেটাবেস তৈরি করবেন। এটি ইউটিএফ -8 কে একটি অক্ষর সেট হিসাবে ব্যবহারের পুরো পয়েন্ট। আমি কিছুটা খাঁটিবাদী তবে আমি মনে করি যে ত্রুটি ঝুঁকিপূর্ণভাবে আপনি সূচীকরণের জন্য যে সামান্য সুবিধা পেতে পারেন তার চেয়ে বেশি। যে কোনও ভাষা সম্পর্কিত নিয়ম ডিবিএমএসের চেয়ে অনেক উচ্চ স্তরে করা উচিত।

আমার বইগুলিতে "মান" কখনই মিলিয়ন বছরে "মান" এর সমান হয় না।

যদি আমি একটি পাঠ্য ক্ষেত্র সংরক্ষণ করতে এবং কোনও ক্ষেত্রে সংবেদনশীল অনুসন্ধান করতে চাই, তবে আমি পিএইচপি ফাংশন যেমন লোয়ার () এবং পিএইচপি ফাংশন স্ট্র্টলওয়ার () সহ এমওয়াইএসকিউএল স্ট্রিং ফাংশন ব্যবহার করব।

Comments

স্ট্রিংগুলির বাইনারি তুলনা যদি আপনার পছন্দসই তুলনা হয় তবে অবশ্যই আপনার বাইনারি কোলেশন ব্যবহার করা উচিত; তবে বিকল্প কোলেশনগুলিকে "বাগ ঝুঁকি" হিসাবে বরখাস্ত করা বা সূচকের সুবিধার জন্য সহজভাবে বোঝা যায় যে আপনি কোনও জোটের বিন্দুটি পুরোপুরি বুঝতে পারছেন না not

— হামারাইট

Answer 7

ইউটিএফ -8 পাঠ্য তথ্যের জন্য আপনার ব্যবহার করা উচিত utf8_general_ciকারণ ...

• utf8_bin: স্ট্রিংয়ের প্রতিটি অক্ষরের বাইনারি মান দ্বারা স্ট্রিংগুলি তুলনা করুন

• utf8_general_ci: সাধারণ ভাষার বিধি ব্যবহার করে এবং কেস-সংবেদনশীল তুলনা ব্যবহার করে স্ট্রিংগুলির তুলনা করুন

ওরফে এটি ডেটা দ্রুত / আরও দক্ষ / আরও দরকারী দরকারী অনুসন্ধান এবং ইনডেক্স করা উচিত।

Answer 8

গৃহীত উত্তরটি মোটামুটি নিশ্চিতভাবে utf8_unicode_ci ব্যবহার করার পরামর্শ দেয় এবং নতুন প্রকল্পগুলির জন্য যেটি দুর্দান্ত, আমি কাউকে কিছুটা সময় সাশ্রয় করার ক্ষেত্রে আমার সাম্প্রতিক বিপরীত অভিজ্ঞতাটি বর্ণনা করতে চেয়েছিলাম।

যেহেতু utf8_general_ci মাইএসকিউএল ইউনিকোডের জন্য ডিফল্ট কোলেশন, আপনি যদি utf8_unicode_ci ব্যবহার করতে চান তবে আপনাকে এটি অনেক জায়গায় নির্দিষ্ট করতে হবে ।

উদাহরণস্বরূপ, সমস্ত ক্লায়েন্ট সংযোগগুলির কেবল একটি ডিফল্ট চরসেট থাকে না (এটি আমার কাছে বোধ হয়) তবে একটি ডিফল্ট কোলেশনও (অর্থাত্ কোলিশনটি সর্বদা ইউনিকোডের জন্য utf8_general_ci এ ডিফল্ট হবে)।

সম্ভবত, আপনি যদি আপনার ক্ষেত্রগুলির জন্য utf8_unicode_ci ব্যবহার করেন, আপনার স্ক্রিপ্টগুলি যে ডাটাবেসের সাথে সংযুক্ত থাকে তাদের পছন্দসই কোলেশনটি স্পষ্টভাবে উল্লেখ করার জন্য আপডেট করতে হবে - অন্যথায় আপনার সংযোগটি যখন ডিফল্ট কোলিশ ব্যবহার করছে তখন পাঠ্য স্ট্রিং ব্যবহার করে অনুসন্ধানগুলি ব্যর্থ হতে পারে।

ফলাফলটি হ'ল যে কোনও আকারের বিদ্যমান সিস্টেমকে ইউনিকোড / ইউটিএফ 8 তে রূপান্তর করার সময়, মাইএসকিউএল যেভাবে ডিফল্টগুলি পরিচালনা করে তার কারণে আপনি utf8_general_ci ব্যবহার করতে বাধ্য হতে পারেন।

Answer 9

গুয়াস হাইলাইট করা কেসটির জন্য, আমি দৃ strongly়ভাবে utf8_bin (কঠোর মিল, ভুল ক্রম) এর পরিবর্তে utf8_unicode_cs (কেস সংবেদনশীল, কঠোর মিল, বেশিরভাগ অংশের জন্য সঠিকভাবে অর্ডার করা) ব্যবহার করার পরামর্শ দেব।

যদি ক্ষেত্রটি অনুসন্ধানের উদ্দেশ্যে, কোনও ব্যবহারকারীর সাথে মিলে যাওয়ার বিপরীতে থাকে, তবে utf8_general_ci বা utf8_unicode_ci ব্যবহার করুন। উভয়ই কেস-সংবেদনশীল, একটি হারাতে হবে ('ß' 's' এর সমান, এবং 'ss' তে নয়)। ভাষা নির্দিষ্ট সংস্করণগুলিও রয়েছে, যেমন utf8_german_ci যেখানে হেরে ম্যাচিং নির্দিষ্ট ভাষার জন্য উপযুক্ত more

[সম্পাদনা করুন - প্রায় 6 বছর পরে]

আমি আর মাইএসকিউএলে "utf8" অক্ষর সেট করার পরামর্শ দিচ্ছি না, এবং পরিবর্তে "utf8mb4" অক্ষর সেটটি সুপারিশ করব। এগুলি প্রায় সম্পূর্ণরূপে মিলছে, তবে আরও কিছু ইউনিকোড চরিত্রের জন্য অনুমতি দেয়।

বাস্তবিকভাবে, মাইএসকিউএলের "utf8" অক্ষর সেট এবং সম্পর্কিত কোলেশনগুলি আপডেট করা উচিত "utf8" স্পেসিফিকেশনের সাথে মেলে, তবে পরিবর্তে, পৃথক অক্ষর সেট এবং স্বতন্ত্র কোলিশগুলি ইতিমধ্যে তাদের অসম্পূর্ণ "utf8" অক্ষর সেটটি ব্যবহার করছে এমনদের জন্য স্টোরেজ নকশাকে প্রভাবিত করবে না ।

Comments

এফওয়াইআই: utf8_unicode_csবিদ্যমান নেই। একমাত্র কেস-সংবেদনশীল utf8 utf8_bin। সমস্যাটি utf8_binবাছাই করা ভুল। দেখুন: stackoverflow.com/questions/15218077/…

— কোস্টা

আপডেট করার জন্য ধন্যবাদ!

— প্রমিথিউস

Answer 10

আমি এই কোলেশন চার্টগুলি সহায়ক বলে মনে করেছি। http://collation-charts.org/mysql60/ । যদিও নিশ্চিত utf8_general_ci ব্যবহৃত হয় তা আমি নিশ্চিত নই।

উদাহরণস্বরূপ এখানে utf8_swishes_ci এর চার্ট is এটি দেখায় যে এটি কোন অক্ষরকে একই হিসাবে ব্যাখ্যা করে। http://collation-charts.org/mysql60/mysql604.utf8_swedish_ci.html

Comments

চার্টের আলাদা স্বাদ: mysql.rjweb.org/utf8_colifications.html

— রিক জেমস

Answer 11

আপনার ডাটাবেস আপলোড ফাইলটিতে, কোনও লাইনের আগে ফলোইন লাইন যুক্ত করুন:

SET NAMES utf8;

এবং আপনার সমস্যা সমাধান করা উচিত।

Comments

একটি প্রশ্ন পড়ুন: অতীতে আমি পিএইচপি "ইউটিএফ -8" এ আউটপুট সেট করেছি, তবে মাইএসকিউএলে এই কোলেশনটি কোন মিলছে? আমি ভাবছি এটি ইউটিএফ -8 এর মধ্যে একটি, তবে আমি পূর্বে utf8_unicode_ci, utf8_general_ci এবং utf8_bin ব্যবহার করেছি।

— জিতেশ সোজিত্র

এই প্রশ্নের প্রশ্নের সাথে কোনও সম্পর্ক নেই। অতিরিক্তভাবে, SET NAMESসরাসরি একটি জিজ্ঞাসা জারি করা ক্লায়েন্টকে এনকোডিং সম্পর্কে জানতে দেয় না এবং খুব সূক্ষ্ম উপায়ে প্রস্তুত বিবৃতিগুলির মতো কিছু বৈশিষ্ট্যগুলি ভেঙে দিতে পারে।

— vlvaro González