BMS Starter Pack 2009 (redistributed)
- This package was exhibited for about 2 years from June , and it stopped by bad condition of
bms.ms. This is one of the most high-quality BMS starter pack. - BMS charts included in this package are wonderful. In particular, about appended charts for Double-Play mode.
JavaScript vs “Surrogate Pairs and Ideographic Variation Sequence”
'0123456789'.length === 10;'𝟘𝟙𝟚𝟛𝟜𝟝𝟞𝟟𝟠𝟡'.length === 20;
Thus, wrong example:
var hexadecimalNumericCharacterReferences = [], i = 0, codePoint = 0;while (i < String.length) {codePoint = String.charCodeAt(i);hexadecimalNumericCharacterReferences.push('&#x' + codePoint.toString(16).toUpperCase() + ';');i += 1;}
- The contents in this hexadecimalNumericCharacterReferences Array:
- Case
'01': ['0', '1']- Case
'𝟘𝟙': ['�', '�', '�', '�']
- Case
This is not UTF-8 but CESU-8. In HTML5, surrogate blocks (U+D800 - U+DFFF) are replaced to �. In application/xhtml+xml, XML parse error is caused by surrogate area. But we can correct this easily.
if (!String.prototype.codePointAt) {/* Polyfill; */}var hexadecimalNumericCharacterReferences = [], i = 0, codePoint = 0;while (i < String.length) {/*codePoint = String.charCodeAt(i);*/codePoint = String.codePointAt(i);hexadecimalNumericCharacterReferences.push('&#x' + codePoint.toString(16).toUpperCase() + ';');/*i += 1;*/i += (codePoint < 0xFFFF) ? 1 : 2;}
If text editors use WSH, IE10+ users can use polyfill. (E.g., JScript macros on EmEditor, Mery, Sakura Editor, and more.)
- Case
'𝟘𝟙': ['𝟘', '𝟙']- Case
'葛󠄁飾区': ['葛', '󠄁', '飾', '区']// 葛󠄁- Case
'葛󠄀城市': ['葛', '󠄀', '城', '市']// 葛󠄀- Case
'🎹💢': ['🎹', '💢']
My anxiety about the decimal numeric character reference
- x-sjis:
- Netscape Navigator 2.0 (18 September, 1995) or later
- Shift_JIS:
- Internet Explorer 3.0 (13 August, 1996) or later; limited to Japanese version? or "x-sjis"?
- Netscape Navigator 3.0 (19 August, 1996) or later
- Unicode:
- Netscape Navigator 4.0 (11 June, 1997) or later
- Internet Explorer 4.0 (30 September, 1997) or later
- Opera 6.00 (29 November, 2001) or later
- UTF-8 Test Page
- Hexadecimal numeric character reference:
- Internet Explorer 5.0 (18 March, 1999) or later // Windows 98SE has IE5 by default
- Netscape 6.0 (14 November, 2000) or later
- Opera 6.00 (29 November, 2001) or later (?)
- Decimal numeric character reference:
-
ユニコード番号による数値文字参照(
가の形)Microsoft Internet Explorer 4以上や Netscape Navigator 4以上では、numeric character references(数値文字参照、例えば
AでASCIIコード65(10進数表記)の文字である"A"を表わす)使用時に、UNICODE番号を使用できます。さらに、Internet Explorerでは、エンコードが日本語の時でもハングルを同時表示できます。IE4/NN4 were supporting that certainly.
IE/NN 3.x were supporting that partially?:
動作環境： IE3.0，Netscape3.0(Windows) IE4.5，Netscape4.5(Macintosh)以上で確認済み
Internet Explorer 3やNetscape Navigator 3では文字参照がShift_JISのコードポイントってことを知らないヤツってナンなの？ゆとり？
Browsers in those days probably knows only the character sets of Latin-1. Therefore when an HTML page is encoded by Shift_JIS, the character of Shift_JIS would be referred to by numbers after
Ā... maybe.If my above-mentioned supposition is right, maybe this is dangerous.
Perhaps if Shift_JIS encoded html, IE/NN 3.x parse NCRed "日本語" (U+65E5, U+672C, U+8A9E)
- not
- "
日本語" - but
- "
鏺陻質"
In 21st century browse, "
鏺陻質" is as "鏺陻質" (U+93FA, U+967B, U+8CEA).Backward compatibility was lost already. I think that the cord point of Unicode would rather be transmitted correctly than a document is altered by an ignorant browser dishonestly. I'd always use hexadecimal numeric character reference from now on.