Author: paul
Date: 2006-01-15 05:58:07 +0100 (Sun, 15 Jan 2006)
New Revision: 837
Log:
r6217@frost: paul | 2006-01-14 22:13:02 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/charset.xml
trunk/refman-5.0/charset.xml
trunk/refman-5.1/charset.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6216
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2175
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6217
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2175
Modified: trunk/refman-4.1/charset.xml
===================================================================
--- trunk/refman-4.1/charset.xml 2006-01-15 04:57:51 UTC (rev 836)
+++ trunk/refman-4.1/charset.xml 2006-01-15 04:58:07 UTC (rev 837)
@@ -3178,14 +3178,15 @@
</indexterm>
<para>
- The <literal>utf8_unicode_ci</literal> collation is implemented
- according to the Unicode Collation Algorithm (UCA) described at
+ MySQL implements the <literal>utf8_unicode_ci</literal>
+ collation according to the Unicode Collation Algorithm (UCA)
+ described at
<ulink url="http://www.unicode.org/reports/tr10/"/>. The
collation uses the version-4.0.0 UCA weight keys:
<ulink url="http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt"/>.
- (The following discussion uses
+ The following discussion uses
<literal>utf8_unicode_ci</literal>, but it is also true for
- <literal>ucs2_unicode_ci</literal>.)
+ <literal>ucs2_unicode_ci</literal>.
</para>
<para>
@@ -3212,7 +3213,7 @@
comparisons between characters. This means that comparisons for
the <literal>utf8_general_ci</literal> collation are faster, but
slightly less correct, than comparisons for
- <literal>utf8_unicode_ci</literal>).
+ <literal>utf8_unicode_ci</literal>.
</para>
<para>
@@ -3245,8 +3246,8 @@
</programlisting>
<para>
- Language-specific collations for the <literal>utf8</literal>
- character set are implemented only if the ordering with
+ MySQL implements language-specific collations for the
+ <literal>utf8</literal> character set only if the ordering with
<literal>utf8_unicode_ci</literal> does not work well for a
language. For example, <literal>utf8_unicode_ci</literal> works
fine for German and French, so there is no need to create
@@ -3255,7 +3256,7 @@
</para>
<para>
- <literal>utf8_general_ci</literal> is also satisfactory for both
+ <literal>utf8_general_ci</literal> also is satisfactory for both
German and French, except that
‘<literal>ß</literal>’ is equal to
‘<literal>s</literal>’, and not to
@@ -3398,8 +3399,7 @@
<listitem>
<para>
- <literal>latin1</literal> (cp1252 West European) collations
- (see the annotations about <quote>latin1</quote> below):
+ <literal>latin1</literal> (cp1252 West European) collations:
</para>
<itemizedlist>
@@ -3455,8 +3455,30 @@
</itemizedlist>
<para>
- <literal>latin1</literal> is the default character set. The
- <literal>latin1_swedish_ci</literal> collation is the
+ <literal>latin1</literal> is the default character set.
+ MySQL's <literal>latin1</literal> is the same as the Windows
+ <literal>cp1252</literal> character set. This means it is
+ the same as the official <literal>ISO 8859-1</literal> or
+ IANA (Internet Assigned Numbers Authority)
+ <literal>latin1</literal>, but IANA
+ <literal>latin1</literal> treats the code points between
+ <literal>0x80</literal> and <literal>0x9f</literal> as
+ <quote>undefined,</quote> whereas <literal>cp1252</literal>,
+ and therefore MySQL's <literal>latin1</literal>, assign
+ characters for those positions. For example,
+ <literal>0x80</literal> is the Euro sign. For the
+ <quote>undefined</quote> entries in
+ <literal>cp1252</literal>, MySQL translates
+ <literal>0x81</literal> to Unicode
+ <literal>0x0081</literal>, <literal>0x8d</literal> to
+ <literal>0x008d</literal>, <literal>0x8f</literal> to
+ <literal>0x008f</literal>, <literal>0x90</literal> to
+ <literal>0x0090</literal>, and <literal>0x9d</literal> to
+ <literal>0x009d</literal>.
+ </para>
+
+ <para>
+ The <literal>latin1_swedish_ci</literal> collation is the
default that probably is used by the majority of MySQL
customers. Although it is frequently said that it is based
on the Swedish/Finnish collation rules, there are Swedes and
@@ -3557,27 +3579,6 @@
</itemizedlist>
- <para>
- <emphasis>Annotations regarding
- <literal>latin1</literal>:</emphasis> MySQL's
- <literal>latin1</literal> is the same as the Windows
- <literal>cp1252</literal> character set. This means it is the
- same as the official <literal>ISO 8859-1</literal> or IANA
- (Internet Assigned Numbers Authority) <literal>latin1</literal>,
- but IANA <literal>latin1</literal> treats the code points
- between 0x80 and 0x9f as <quote>undefined,</quote> while
- <literal>cp1252</literal>, and therefore MySQL's
- <literal>latin1</literal>, assign characters for those
- positions. For example, 0x80 is the Euro sign. For the
- <quote>undefined</quote> entries in <literal>cp1252</literal>,
- MySQL translates <literal>0x81</literal> to Unicode
- <literal>0x0081</literal>, <literal>0x8d</literal> to
- <literal>0x008d</literal>, <literal>0x8f</literal> to
- <literal>0x008f</literal>, <literal>0x90</literal> to
- <literal>0x0090</literal>, and <literal>0x9d</literal> to
- <literal>0x009d</literal>.
- </para>
-
</section>
<section id="charset-ce-sets">
@@ -3585,9 +3586,9 @@
<title>&title-charset-ce-sets;</title>
<para>
- We also provide some support for character sets used in the
- Czech Republic, Slovakia, Hungary, Romania, Slovenia, Croatia,
- and Poland.
+ MySQL provides some support for character sets used in the Czech
+ Republic, Slovakia, Hungary, Romania, Slovenia, Croatia, and
+ Poland.
</para>
<itemizedlist>
@@ -3746,7 +3747,7 @@
<para>
South European and Middle Eastern character sets supported by
MySQL include Armenian, Arabic, Georgian, Greek, Hebrew, and
- Turkish:
+ Turkish.
</para>
<itemizedlist>
@@ -3893,8 +3894,7 @@
<para>
The Baltic character sets cover Estonian, Latvian, and
- Lithuanian languages. There are two Baltic character sets
- currently supported:
+ Lithuanian languages.
</para>
<itemizedlist>
@@ -3970,7 +3970,7 @@
<title>&title-charset-cyrillic-sets;</title>
<para>
- Here are the Cyrillic character sets and collations for use with
+ The Cyrillic character sets and collations are for use with
Belarusian, Bulgarian, Russian, and Ukrainian languages.
</para>
@@ -4101,7 +4101,9 @@
The Asian character sets that we support include Chinese,
Japanese, Korean, and Thai. These can be complicated. For
example, the Chinese sets must allow for thousands of different
- characters.
+ characters. See <xref linkend="charset-cp932"/>, for additional
+ information about the <literal>cp932</literal> and
+ <literal>sjis</literal> character sets.
</para>
<itemizedlist>
@@ -4425,11 +4427,10 @@
<para>
Some <literal>cp932</literal> characters have two
different code points, both of which convert to the same
- Unicode code point. So, when converting from Unicode back
- to <literal>cp932</literal>, one of the code points must
- be selected. For this <quote>round trip
- conversion,</quote> the rule recommended by Microsoft is
- used. (See
+ Unicode code point. When converting from Unicode back to
+ <literal>cp932</literal>, one of the code points must be
+ selected. For this <quote>round trip conversion,</quote>
+ the rule recommended by Microsoft is used. (See
<ulink url="http://support.microsoft.com/kb/170559/EN-US/"/>.)
</para>
@@ -4465,11 +4466,11 @@
</itemizedlist>
<para>
- Information about the Unicode values of
- <literal>cp932</literal> characters is given in the table
- shown at
- <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>.
- For <literal>cp932</literal> table entries with characters
+ The table shown at
+ <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>
+ provides information about the Unicode values of
+ <literal>cp932</literal> characters. For
+ <literal>cp932</literal> table entries with characters
under which a four-digit number appears, the number
represents the corresponding Unicode
(<literal>ucs2</literal>) encoding. For table entries with
Modified: trunk/refman-5.0/charset.xml
===================================================================
--- trunk/refman-5.0/charset.xml 2006-01-15 04:57:51 UTC (rev 836)
+++ trunk/refman-5.0/charset.xml 2006-01-15 04:58:07 UTC (rev 837)
@@ -2685,8 +2685,7 @@
</itemizedlist>
<para>
- <emphasis role="bold">Note</emphasis>: The
- <literal>ucs2_esperanto_ci</literal> and
+ The <literal>ucs2_esperanto_ci</literal> and
<literal>utf8_esperanto_ci</literal> collations were added in
MySQL 5.0.13. The <literal>ucs2_hungarian_ci</literal> and
<literal>utf8_hungarian_ci</literal> collations were added in
@@ -2698,14 +2697,15 @@
</indexterm>
<para>
- The <literal>utf8_unicode_ci</literal> collation is implemented
- according to the Unicode Collation Algorithm (UCA) described at
+ MySQL implements the <literal>utf8_unicode_ci</literal>
+ collation according to the Unicode Collation Algorithm (UCA)
+ described at
<ulink url="http://www.unicode.org/reports/tr10/"/>. The
collation uses the version-4.0.0 UCA weight keys:
<ulink url="http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt"/>.
- (The following discussion uses
+ The following discussion uses
<literal>utf8_unicode_ci</literal>, but it is also true for
- <literal>ucs2_unicode_ci</literal>.)
+ <literal>ucs2_unicode_ci</literal>.
</para>
<para>
@@ -2732,7 +2732,7 @@
comparisons between characters. This means that comparisons for
the <literal>utf8_general_ci</literal> collation are faster, but
slightly less correct, than comparisons for
- <literal>utf8_unicode_ci</literal>).
+ <literal>utf8_unicode_ci</literal>.
</para>
<para>
@@ -2765,8 +2765,8 @@
</programlisting>
<para>
- Language-specific collations for the <literal>utf8</literal>
- character set are implemented only if the ordering with
+ MySQL implements language-specific collations for the
+ <literal>utf8</literal> character set only if the ordering with
<literal>utf8_unicode_ci</literal> does not work well for a
language. For example, <literal>utf8_unicode_ci</literal> works
fine for German and French, so there is no need to create
@@ -2775,7 +2775,7 @@
</para>
<para>
- <literal>utf8_general_ci</literal> is also satisfactory for both
+ <literal>utf8_general_ci</literal> also is satisfactory for both
German and French, except that
‘<literal>ß</literal>’ is equal to
‘<literal>s</literal>’, and not to
@@ -2918,8 +2918,7 @@
<listitem>
<para>
- <literal>latin1</literal> (cp1252 West European) collations
- (see the annotations about <quote>latin1</quote> below):
+ <literal>latin1</literal> (cp1252 West European) collations:
</para>
<itemizedlist>
@@ -2975,8 +2974,30 @@
</itemizedlist>
<para>
- <literal>latin1</literal> is the default character set. The
- <literal>latin1_swedish_ci</literal> collation is the
+ <literal>latin1</literal> is the default character set.
+ MySQL's <literal>latin1</literal> is the same as the Windows
+ <literal>cp1252</literal> character set. This means it is
+ the same as the official <literal>ISO 8859-1</literal> or
+ IANA (Internet Assigned Numbers Authority)
+ <literal>latin1</literal>, but IANA
+ <literal>latin1</literal> treats the code points between
+ <literal>0x80</literal> and <literal>0x9f</literal> as
+ <quote>undefined,</quote> whereas <literal>cp1252</literal>,
+ and therefore MySQL's <literal>latin1</literal>, assign
+ characters for those positions. For example,
+ <literal>0x80</literal> is the Euro sign. For the
+ <quote>undefined</quote> entries in
+ <literal>cp1252</literal>, MySQL translates
+ <literal>0x81</literal> to Unicode
+ <literal>0x0081</literal>, <literal>0x8d</literal> to
+ <literal>0x008d</literal>, <literal>0x8f</literal> to
+ <literal>0x008f</literal>, <literal>0x90</literal> to
+ <literal>0x0090</literal>, and <literal>0x9d</literal> to
+ <literal>0x009d</literal>.
+ </para>
+
+ <para>
+ The <literal>latin1_swedish_ci</literal> collation is the
default that probably is used by the majority of MySQL
customers. Although it is frequently said that it is based
on the Swedish/Finnish collation rules, there are Swedes and
@@ -3077,27 +3098,6 @@
</itemizedlist>
- <para>
- <emphasis>Annotations regarding
- <literal>latin1</literal>:</emphasis> MySQL's
- <literal>latin1</literal> is the same as the Windows
- <literal>cp1252</literal> character set. This means it is the
- same as the official <literal>ISO 8859-1</literal> or IANA
- (Internet Assigned Numbers Authority) <literal>latin1</literal>,
- but IANA <literal>latin1</literal> treats the code points
- between 0x80 and 0x9f as <quote>undefined,</quote> while
- <literal>cp1252</literal>, and therefore MySQL's
- <literal>latin1</literal>, assign characters for those
- positions. For example, 0x80 is the Euro sign. For the
- <quote>undefined</quote> entries in <literal>cp1252</literal>,
- MySQL translates <literal>0x81</literal> to Unicode
- <literal>0x0081</literal>, <literal>0x8d</literal> to
- <literal>0x008d</literal>, <literal>0x8f</literal> to
- <literal>0x008f</literal>, <literal>0x90</literal> to
- <literal>0x0090</literal>, and <literal>0x9d</literal> to
- <literal>0x009d</literal>.
- </para>
-
</section>
<section id="charset-ce-sets">
@@ -3105,9 +3105,9 @@
<title>&title-charset-ce-sets;</title>
<para>
- We also provide some support for character sets used in the
- Czech Republic, Slovakia, Hungary, Romania, Slovenia, Croatia,
- and Poland.
+ MySQL provides some support for character sets used in the Czech
+ Republic, Slovakia, Hungary, Romania, Slovenia, Croatia, and
+ Poland.
</para>
<itemizedlist>
@@ -3266,7 +3266,7 @@
<para>
South European and Middle Eastern character sets supported by
MySQL include Armenian, Arabic, Georgian, Greek, Hebrew, and
- Turkish:
+ Turkish.
</para>
<itemizedlist>
@@ -3413,8 +3413,7 @@
<para>
The Baltic character sets cover Estonian, Latvian, and
- Lithuanian languages. There are two Baltic character sets
- currently supported:
+ Lithuanian languages.
</para>
<itemizedlist>
@@ -3490,7 +3489,7 @@
<title>&title-charset-cyrillic-sets;</title>
<para>
- Here are the Cyrillic character sets and collations for use with
+ The Cyrillic character sets and collations are for use with
Belarusian, Bulgarian, Russian, and Ukrainian languages.
</para>
@@ -3621,7 +3620,9 @@
The Asian character sets that we support include Chinese,
Japanese, Korean, and Thai. These can be complicated. For
example, the Chinese sets must allow for thousands of different
- characters.
+ characters. See <xref linkend="charset-cp932"/>, for additional
+ information about the <literal>cp932</literal> and
+ <literal>sjis</literal> character sets.
</para>
<itemizedlist>
@@ -3942,11 +3943,10 @@
<para>
Some <literal>cp932</literal> characters have two
different code points, both of which convert to the same
- Unicode code point. So, when converting from Unicode back
- to <literal>cp932</literal>, one of the code points must
- be selected. For this <quote>round trip
- conversion,</quote> the rule recommended by Microsoft is
- used. (See
+ Unicode code point. When converting from Unicode back to
+ <literal>cp932</literal>, one of the code points must be
+ selected. For this <quote>round trip conversion,</quote>
+ the rule recommended by Microsoft is used. (See
<ulink url="http://support.microsoft.com/kb/170559/EN-US/"/>.)
</para>
@@ -3982,11 +3982,11 @@
</itemizedlist>
<para>
- Information about the Unicode values of
- <literal>cp932</literal> characters is given in the table
- shown at
- <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>.
- For <literal>cp932</literal> table entries with characters
+ The table shown at
+ <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>
+ provides information about the Unicode values of
+ <literal>cp932</literal> characters. For
+ <literal>cp932</literal> table entries with characters
under which a four-digit number appears, the number
represents the corresponding Unicode
(<literal>ucs2</literal>) encoding. For table entries with
Modified: trunk/refman-5.1/charset.xml
===================================================================
--- trunk/refman-5.1/charset.xml 2006-01-15 04:57:51 UTC (rev 836)
+++ trunk/refman-5.1/charset.xml 2006-01-15 04:58:07 UTC (rev 837)
@@ -2677,8 +2677,7 @@
</itemizedlist>
<para>
- <emphasis role="bold">Note</emphasis>: The
- <literal>ucs2_hungarian_ci</literal> and
+ The <literal>ucs2_hungarian_ci</literal> and
<literal>utf8_hungarian_ci</literal> collations were added in
MySQL 5.1.5.
</para>
@@ -2688,14 +2687,15 @@
</indexterm>
<para>
- The <literal>utf8_unicode_ci</literal> collation is implemented
- according to the Unicode Collation Algorithm (UCA) described at
+ MySQL implements the <literal>utf8_unicode_ci</literal>
+ collation according to the Unicode Collation Algorithm (UCA)
+ described at
<ulink url="http://www.unicode.org/reports/tr10/"/>. The
collation uses the version-4.0.0 UCA weight keys:
<ulink url="http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt"/>.
- (The following discussion uses
+ The following discussion uses
<literal>utf8_unicode_ci</literal>, but it is also true for
- <literal>ucs2_unicode_ci</literal>.)
+ <literal>ucs2_unicode_ci</literal>.
</para>
<para>
@@ -2722,7 +2722,7 @@
comparisons between characters. This means that comparisons for
the <literal>utf8_general_ci</literal> collation are faster, but
slightly less correct, than comparisons for
- <literal>utf8_unicode_ci</literal>).
+ <literal>utf8_unicode_ci</literal>.
</para>
<para>
@@ -2755,8 +2755,8 @@
</programlisting>
<para>
- Language-specific collations for the <literal>utf8</literal>
- character set are implemented only if the ordering with
+ MySQL implements language-specific collations for the
+ <literal>utf8</literal> character set only if the ordering with
<literal>utf8_unicode_ci</literal> does not work well for a
language. For example, <literal>utf8_unicode_ci</literal> works
fine for German and French, so there is no need to create
@@ -2765,7 +2765,7 @@
</para>
<para>
- <literal>utf8_general_ci</literal> is also satisfactory for both
+ <literal>utf8_general_ci</literal> also is satisfactory for both
German and French, except that
‘<literal>ß</literal>’ is equal to
‘<literal>s</literal>’, and not to
@@ -2908,8 +2908,7 @@
<listitem>
<para>
- <literal>latin1</literal> (cp1252 West European) collations
- (see the annotations about <quote>latin1</quote> below):
+ <literal>latin1</literal> (cp1252 West European) collations:
</para>
<itemizedlist>
@@ -2965,8 +2964,30 @@
</itemizedlist>
<para>
- <literal>latin1</literal> is the default character set. The
- <literal>latin1_swedish_ci</literal> collation is the
+ <literal>latin1</literal> is the default character set.
+ MySQL's <literal>latin1</literal> is the same as the Windows
+ <literal>cp1252</literal> character set. This means it is
+ the same as the official <literal>ISO 8859-1</literal> or
+ IANA (Internet Assigned Numbers Authority)
+ <literal>latin1</literal>, but IANA
+ <literal>latin1</literal> treats the code points between
+ <literal>0x80</literal> and <literal>0x9f</literal> as
+ <quote>undefined,</quote> whereas <literal>cp1252</literal>,
+ and therefore MySQL's <literal>latin1</literal>, assign
+ characters for those positions. For example,
+ <literal>0x80</literal> is the Euro sign. For the
+ <quote>undefined</quote> entries in
+ <literal>cp1252</literal>, MySQL translates
+ <literal>0x81</literal> to Unicode
+ <literal>0x0081</literal>, <literal>0x8d</literal> to
+ <literal>0x008d</literal>, <literal>0x8f</literal> to
+ <literal>0x008f</literal>, <literal>0x90</literal> to
+ <literal>0x0090</literal>, and <literal>0x9d</literal> to
+ <literal>0x009d</literal>.
+ </para>
+
+ <para>
+ The <literal>latin1_swedish_ci</literal> collation is the
default that probably is used by the majority of MySQL
customers. Although it is frequently said that it is based
on the Swedish/Finnish collation rules, there are Swedes and
@@ -3067,27 +3088,6 @@
</itemizedlist>
- <para>
- <emphasis>Annotations regarding
- <literal>latin1</literal>:</emphasis> MySQL's
- <literal>latin1</literal> is the same as the Windows
- <literal>cp1252</literal> character set. This means it is the
- same as the official <literal>ISO 8859-1</literal> or IANA
- (Internet Assigned Numbers Authority) <literal>latin1</literal>,
- but IANA <literal>latin1</literal> treats the code points
- between 0x80 and 0x9f as <quote>undefined,</quote> while
- <literal>cp1252</literal>, and therefore MySQL's
- <literal>latin1</literal>, assign characters for those
- positions. For example, 0x80 is the Euro sign. For the
- <quote>undefined</quote> entries in <literal>cp1252</literal>,
- MySQL translates <literal>0x81</literal> to Unicode
- <literal>0x0081</literal>, <literal>0x8d</literal> to
- <literal>0x008d</literal>, <literal>0x8f</literal> to
- <literal>0x008f</literal>, <literal>0x90</literal> to
- <literal>0x0090</literal>, and <literal>0x9d</literal> to
- <literal>0x009d</literal>.
- </para>
-
</section>
<section id="charset-ce-sets">
@@ -3095,9 +3095,9 @@
<title>&title-charset-ce-sets;</title>
<para>
- We also provide some support for character sets used in the
- Czech Republic, Slovakia, Hungary, Romania, Slovenia, Croatia,
- and Poland.
+ MySQL provides some support for character sets used in the Czech
+ Republic, Slovakia, Hungary, Romania, Slovenia, Croatia, and
+ Poland.
</para>
<itemizedlist>
@@ -3262,7 +3262,7 @@
<para>
South European and Middle Eastern character sets supported by
MySQL include Armenian, Arabic, Georgian, Greek, Hebrew, and
- Turkish:
+ Turkish.
</para>
<itemizedlist>
@@ -3409,8 +3409,7 @@
<para>
The Baltic character sets cover Estonian, Latvian, and
- Lithuanian languages. There are two Baltic character sets
- currently supported:
+ Lithuanian languages.
</para>
<itemizedlist>
@@ -3486,7 +3485,7 @@
<title>&title-charset-cyrillic-sets;</title>
<para>
- Here are the Cyrillic character sets and collations for use with
+ The Cyrillic character sets and collations are for use with
Belarusian, Bulgarian, Russian, and Ukrainian languages.
</para>
@@ -3617,7 +3616,9 @@
The Asian character sets that we support include Chinese,
Japanese, Korean, and Thai. These can be complicated. For
example, the Chinese sets must allow for thousands of different
- characters.
+ characters. See <xref linkend="charset-cp932"/>, for additional
+ information about the <literal>cp932</literal> and
+ <literal>sjis</literal> character sets.
</para>
<itemizedlist>
@@ -3938,11 +3939,10 @@
<para>
Some <literal>cp932</literal> characters have two
different code points, both of which convert to the same
- Unicode code point. So, when converting from Unicode back
- to <literal>cp932</literal>, one of the code points must
- be selected. For this <quote>round trip
- conversion,</quote> the rule recommended by Microsoft is
- used. (See
+ Unicode code point. When converting from Unicode back to
+ <literal>cp932</literal>, one of the code points must be
+ selected. For this <quote>round trip conversion,</quote>
+ the rule recommended by Microsoft is used. (See
<ulink url="http://support.microsoft.com/kb/170559/EN-US/"/>.)
</para>
@@ -3978,11 +3978,11 @@
</itemizedlist>
<para>
- Information about the Unicode values of
- <literal>cp932</literal> characters is given in the table
- shown at
- <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>.
- For <literal>cp932</literal> table entries with characters
+ The table shown at
+ <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>
+ provides information about the Unicode values of
+ <literal>cp932</literal> characters. For
+ <literal>cp932</literal> table entries with characters
under which a four-digit number appears, the number
represents the corresponding Unicode
(<literal>ucs2</literal>) encoding. For table entries with
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r837 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 15 Jan |
