Używam MySQL do przechowywania danych, a moje strony internetowe są kodowane jako UTF-8. Mam wiele portugalskich znaków, takich jak ç i õ i zastanawiam się, czy powinienem uciec przed nimi w HTML-u.Czy powinniśmy kodować znaki specjalne HTML przed przechowywaniem ich w bazie danych?
Czy na przykład przechowywać & jako &? Czemu nie)? Jakie są zalety i wady/najlepsze praktyki?
Nie przechowuj kodu HTML przed zapisaniem. Powinieneś przechowywać jako czystą formę swoich danych, jak to możliwe. Kodowanie HTML jest potrzebne, ponieważ zamierzasz wyświetlać dane na stronie HTML, tak samo jak kodowanie podczas przetwarzania danych w celu utworzenia strony. Załóżmy na przykład, że zdecydujesz, że będziesz także wysyłać dane w wiadomościach tekstowych. Jeśli dane zostały zakodowane w HTML, teraz kodowanie HTML stanowi barierę, którą należy cofnąć.
Wybierz formularz kanoniczny dla swoich danych i zapisz go. UTF-8 jest cudowny, a twoja baza danych go obsługuje (zakładając, że poprawnie utworzyłeś wszystkie tabele). Po prostu przechowuj UTF-8.
Zgadzam się. Jest to odpowiednik HTML \ "s \" \ "magicznych cytatów \" funkcji. To nie jest dobry pomysł, ponieważ nie wszystkie potrzeby dotyczące danych uciekają & jest denerwujące, aby zobaczyć dane z ewakuacją tam, gdzie nie powinno być. – dan04
Czy to nie to samo, na odwrót? Że niekodowany kod HTML jest barierą, kiedy jej potrzebujesz? I.m.o. jest bardziej prawdopodobne, że musisz wyprowadzić kodowany kod HTML. W nielicznych przypadkach, kiedy chcesz to zdekodować, możesz go odkodować. Bezpieczniej jest także, gdy programista zapomina o dekodowaniu, a nie kodowaniu, prawda? Może być wiele lokalizacji danych, więc ryzyko, że programista zapomni kodowania, jest prawdziwe. – feskr
Czy kiedykolwiek będziesz musiał je wyszukać? Nie jestem ekspertem od MySQL, ale być może będziesz musiał przeskakiwać przez obręcze, by wyszukiwać.
Czy jesteś zaniepokojony HTML-a danych lub kodowania znaków?
Powiedziałbym, że staraj się nie robić specjalnego kodowania znaków w DB, jeśli możesz tego uniknąć. Wyszukiwanie, konieczność pamiętania specjalnego przetwarzania wejścia/wyjścia, itp.
świetny punkt. Nie myślałem tak daleko, ponieważ jeszcze nie zaimplementowałem wyszukiwania. Moje oprogramowanie jest jeszcze na wczesnym etapie rozwoju. Ale odpowiedź brzmi: tak, będę musiał je wyszukać. Czy kodowanie powoduje w tym przypadku problemy?Czytając twój komentarz, zakładam, że będę musiał zakodować znaki w ciągu wyszukiwania przed wysłaniem zapytania! – Mohamad
Tak sądzę, a nawet wtedy miałbyś kłopot z "bliskimi meczami". Jestem bardziej zaznajomiony z SQL Server, który ma dopasowanie z użyciem symboli wieloznacznych ("LIKE" - SQL Standard?), Co może być problematyczne z kodowaniem. – n8wrl
Nie zakodowałbym tego w bazie danych, chyba że jest do tego wyraźna i konkretna wartość. Ty (i każdy, kto kiedykolwiek będzie pracował z danymi), będziesz musiał pamiętać, aby nie uciekać, gdy używasz tych danych, lub uciekać od danych, które wstawisz, zaktualizujesz lub porównasz z tym polem. Nie jestem pewien, jaką korzyścią jest ucieczka, ale prawdopodobnie nie warto.
Jeśli wykonujesz 100 lub 1000 prezentacji strony dla każdego zapisu, kodowanie w drodze będzie bardziej efektywne. Ale w większości przypadków myślę, że różnica byłaby znikoma.
Ale inne powody (aby nie kodować) są dobre, bez wątpienia - i tak nie ma sensu kodować znaków, które lubi UTF-8.
Przechodząc do celu bazy danych, nie zaleca się kodowania w HTML i przechowywania danych. Spowoduje to, że dane będą pożądane tylko do renderowania na stronach HTML (jeden cel) i do wszystkich innych operacji (wielu), które trzeba ponownie rozszyfrować. Zmniejsza to spójność danych (ponieważ ważność, dokładność, użyteczność są utrudnione) właściwości bazy danych.
Twierdzę, że kodowanie w drodze do bazy danych jest w rzeczywistości zagrożeniem bezpieczeństwa, ponieważ oznacza, że prawdopodobnie nie będzie kodowania między bazą danych a przeglądarką (ponieważ mogłoby to prowadzić do podwójnego kodowania). Oznacza to, że jeśli do bazy danych zostanie wprowadzona teraz lub w przyszłości informacja niekodowana, to zostanie ona wysłana do przeglądarki bez szyfrowania. Lepiej kodować bazę danych i przeglądarkę, a zatem przechowywać niekodowane IMHO.
ç i õ są znakami UTF-8. Jeśli DB obsługuje je, a twoje strony są już zakodowane do UTF-8, to po co konwertować? – bakoyaro
To dlatego, że jestem przyzwyczajony do czytania o ucieczce z tych rzeczy, które uważałem za standardową praktykę, najwyraźniej tak nie jest! – Mohamad