Re: What all could be the security issues in Unicode Database
From: AnthonyThomas (Anthony.Thomas_at_CommerceBank.com)
Date: 12/14/04
- Next message: Brian Brown: "Re: problem"
- Previous message: AnthonyThomas: "Re: Incompability between MSSQL2000 SERVER 64 AND 32 BITS"
- In reply to: Mike Epprecht \(SQL MVP\): "Re: What all could be the security issues in Unicode Database"
- Next in thread: Bart Duncan [MSFT]: "Re: What all could be the security issues in Unicode Database"
- Reply: Bart Duncan [MSFT]: "Re: What all could be the security issues in Unicode Database"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 13 Dec 2004 23:25:48 -0600
Conversion or not, storage is another matter. Convert it if you must, but
even that is not a standard. Take a look at UTF-8. SQL Server does not
support this. So, there is the doubling of the storage.
Again, a presentation or, at least, an application issue.
Sincerely,
Anthony Thomas
-- "Mike Epprecht (SQL MVP)" <mike@epprecht.net> wrote in message news:%23K9dgYV4EHA.1392@tk2msftngp13.phx.gbl... Hi Don't forget, all NT based OS's use UNICODE internally, so the data gets converted to UNICODE and is used in the OS as UNICODE. If an application is not UNICODE, the OS converts it for it. .NET framework is UNICODE. If you like it or not, the conversion happens automatically. -- -------------------------------- Mike Epprecht, Microsoft SQL Server MVP Zurich, Switzerland IM: mike@epprecht.net MVP Program: http://www.microsoft.com/mvp Blog: http://www.msmvps.com/epprecht/ "AnthonyThomas" <Anthony.Thomas@CommerceBank.com> wrote in message news:OnwJcuR4EHA.1564@TK2MSFTNGP09.phx.gbl... > Not to mention that UNICODE is horribly inefficient. You do not need to use > it unless you know for fact that you will be using extended code pages and > character sets, like Kana Fonts, and such. > > The reason is that UNICODE stores ALL character information in a 2-byte > storage assignement. For any character that would have fall in the normal > ASCII range, UNICODE stores a 0x00 in the High-Ordered byte and the normal > ASCII code in the Low-Ordered byte. You'd be paying to store a lot of > zero's just for the off-chance that someone might be needing to store an > extended character. > > That is not to say that UNICODE does not have a place. Names (people, > places, things) are good candidates for NVARCHAR data types, especially on > Websites where you do not know a priori who may be using the site, but for > all of the internal data elements, you, as the designer, should know exactly > what charater types are going to be allowed. You could even swith > collations and code pages for individual table attributes if you knew which > character sets would be used for them. All of this without the expense of > UNICODE. > > It is up to you, but when your superiors start asking why the database is so > big and expensive, you can tell them you jumped on the UNICODE Hype > bandwagon and its just they price they have to pay to be "cutting edge." > > Sincerely, > > > Anthony Thomas > > -- > > "Mike Epprecht (SQL MVP)" <mike@epprecht.net> wrote in message > news:9A2BA7C8-38E5-48CA-9521-7694146A5D8A@microsoft.com... > Hi > > Normal security issues apply, like SQL Injection, bad permissioning etc. > UNICODE does not bring any specific issues with it from a security > perspective. > > Regards > Mike > > "Sierra" wrote: > > > Hi > > > > Can u guys give me some inputs as to what all could be the security > concerns > > in an Unicode Database > > > > Regards > > Sierra > > > > > > > >
- Next message: Brian Brown: "Re: problem"
- Previous message: AnthonyThomas: "Re: Incompability between MSSQL2000 SERVER 64 AND 32 BITS"
- In reply to: Mike Epprecht \(SQL MVP\): "Re: What all could be the security issues in Unicode Database"
- Next in thread: Bart Duncan [MSFT]: "Re: What all could be the security issues in Unicode Database"
- Reply: Bart Duncan [MSFT]: "Re: What all could be the security issues in Unicode Database"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
