移動後のサプライヤの問題

[Gość]

サービスを停止したプロバイダーの1つに障害が発生した後にサーバーからデータを移動した後、引用符などの句読点が正しく表示されます。状況はすでに発生していますが、言葉のないサポートによって解決されました。何が原因であるかを説明します。今回は答えが得られました。

引用文

基本文字列を比較する方法はlatin2_general_ciですが、テーブルの場合はutf8_general_ciがあり、テーブルの1つにlatin2_general_ciもあるため、興味があります

このような結果の欠如の場合、問題が発生する可能性がありますが、データベースを作成し管理するのは間違いです。この状況では、データの移行に問題があります。これはサイト管理者の明白な過失であるため、私たちの介入は含まれていません。データベースを作成してターゲットエンコーディングを決定し、それが各テーブルのエンコーディングと一貫していることを確認してください。主と一日が既に対象者が、あなたはまた、私たちの主張を持っていますが、それはまだコーディングこれらの違いを克服するために氏の手順を行っていない、おそらく基地の一つを再生した後、私と一緒にチャットに上げたように私には思えます。

一方で、いくつかは、まだ今まで、私は残念ながら、通知されたかについての問題を引き起こさなかった、少なくとも移動しました。

一度この問題が起こったら、それはどうですか？データベースのXの出現を修正することは、私にとって時間の無駄であり、時間を無駄にしてしまい、会社は何もする必要は全くないと感じています。私はそれを要求する権利を持っていますか？

私はあなたの現在のサプライヤーで、問題のある側面がありませんでした彼らは、パッドだったするサーバーおよびサーバーへのサーバーから「移転」、およびこの種の問題から、私が伝えられたことを追加して、私にすべての責任をzgonićしようとするだろう。そうですか？

一般的に私のところでは、すべてが大丈夫、突然動いてすべてが詰まっているように見えます。 、私はプロバイダにこのことを報告し、それで何かをする義務は感じていない、私にすべての責任は、しかし、もちろん、それは1時間以上かかることが前提であり、これを修復する技術者のネット79PLN /時間の形で利益のために出て行くと見えます

Edytowano Wrzesień 8, 2017 przez Gość (zobacz historię edycji)

[Marcin K 6]

Zamiast płacić za zmianę kodowania, możesz zrobić tak

 

1. samemu zrobić kopię bazy

 

2. ściągnąć program "Gżegżółka " - http://www.programos...,gzegzolka.html

 

3. otworzyć w programie kopię bazy (plik sql)

 

4. zmienić kodowanie z latin2 na utf8

 

5 zapisać plik

 

6. wgrać bazę na serwer

 

Powinno starczyć i zaoszczędzone 79zł. Dodatkowo w pliku SQL podczas struktury create dla tabel upewnij się że jest kodowanie utf_general_ci lub utf_polish_ci

Edytowano Maj 27, 2011 przez Marcin K (zobacz historię edycji)

[regdos 1848]

Zamiast płacić za zmianę kodowania, możesz zrobić tak

(...)

i w przypadku gdy jakieś dane są serializowane w bazie danych i zawierają znaki, które w kodowaniu utf-8 są dwubajtowe będziesz się zastanawiać dlaczego to nie zadziałało.

 

poprawnie wyświetlać znaki interpunkcyjne takie jak cudzysłowy

Poza tym to chyba nie jest związane w kodowaniem.

 

Poza tym Ci z tej firmy hostingowej nie do końca prawdę piszą bo piszą o metodzie porównywania napisów (COLLATE) a nie kodowaniu danych w bazie danych i w połączeniu i w aplikacji.

 

Podaj adres strony i gdzie ten problem występuje.

[kafi 2425]

Poza tym Ci z tej firmy hostingowej nie do końca prawdę piszą bo piszą o metodzie porównywania napisów (COLLATE) a nie kodowaniu danych w bazie danych i w połączeniu i w aplikacji.

Poprawnie piszą.

Jeśli usługodawca stosuje jako init-connect np. SET NAMES latin2, pole jest oznaczone jako UTF8, to zapisuje się to jako Latin2 w strukturze UTF8. I póki owy set names cały czas tam jest, to jest w miarę ok.

Problem pojawia się w tym, że próba eksportu w dumpie zrobi niezłą kaszankę.

A zmiana collate spowoduje próbę wykonania konwersji z owego pseudoutf8 (a w rzeczywistości w zawartości stricte bajtowej latin2) do latin2 i wygeneruje ładne znaki zapytania.

Da się to w pewien dziwaczny sposób ujednolicić, ale bez backupu w postaci bezpośrednich plików MYI i FRM nie radził bym. No i to jest tak lekko mówiąc... bardzo czasochłonne; ale jak się dopuszcza takie niespójności, to cóż, ma się problem.

[Gość]

kafi なぜあなたは私が話している会社と何か関係があると思いますか？

Edytowano Wrzesień 8, 2017 przez Gość (zobacz historię edycji)

[kafi 2425]

Nie wiem, o jakiej firmie myślisz, ale raczej mogę w 99,5% być pewien, że tylko ci się wydaje

 

Strona ta wygląda dosyć dziwnie - bo błędne wpisy są tylko w kilku miejscach i co śmieszne to nie ma żadnych problemów z polskimi ogonkami (a to mniej więcej tam były zazwyczaj problemy).

 

Żeby nie wróżyć z fusów - wykonaj w phpMyAdminie zapytanie

SHOW VARIABLES LIKE "%char%";

i wklej wynik, będziemy myśleć dalej.

[Gość]

Variable_name Value

character_set_client utf8

character_set_connection utf8

character_set_database latin2

character_set_filesystem binary

character_set_results utf8

character_set_server latin2

character_set_system utf8

character_sets_dir /usr/share/mysql/charsets/

[regdos 1848]

Mam do czynienia z różnymi klientami i różnymi bazami danych i zawsze udało mi się przenieść dane bez problemu. W mojej opinii wina leży tylko i wyłączenie po stronie hostingu, bo nieważne jak są dane w bazie to jeżeli firma sama z siebie je przenosi to dane maja być po przenosinach takie same jak przed i nie ma z czym dyskutować.

[Gość]

Regdosも、私は真剣にこのような重大な違法行為をしたかどうかを判断するための話題を設定しました。私は、この会社の所有者が私と彼との間で長くて強く対話するので、私を説得しようとしています。

だから私はホスティング会社を変えているし、私はホスティングからホスティングにこのサイトを移動し、すべてがスムーズに行ったので、私は荒廃されませんが、結局あなたは所有者に説明する必要があります...

だから私は自分の部分で私は手動で生成するすべてを変更することができます理解する方法は？

Edytowano Wrzesień 8, 2017 przez Gość (zobacz historię edycji)

[crazyluki 114]

widziałeś : http://php.net/manual/en/function.mysql-set-charset.php

[Gość]

crazyluki: 私ははいと言うかもしれません

サイト上のスクリプトはWordPressで、3か月前、半年まで "落とし込んで"手に入りました。 私は何も動かさなかった、私は何も掘っていないが、データベースに今疑問符です...

Edytowano Wrzesień 8, 2017 przez Gość (zobacz historię edycji)

[regdos 1848]

widziałeś : http://php.net/manua...set-charset.php

 

Zauważ, ze problemem nie są polskie znaki tylko chyba długie myślniki i cudzysłowy drukarskie (ono są dwubajtowe w UTF) ale w innych miejscach te znaki się poprawnie wyświetlają np. http://www.biblioteka.lazy.pl/2009/11/30/w-bibliotece-grudzien-2009/ i naprawdę nie ma tutaj o czym dyskutować bo wina firmy przenoszącej jest ewidentna - coś zepsuli - a zganianie tego na użytkownika, że to wina jego ustawionego collate jest żałosna.

[Gość]

サプライヤにこの問題を解決させるためにどのような議論をすることができますか？彼らは何が欲しくないのですか？

Edytowano Wrzesień 8, 2017 przez Gość (zobacz historię edycji)

[regdos 1848]

Jakich więc argumentów mogę użyć, aby wymusić na dostawcy naprawienie tego problemu, czego zrobić nie chce?

 

Argument jest jeden, działało a po Państwa działaniach przestało więc prosisz o przywrócenie do stanu pierwotnego. Ewentualnie poproś o dostęp do starego serwera i starej bazy żeby samemu się tym zająć.

[Gość]

古いサーバーが死んでいる、このトピックを参照した後、私はこの答えがあります：

こんにちは、

私たちのページの主題は十分明確に示されています。 この主題を知らない第三者の声明は私には興味がありません、私はすでにあなたにそれを言いました。

 

 

 

Edytowano Wrzesień 8, 2017 przez Gość (zobacz historię edycji)