Comparison of Unicode encodings: Difference between revisions

Revision as of 01:12, 26 August 2005

Revision as of 01:28, 26 August 2005

Line 6:

==Considerations other than size==

===For processing===

For processing a format should be easy to search, truncate, and generally process safely. Fixed-size characters can be helpful, but it should be remembered that even if there is a fixed width per code point (as in UTF-32), there is not a fixed width per displayed character due to [[combining character]]s. Also if you are working with a particular [[application programming interface|API]] heavily and that API has standardised on a particular Unicode encoding it is generally a good idea to use the encoding that the API does to avoid the need to convert before every call to the API. UTF-16 is popular because many APIs date to the time when Unicode was 16-bit fixed width. Unfortunately using UTF-16 encouragesmakes codecharacters thatoutside doesthe notBMP properlya handlespecial codecase pointswhich outsideincreases the BMPrisk of oversights related to thier handling.

===For communication===