Tôi sử dụng MySQL để lưu trữ dữ liệu và các trang web của tôi đều được mã hóa dưới dạng UTF-8. Tôi có nhiều ký tự tiếng Bồ Đào Nha như ç và õ và tôi tự hỏi mình có nên thoát HTML trước khi lưu trữ không.Chúng ta có nên mã hóa HTML các ký tự đặc biệt trước khi lưu chúng trong cơ sở dữ liệu không?
Nếu chúng tôi lưu trữ & làm ví dụ &? Và tại sao không)? Những ưu điểm và nhược điểm/thực tiễn tốt nhất là gì?
Không mã hóa HTML ký tự của bạn trước khi lưu trữ. Bạn nên lưu trữ dưới dạng một dạng dữ liệu thuần túy nhất có thể. Mã hóa HTML là cần thiết vì bạn sẽ hiển thị dữ liệu trên trang HTML, do đó, hãy mã hóa trong quá trình xử lý dữ liệu để tạo trang. Ví dụ: giả sử bạn quyết định bạn cũng sẽ gửi dữ liệu trong email văn bản thuần túy. Nếu bạn đã mã hóa HTML dữ liệu, bây giờ mã hóa HTML là một rào cản mà bạn phải hoàn tác.
Chọn biểu mẫu chuẩn cho dữ liệu của bạn và lưu trữ dữ liệu đó. UTF-8 là tuyệt vời, và cơ sở dữ liệu của bạn hỗ trợ nó (giả sử bạn đã tạo tất cả các bảng của bạn đúng cách). Chỉ cần lưu trữ UTF-8.
Tôi đồng ý. Đây là HTML tương đương với tính năng \ "magic quotes \" của PHP. Nó không phải là một ý tưởng tốt, bởi vì không phải tất cả các dữ liệu cần phải thoát & nó gây phiền nhiễu để xem dữ liệu đã thoát mà nó không nên. – dan04
Nó không giống nhau, theo cách khác? HTML không mã hóa đó là rào cản khi bạn cần mã hóa? I.m.o. nhiều khả năng bạn cần xuất HTML được mã hóa. Trong vài trường hợp bạn muốn nó được giải mã, bạn có thể giải mã nó. Nó cũng an toàn hơn khi một nhà phát triển quên giải mã hơn mã hóa phải không? Có thể có rất nhiều vị trí dữ liệu được sử dụng, do đó rủi ro cho nhà phát triển quên mã hóa là có thật. – feskr
Bạn có bao giờ cần tìm kiếm chúng không? Tôi không phải là một chuyên gia MySQL nhưng bạn có thể phải nhảy qua vòng để thực hiện tìm kiếm.
Bạn có lo lắng về tính chất HTML của dữ liệu hoặc mã hóa ký tự không?
Tôi sẽ cố gắng không thực hiện bất kỳ mã hóa ký tự đặc biệt nào trong DB nếu bạn có thể tránh được. Tìm kiếm, phải nhớ xử lý ràng buộc/ràng buộc đặc biệt, v.v.
điểm tuyệt vời. Tôi đã không nghĩ rằng đến nay bởi vì tôi đã không thực hiện tìm kiếm được nêu ra. Phần mềm của tôi vẫn còn sớm trong quá trình phát triển. Nhưng câu trả lời là có, tôi sẽ cần phải tìm kiếm chúng. Việc mã hóa chúng có gây ra vấn đề trong trường hợp đó không?Đọc nhận xét của bạn, tôi cho rằng tôi sẽ phải mã hóa các ký tự trong chuỗi tìm kiếm trước khi gửi truy vấn! – Mohamad
Tôi sẽ nghĩ như vậy, và thậm chí sau đó bạn sẽ gặp rắc rối với 'gần các trận đấu.' Tôi quen thuộc hơn với SQL Server trong đó có ký tự đại diện phù hợp ('LIKE' - SQL Standard?) Mà có thể có vấn đề với mã hóa. – n8wrl
Tôi sẽ không mã hóa nó trong cơ sở dữ liệu trừ khi có giá trị rõ ràng và rõ ràng để thực hiện điều đó. Bạn (và bất kỳ ai khác sẽ làm việc với dữ liệu) sẽ phải nhớ bỏ trốn khi sử dụng dữ liệu đó hoặc thoát khỏi bất kỳ dữ liệu nào bạn chèn, cập nhật hoặc so sánh với trường đó. Tôi không chắc lợi ích của việc trốn thoát nó là gì, nhưng có lẽ nó không đáng giá.
Nếu bạn đang thực hiện 100 hoặc 1000 bản trình bày trang cho mỗi lần viết thì mã hóa trên đường sẽ hiệu quả hơn. Nhưng trong hầu hết các trường hợp, tôi đoán sự khác biệt sẽ không đáng kể.
Nhưng các lý do khác (không mã hóa) là tốt, không nghi ngờ gì về nó - và dù sao cũng vô nghĩa khi mã hóa các ký tự UTF-8 thích.
Đi theo mục đích của Cơ sở dữ liệu, không nên mã hóa HTML và lưu trữ dữ liệu. Làm như vậy sẽ làm cho dữ liệu mong muốn chỉ để hiển thị trên các trang HTML (một mục đích) và cho tất cả các hoạt động khác (nhiều) bạn cần phải giải mã lại. Điều này làm giảm tính nhất quán của dữ liệu (vì tính hợp lệ, chính xác, khả năng sử dụng bị cản trở) tài sản của Cơ sở dữ liệu.
Tôi cho rằng việc mã hóa trên cơ sở dữ liệu thực sự là một nguy cơ bảo mật, vì có nghĩa là bạn sẽ không mã hóa giữa cơ sở dữ liệu và trình duyệt (vì điều này sẽ dẫn đến mã hóa kép). Điều đó có nghĩa rằng nếu có một con đường hoặc là bây giờ hoặc trong tương lai cho dữ liệu chưa mã hóa để có được vào cơ sở dữ liệu của bạn sau đó sẽ được gửi đến trình duyệt không được mã hóa. Tốt hơn để mã hóa giữa cơ sở dữ liệu và trình duyệt và do đó lưu trữ IMHO chưa được mã hóa.
ç và õ là các ký tự UTF-8. Nếu DB hỗ trợ chúng và các trang của bạn đã được mã hóa thành UTF-8 thì tại sao lại chuyển đổi? – bakoyaro
Đó là bởi vì tôi đã từng đọc về việc thoát khỏi công cụ này mà tôi nghĩ rằng đó là thực hành tiêu chuẩn, có vẻ như nó không phải! – Mohamad