სხვადასხვა PHP კოდირება
ახალბედა სცენარის ავტორები არ აინტერესებს ისეთი რამ, როგორც კოდირება. აქედან გამომდინარე, საიტებზე ზოგჯერ შეგიძლიათ იპოვოთ საშინელი არეულობა, როდესაც მონაცემთა ბაზის მონაცემები მიიღება ერთი კოდირებით, გვერდი ჩამოყალიბებულია მეორეში და სერვერი მესამეა. შედეგად, თუ გვერდი შეიძლება გაშიფრულიყო, მაშინ სულ მცირე 2-ჯერ. ��სე რომ, რატომ ხდება ასეთი პრობლემა და როგორ გადალახოს იგი?
რუსულ სეგმენტში ყველაზე ხშირად შეგიძლიათ იპოვოთ ე.წ. Windows- კოდირება. სხვაგვარად დარეკეთ: Windows-1251, cp1251 ან თუნდაც ansi. შემდეგი არის utf-8. ასევე შეგიძლიათ მოიძიოთ სახელი უნიკოდი, მაგრამ ეს არ არის მთლიანად სწორი, რადგან უნიკოდი არის მთელი ჯგუფის საერთო სახელი (utf-8, utf-16, utf-32). და ძალიან პოპულარული rarity არის koi8-r ან უბრალოდ koi-8 - ერთხელ პოპულარული Linux კოდირება. რასაკვირველია, შესაძლებელია რუსეთის სეგმენტში რაღაც სხვაგვარად შეხვდეს, მაგრამ ეს ავტორის მიერ "სიამოვნებაა".
© - & ასლი;
გარდა იმისა, რომ ყოველი ასეთი ხასიათი აღწერს პერსონაჟთა ჯგუფს, კოდი ხდება არასწორი და ტექსტის მუშაობა უფრო გართულებულია. ეს არის სადაც მულტიმედია უტე -8 მოდის სამაშველოში. ძალიან მოსახერხებელია გამოიყენოს სხვადასხვა ალფაბეტებისა და სხვადასხვა სიმბოლოების ასოები ერთ ტექსტში.
ამდენად, საწყის პირობებში ყველაზე კომფორტული კომპლექტია: მონაცემთა ბაზის კოდი, php სკრიპტი და html გვერდები / js სკრიპტები უნდა იყოს იგივე. რა თქმა უნდა, თქვენ შეგიძლიათ გამოიყენოთ სხვადასხვა, მაგრამ ამ შემთხვევაში არსებობს დაბნეული რისკი. არ აქვს მნიშვნელობა, რომელი კოდი გამოიყენება. თუ საიტი მხოლოდ რუსულენოვანი აუდიტორიისთვისაა, Windows-1251 საკმაოდ საკმარისი იქნება. სხვაგვარად, utf-8 იქნება ლოგიკური არჩევანი. პირველი ვარიანტი მეტ-ნაკლებად ნათელია. multibyte კოდირების მოითხოვს გარკვეული ჟესტები.
Uf-8- სთან მუშაობისას სტანდარტული ნოუთუსი არ მუშაობს ! ფაქტია, რომ ამ რედაქტორმა, ამ კოდირებისას ფაილის შენახვისას, დასძენს ხელმოწერის დასაწყისში - 3 სიმბოლო, ე.წ. ბომბი (ბიტიანი შეკვეთა ნიშანი), რომელიც შეიძლება გამოყენებულ იქნეს კოდირების განსაზღვრისას ფაილის გახსნისას. უმჯობესია აირჩიოთ სხვა რედაქტორი: notepad2 ან notepad ++ . პარამეტრებში უნდა აირჩიოთ შენახვა ხელმოწერის გარეშე.
შემდეგი მნიშვნელოვანი ნაბიჯი მუშაობს მონაცემთა ბაზასთან. სასურველია, რომ ბაზის / მაგიდის / ტექსტის ველის კოდირება შეესაბამება სკრიპტის კოდირებას (ეს შეიძლება იყოს cp1251 ან utf-8 ან სხვა რამ). თუ მონაცემთა ბაზის მონაცემები მიღებული იქნა "zyuk" სახით, სავარაუდოდ კავშირის კოდირება განსხვავდება მონაცემთა ბაზაში შენახული მონაცემებისაგან. შემდეგი შეკითხვა ხელს შეუწყობს სიტუაციის დაძლევას (შეასრულოს მონაცემთა ბაზასთან დაკავშირებისთანავე):
თუ საიტი იყენებს Windows-1251, თქვენ უნდა მიუთითოთ ის - cp1251.
ზოგადად, არაფერია რთული. მხოლოდ სტანდარტული PHP ფუნქციები არ არის შექმნილი მრავალმხრივი სიმებიანი მუშაობით. მაგრამ არსებობს სტანდარტული ბიბლიოთეკები, რომლებიც ხელს შეუწყობს სიტუაციის გამოსწორებას: iconv და mbstring . რეგულარული გამოხატვისთვის, ასევე საჭიროა შეცვლა, რომელიც გააქტიურებულია მოდიფიკატორის საშუალებით.
ასევე, მონაცემთა ბაზის მონაცემები მიღებულია, სკრიპტები იწერება ყველა წესის მიხედვით. ის რჩება სწორი სათაურის გაგზავნისა და გვერდის კოდი მომხმარებლის მომხმარებლის ბრაუზერში. ჩვენ ვგზავნით სასაქონლო პოზიციას:
სათაური ('content-type: text / html; charset = utf-8');
თუ ერთჯერადი ბიტიანი კოდირება გამოიყენება, სიმბოლოთა ღირებულება განსხვავდება Windows-1251 . ამის შემდეგ პრობლემები არ უნდა დარჩეს.
Uf-8- ში მუშაობის ზოგიერთი მარტივი მაგალითი:
მაგალითი 1: iconv, სიმბოლოთა რაოდენობა თითო ხაზი
$ s = 'string'; # string in utf-8 $ cnt1 = strlen ($ s); # შეიცავს ღირებულებას $ 12 cnt2 = iconv_strlen ($ s, 'UTF-8'); # სწორი ღირებულება, 6
მაგალითი 2: mbstring, სიმბოლოთა სიმბოლოების რაოდენობა
$ s = 'string'; # string in utf-8 $ cnt1 = strlen ($ s); # შეიცავს ღირებულებას $ 12 cnt2 = mb_strlen ($ s, 'UTF-8'); # სწორი ღირებულება, 6
მაგალითი 3: რეგულარული გამოხატვა, ძიება და გამოცვლა
$ s = 'სიმებიანი'; # ხაზი utf-8 $ s = preg_replace ('/ p / i', 'd', $ s); # ჩანაცვლება არ მოხდება $ s = preg_replace ('/ p / iu', 'd', $ s); # შედეგი სიტყვა დოკი
i მოდიფიკატორის განსაზღვრავს case-insensitive ძებნა და u მოდიფიკატორი ეუბნება რეგულარული გამოხატვის ძრავა მუშაობა utf-8 სიმები.
თუ ვინმე ამბობს, რომ php ვერ მუშაობს utf-8, ეს იქნება არასწორი. რამდენიმე წელია, რაც ამ პროექტს ვაკეთებ ამ პროექტში და არანაირი პრობლემა არ ყოფილა. საძიებო სისტემებმა დიდი ხანია გამოიყენეს ეს შესანიშნავი კოდირება.
გამომცემელი
ფორუმზე 11 საათი
x64 (aka andi)
კომენტარები: 2846 პუბლიკაციები: 395 რეგისტრაცია: 02-04-2009
?სე რომ, რატომ ხდება ასეთი პრობლემა და როგორ გადალახოს იგი?