stanford-oval/wikipedia huggingface dataset:
海綿寶寶：海陸大出擊
制作

2004年《海绵宝宝历险记》问世后，制片人朱莉亚·皮斯特（）说拍续集不太可能了，尽管影片的票房表现不俗。2009年接受《数码间谍》采访时，《海绵宝宝》的编剧兼执行制片人保罗·提比被问到续集的可能性，他说：“我认为他们已经在探讨这件事了，但我还没有签下任何合约。感觉我们已经降了太多的故事，《海绵宝宝》以这种11分钟的短片形式呈现非常好。”他进一步表示，再做一部电影是“巨大的挑战”。然而，提比否认续集不可能出现，表示：“我没有说过不会，但我不知道这会不会成为又一部作品。”2010年，尼克国际儿童频道据称已接触节目原创，商讨创作又一部改编电影的事宜。电视台一直希望和派拉蒙影业合作，发行另一部《海绵宝宝》电影，让连续剧从不断下降的收视率中重振雄风。然而，内部分歧推迟了合作。
2011年3月4日，《洛杉矶时报》撰文率先报道派拉蒙“另一部《海绵宝宝》电影”在开发中。几个月后的7月份，派拉蒙组建旗下全新的动画部门派拉蒙动画（英语：），紧随2011年计算机动画《兰戈》票房和口碑双丰收之后，而后来在2012年，梦工厂动画公司和派拉蒙的发行合约高满，梦工厂结束合作。派拉蒙总裁兼首席执行官菲利普·道曼（英语：）和尼克国际儿童频道母公司维亚康姆于2012年2月28日正式宣布续集在开发中，定于2014年上映，表示“我们会在2014年末发行《海绵宝宝》大电影”。道曼补充道，影片“会启动或纳入我们开启新动画尝试的电影作品”。尼克国际儿童频道希望影片的海外票房超越2004年作品，便不断增加全球上映范围。他表示：“这会继续推动《海绵宝宝》步向国际化”。
2014年6月10日，制作宣布开始，制作名称定为《海绵宝宝历险记2》（），而部分行业出版物称本片为《海绵宝宝2》（）。影片执行制片人由连续剧作者史蒂芬·海伦伯格担任。2004年《海绵宝宝历险记》上映后，他辞任了节目的节目制作人（英语：）。他不再参与节目的日常创作或播映工作，但会评价每一集并提出建议。然而，2012年接受托马斯·弗朗西斯·威尔逊采访时，海伦伯格声称他协助影片的制作。2013年年末，提比在Twitter上透露“史蒂芬（海伦伯格）和我一同写新电影的剧本，他每天都到片厂和我们工作。”影片将于2014年11月杀青。影片制作收官后，海伦伯格重新担任节目的执行制作人，如今有更多的创意投入，频繁参与剧组会议。
制作 > 选角

系列和2004年前作的经典角色悉数回归。2013年8月，的选角导演开始为真人动画场景的临时演员举行选角面试。2013年9月21日，据报西班牙演员安东尼奥·班德拉斯为选为真人角色海盗阿成的演员。
制作 > 动画

影片的动画由韩国的草图韩国（英语：）负责。创意总监文森特·沃勒（）表示：“我们正让动画变得了不起”。续集和前作一样，融合传统动画和真人动画，同时采用由澳大利亚墨尔本的处理的计算机生成动画。此前曾在《海绵宝宝历险记》中担任角色设计和首席故事分镜师（英语：）的薛尔曼·科恩（英语：）在续集中回归，2005年，他曾离开节目。连续剧作画监督汤姆·安美（英语：）和阿兰·斯马特（英语：）创作影片的曝光表（英语：）。影片的大部分角色设定组员都来自连续剧。
2012年，派拉蒙为即将上映的影片举行推介会时，影片首次以“CGI类动画”“3D长片”的身份展出。奥兰多尼克国际度假村（英语：）于2013年初上映3D短片《海绵宝宝4D：营救大果冻（英语：）》后，高管们曾谈过要将3D体视学永远流传下去。导演提比在Twitter上被问到电影将会采用什么动画技术时，回答道：“我不想透露任何事，但（它）大部分是2D。”
2014年3月，派拉蒙在美国全国影院业主协会（英语：）电影展上放映影片的真人动画片段。新闻网站报道影片采用了计算机生成动画（CGI），其中互联网电影资料库的编辑评论道：“派拉蒙宣布将有一部新的《海绵宝宝》电影时，就有了这（像《海绵宝宝》的其他化身一样）会是一部动画片。今晚展出的小片段反而暗示它看上去类似于《鼠来宝》、《瑜珈熊》和《蓝精灵》等作品的CGI、真人动画杂交品。”在CraveOnline（英语：）发布的一篇文章中，作者爱德华·道格拉斯（）写道：“CGI动画看起来很怪异”。菲利普·道曼解释称，CGI元素为了让角色“活灵活现，获得另一种提升”。
制作 > 摄制

影片的真人实拍（英语：）镜头由迈克·米歇尔（英语：）执导。摄制于2013年9月30日启动，持续到2013年11月5日，在乔治亚州萨凡纳和泰比岛（英语：）等多个地点取景。7月11日，萨凡纳电影服务办公室（）率先宣布影片将会在萨凡纳拍摄真人实拍镜头40天。办公室地方专员威尔·哈马尔格伦（）表示影片将会给市的经济贡献800万美元，包括至少5600次酒店夜宿。
影片的真人实拍镜头在乔治亚州萨凡纳多地取景，包括市区（上）和码头（下）。
2013年9月30日，因杰伊·雪夫（）被解雇，影片的制作启动被中断。根据萨凡纳休闲服务部门主管乔·希鲁斯（）的备忘录，雪夫因“没能妥善规范和管理影片的安排”而被解雇。雪夫被指控对电影摄制一无所知，还被当地居民投诉扰民。而另一篇报道则指雪夫被解雇的原因，是派拉蒙和萨凡纳电影办公室就当地企业与派拉蒙协商拍摄期间可能有的商业损失存在分歧。
影片搭景（英语：）准备期间，剧组沿着布劳顿街（）的店面喷漆，仿造名叫“盐浅滩”（）的“海滩社群”。雪夫表示，“他们试着把它包装成海边的样子。”位于布劳顿街，隶属于萨凡纳艺术设计学院的珍图书馆与信托剧院（）被改造成海事博物馆。早在2013年8月，派拉蒙接触学院，商讨将图书馆用作取景地。学院同意后，制片方的艺术部开始改造被选作去景点的大楼。摄制期间，大楼继续向学生开放，而信托会冠名的“SCAD”仍然保持不变。其他机构，例如花店（英语：）、便利商店和咖啡店分别改成冲浪、牛乳糖和浮标店。雪夫表示：“这种改变是临时的，所有建筑在拍摄完成后会恢复成原本的颜色。”
10月9日，市区摄制启动，布莱顿街蒙哥马利街（）和哈伯斯罕街（）部分路段关闭到10月18日。早在10月9日，当地居民便收到剧组散发的详述拍摄可能会对他们造成的不便的黄色传单。饰演海盗的演员安东尼奥·班德拉斯在一艘带轮子的海盗船上拍摄追车戏。有一次，一位剧组成员意外造成市中心一座大楼受损，将一名女士送到了坎德勒医院（）。电影服务办公室的威廉·哈马格伦（）表示派拉蒙获允许在某些封闭地段使用机动车，但许可证并不延伸到行车道。
10月18日，市中心拍摄结束。当天还举行了抽奖活动，市长埃德娜·杰克逊（）宣布了获奖者。奖品包括海绵宝宝主题派对、自行车、马歇尔度假屋独家、萨凡纳小餐馆晚餐、礼品券和一台60吋电视。市中心的拍摄过后，取景地企业对制作团队的评价褒贬不一。企业主认为，选择用来拍戏的10月份是“布莱顿商人的大日子”。有些商人建议将2月、7月或8月定为拍摄的首选时间。
泰比岛的拍摄于10月21日启动。电影制片人获准在泰比岛市政厅举办完会议后拍戏，而企业和居民对拍戏可能造成的影响表示担忧，同时还担心威胁海龟的安全。乐队枪与玫瑰乐手史莱许在泰比岛的拍摄现场被人看到，尽管他在成片中没有出场。后来剧组带上骑自行车的临时演员，移师斯特兰德大街（）拍摄追车戏。
電影歌曲

| 0 | 1 | 2 | 3 | 4 | 5 |
| --- | --- | --- | --- | --- | --- |
| 曲別 | 歌曲名稱 | 作詞 | 作曲 | 演唱者 | 備註 |

| 主題曲  | Squeeze Me | 待查 | 待查 | N*E*R*D（英语：） |  |

在本劇中出現The good, the bad and the ugly（黃昏三鏢客）的經典電影配樂：Ecstasy of Gold為橋段插曲。
發行 > 評價

爛番茄新鮮度80%，基於100條評論，平均分為6.5/10，但觀眾評價僅有54%；而在Metacritic上得到62分，代表「普遍好評」，IMDB上得6分，收穫多數好評，但普遍不受觀眾青睞。
發行 > 票房

中国大陆收获5610万人民币。
| 0 | 1 | 2 |
| --- | --- | --- |

| 上一届：  《美国狙击手》 |  2015年美国周末票房冠军   第6週 | 下一届： 《格雷的五十道陰影》   |
续集

条目：海綿寶寶：奔跑吧
2015年2月，派拉蒙全球发行营销总裁梅根·科里森（）在访谈中谈到电影不俗的票房，指出第三部电影的可能性是“很好的赌注”。在另一个采访中，派拉蒙副主席罗伯·摩尔（）表示“希望拍另一部电影不用花十年”。2015年4月30日，维亚康姆在Twitter上宣布第三部《海绵宝宝》电影正在开发中。2015年8月3日，文森特·沃勒在Twitter上证实续集进入前期制作，同时保罗·提比也确认回归担任导演，并和凯尔·麦卡洛克（英语：）编剧。2015年11月，据宣布影片定档2019年2月8日，但档期之后推迟到2019年3月。2015年11月11日，沃勒在Twitter证实影片大部分采用传统上的计算机生成动画加真人实拍镜头。编剧乔纳森·阿尔贝和格伦·伯杰（英语：）2016年1月在采访中表示正创作第三部《海绵宝宝》电影。2016年4月，分镜画家鲍勃·坎普（英语：）表示漫画家约翰·克里法拉西（英语：）正在开发一部提前于本片上映的新《莱恩与史丁比秀（英语：）》动画，然而克里法拉西在Twitter上否认在制作动画。2017年3月在电影展上，据宣布影片推迟到2019年8月2日上映。2017年3月28日，雅虎电影在它的Twitter上报道称影片将成为《海绵宝宝》的终篇，现任节目制作人沃勒暗示这不过是一部占位作品。之後改於2021年上映。
外部連結

海綿寶寶：海陸大出擊的Facebook專頁
互联网电影数据库（IMDb）上《海綿寶寶：海陸大出擊》的资料（英文）
Box Office Mojo上《海綿寶寶：海陸大出擊》的資料（英文）
爛番茄上《海綿寶寶：海陸大出擊》的資料（英文）
Metacritic上《海綿寶寶：海陸大出擊》的資料（英文）
AllMovie上《海綿寶寶：海陸大出擊》的资料（英文）
Yahoo奇摩電影上《海綿寶寶：海陸大出擊》的資料（繁體中文）
開眼電影網上《海綿寶寶：海陸大出擊》的資料（繁體中文）
豆瓣电影上《海綿寶寶歷險記：海綿出水》的資料 （简体中文）
时光网上《海綿寶寶歷險記：海綿出水》的資料（简体中文）
奧布霍韋

50°50′56″N 33°1′26″E﻿ / ﻿50.84889°N 33.02389°E﻿ / 50.84889; 33.02389
奧布霍韋（烏克蘭語：），是烏克蘭北部的村莊，隸屬切爾尼希夫州的普里盧基區。該村面積0.51平方公里，海拔高度175米，2001年人口181，人口密度每平方公里353.5人。
參考資料

Погода в селі Обухове （页面存档备份，存于）
UTF-8

| --- | --- |
语言: 國際
标准: Unicode
分类: EASCII 变长编码 Unicode转换格式
拓展自: US-ASCII
变换/编码: ISO 10646 (Unicode)
前用: UTF-1
 论 编
顯示了谷歌所記錄的2001年至2012年主要編碼方法的使用情況，2008年，UTF-8的使用率超过所有其他编码方式，在2012年超过所有网页的60％。其中曲线包括所有仅包含ASCII字符的网页，无论元数据中声明如何。
UTF-8（）是一種針對Unicode的可變長度字元編碼，也是一种前缀码。它可以用一至四个字节对Unicode字符集中的所有有效编码点进行编码，属于Unicode标准的一部分，最初由肯·汤普逊和罗布·派克提出。由于较小值的编码点一般使用频率较高，直接使用Unicode编码效率低下，大量浪费内存空间。UTF-8就是为了解决向后兼容ASCII码而设计，Unicode中前128个字符，使用与ASCII码相同的二进制值的单个字节进行编码，而且字面与ASCII码的字面一一对应，這使得原來處理ASCII字元的軟體無須或只須做少部份修改，即可繼續使用。因此，它逐漸成為電子郵件、網頁及其他儲存或傳送文字優先採用的編碼方式。
自2009年以来，UTF-8一直是万维网的最主要的编码形式（对所有，而不仅是Unicode范围内的编码）（并由WHATWG宣布为强制性的“适用于所有事物()”，截止到2019年11月， 在所有网页中，UTF-8编码应用率高达94.3%（其中一些仅是ASCII编码，因为它是UTF-8的子集），而在排名最高的1000个网页中占96％。 第二热门的多字节编码方式Shift JIS和GB 2312分别具有0.3％和0.2％的占有率。Internet邮件联盟（）建议所有电子邮件程序都能够使用UTF-8展示和创建邮件， W3C建议UTF-8作为XML文件和HTML文件的默认编码方式。網際網路工程工作小組（IETF）要求所有網際網路協議都必須支持UTF-8編碼。互聯網郵件聯盟（IMC）建議所有電子郵件軟件都支持UTF-8編碼。
歷史

1992年初，為建立良好的位元組串編碼系統以供多位元組字元集使用，開始了一個正式的研究。ISO/IEC 10646的初稿中有一個非必須的附錄，名為UTF。當中包含了一個供32位元的字元使用的位元組串編碼系統。這個編碼方式的性能並不令人滿意，但它提出了將0-127的範圍保留給ASCII以相容舊系統的概念。
1992年7月，X/Open委員會XoJIG開始尋求一個較佳的編碼系統。Unix系統實驗室（USL）的Dave Prosser為此提出了一個編碼系統的建議。它具備可更快速實作的特性，並引入一項新的改進。其中，7位元的ASCII符號只代表原來的意思，所有多位元組序列則會包含第8位元的符號，也就是所謂的最高有效位元。
1992年8月，這個建議由IBMX/Open的代表流傳到一些感興趣的團體。與此同時，貝爾實驗室九號計畫作業系統工作小組的肯·汤普逊對這編碼系統作出重大的修改，讓編碼可以自我同步，使得不必從字串的開首讀取，也能找出字符間的分界。1992年9月2日，肯·汤普逊和羅勃·派克一起在美國新澤西州一架餐車的餐桌墊上描繪出此設計的要點。接下來的日子，Pike及汤普逊將它實現，並將這編碼系統完全應用在九號計畫當中，及後他將有關成果回饋X/Open。
1993年1月25-29日的在聖地牙哥舉行的USENIX會議首次正式介紹UTF-8。
自1996年起，微軟的CAB（MS Cabinet）規格在UTF-8標準正式落實前就明確容許在任何地方使用UTF-8編碼系統。但有關的編碼器實際上從來沒有實作這方面的規格。
结构

UTF-8使用一至六個位元組為每個字符編碼（儘管如此，2003年11月UTF-8被RFC 3629重新規範，只能使用原来Unicode定義的區域，U+0000到U+10FFFF，也就是說最多四個字節）：
128個US-ASCII字符只需一個位元組編碼（Unicode範圍由U+0000至U+007F）。
帶有附加符号的拉丁文、希臘文、西里爾字母、亞美尼亞語、希伯來文、阿拉伯文、敘利亞文及它拿字母則需要兩個位元組編碼（Unicode範圍由U+0080至U+07FF）。
其他基本多文種平面（BMP）中的字元（這包含了大部分常用字，如大部分的漢字）使用三個位元組編碼（Unicode範圍由U+0800至U+FFFF）。
其他極少使用的Unicode 輔助平面的字元使用四至六位元組編碼（Unicode範圍由U+10000至U+1FFFFF使用四字節，Unicode範圍由U+200000至U+3FFFFFF使用五字節，Unicode範圍由U+4000000至U+7FFFFFFF使用六字節）。
對上述提及的第四種字元而言，UTF-8使用四至六個位元組來編碼似乎太耗費資源了。但UTF-8對所有常用的字元都可以用三個位元組表示，而且它的另一種選擇，UTF-16編碼，對前述的第四種字符同樣需要四個位元組來編碼，所以要決定UTF-8或UTF-16哪種編碼比較有效率，還要視所使用的字元的分佈範圍而定。不過，如果使用一些傳統的壓縮系統，比如DEFLATE，則這些不同編碼系統間的的差異就變得微不足道了。若顧及傳統壓縮算法在壓縮較短文字上的效果不大，可以考慮使用Unicode標準壓縮格式（SCSU）。
描述

目前有好幾份關於UTF-8詳細規格的文件，但這些文件在定義上有些許的不同：
RFC 3629 / STD 63（2003），這份文件制定了UTF-8是標準的網際網路協議元素
第四版，The Unicode Standard，§3.9－§3.10（2003）
ISO/IEC 10646-1:2000附加文件D（2000）
它們取代了以下那些被淘汰的定義：
ISO/IEC 10646-1:1993修正案2／附加文件R（1996）
第二版，The Unicode Standard，附錄A（1996）
RFC 2044（1996）
RFC 2279（1998）
第三版，The Unicode Standard，§2.3（2000）及勘誤表#1：UTF-8 Shortest Form（2000）
Unicode Standard附加文件#27: Unicode 3.1（2001）
事實上，所有定義的基本原理都是相同的，它們之間最主要的不同是支持的字元範圍及無效輸入的處理方法。
Unicode字元的位元被分割為數個部分，並分配到UTF-8的位元組串中較低的位元的位置。在U+0080的以下字元都使用內含其字元的單位元組編碼。這些編碼正好對應7位元的ASCII字符。在其他情況，有可能需要多達4個字元組來表示一個字元。這些多位元組的最高有效位元會設定成1，以防止與7位元的ASCII字符混淆，並保持標準的位元組主導字串運作順利。
| 代碼範圍 十六進制 | 標量值（scalar value） 二進制 | UTF-8 二進制／十六進制 | 註釋 |
| --- | --- | --- | --- |
| 000000 - 00007F 128個代碼 | 00000000 00000000 0zzzzzzz | 0zzzzzzz（00-7F） | ASCII字元範圍，位元組由零開始 |
| 000000 - 00007F 128個代碼 | 七個z | 七個z | ASCII字元範圍，位元組由零開始 |
| 000080 - 0007FF 1920個代碼 | 00000000 00000yyy yyzzzzzz | 110yyyyy（C0-DF） 10zzzzzz（80-BF） | 第一個位元組由110開始，接著的位元組由10開始 |
| 000080 - 0007FF 1920個代碼 | 三個y；二個y；六個z | 五個y；六個z | 第一個位元組由110開始，接著的位元組由10開始 |
| 000800 - 00D7FF  00E000 - 00FFFF 61440個代碼   | 00000000 xxxxyyyy yyzzzzzz | 1110xxxx（E0-EF） 10yyyyyy 10zzzzzz | 第一個位元組由1110開始，接著的位元組由10開始 |
| 000800 - 00D7FF  00E000 - 00FFFF 61440個代碼   | 四個x；四個y；二個y；六個z | 四個x；六個y；六個z | 第一個位元組由1110開始，接著的位元組由10開始 |
| 010000 - 10FFFF 1048576個代碼 | 000wwwxx xxxxyyyy yyzzzzzz | 11110www（F0-F7） 10xxxxxx 10yyyyyy 10zzzzzz | 将由11110開始，接著的位元組由10開始 |
| 010000 - 10FFFF 1048576個代碼 | 三個w；二個x；四個x；四個y；二個y；六個z | 三個w；六個x；六個y；六個z | 将由11110開始，接著的位元組由10開始 |
例如，希伯来语字母aleph（א）的Unicode代码是U+05D0，按照以下方法改成UTF-8：
它属于U+0080到U+07FF区域，这个表说明它使用双字节，110yyyyy 10zzzzzz.
十六进制的0x05D0换算成二进制就是101-1101-0000.
这11位数按顺序放入"y"部分和"z"部分：11010111 10010000.
最后结果就是双字节，用十六进制写起来就是0xD7 0x90，这就是这个字符aleph（א）的UTF-8编码。
所以开始的128个字元（US-ASCII）只需一字节，接下来的1920个字符需要双字节编码，包括带附加符号的拉丁字母，希腊字母，西里尔字母，科普特语字母，亚美尼亚语字母，希伯来文字母和阿拉伯字母的字元。基本多文種平面中其余的字元使用三个字节，剩余字符使用四个字节。
根据这种方式可以处理更大数量的字元。原来的规范允许长达6字节的序列，可以覆盖到31位元（通用字符集原来的极限）。尽管如此，2003年11月UTF-8被RFC 3629重新规范，能使用原来Unicode定义的区域，U+0000到U+10FFFF。根据这些规范，以下字节值将无法出现在合法UTF-8序列中：
| 编码（二进制） | 编码（十六进制） | 注释 |
| --- | --- | --- |
| 1100000x | C0, C1 | 过长编码：双字节序列的头字节，但码点 <= 127 |
| 1111111x | FE, FF | 无法达到：7或8字节序列的头字节 |
| 111110xx 1111110x | F8, F9, FA, FB, FC, FD | 被RFC 3629规范：5或6字节序列的头字节 |
| 11110101 1111011x | F5, F6, F7 | 被RFC 3629规范：码点超过10FFFF的头字节 |
UTF-8编码字节含义

对于UTF-8编码中的任意字节B，如果B的第一位为0，则B独立的表示一个字符(ASCII码)；
如果B的第一位为1，第二位为0，则B为一个多字节字符中的一个字节(非ASCII字符)；
如果B的前两位为1，第三位为0，则B为两个字节表示的字符中的第一个字节；
如果B的前三位为1，第四位为0，则B为三个字节表示的字符中的第一个字节；
如果B的前四位为1，第五位为0，则B为四个字节表示的字符中的第一个字节；
因此，对UTF-8编码中的任意字节，根据第一位，可判断是否为ASCII字符；根据前二位，可判断该字节是否为一个字符编码的第一个字节；根据前四位（如果前两位均为1），可确定该字节为字符编码的第一个字节，并且可判断对应的字符由几个字节表示；根据前五位（如果前四位为1），可判断编码是否有错误或数据传输过程中是否有错误。
設計UTF-8的理由

UTF-8的設計有以下的多字元組序列的特質：
單位元組字符的最高有效位元永遠為0。
多位元組序列中的首個字元組的幾個最高有效位元決定了序列的長度。最高有效位為110的是2位元組序列，而1110的是三位元組序列，如此類推。
多位元組序列中其餘的位元組中的首兩個最高有效位元為10。
UTF-8的這些特質，保證了一個字符的字节序列不会包含在另一個字符的字节序列中。這確保了以位元組為基礎的部份字串比對（sub-string match）方法可以適用於在文字中搜尋字或詞。有些比較舊的可變長度8位元編碼（如Shift JIS）沒有這個特質，故字串比對的算法變得相當複雜。雖然這增加了UTF-8編碼的字串的信息冗餘，但是利多於弊。另外，資料壓縮並非Unicode的目的，所以不可混為一談。即使在傳送過程中有部份位元組因錯誤或干擾而完全遺失，還是有可能在下一個字符的起點重新同步，令受損範圍受到限制。
另一方面，由於其位元組序列設計，如果一個疑似為字符串的序列被驗證為UTF-8編碼，那麼我們可以有把握地說它是UTF-8字符串。一段兩位元組隨機序列碰巧為合法的UTF-8而非ASCII的機率為32分1。對於三位元組序列的機率為256分1，對更長的序列的機率就更低了。
UTF-8的編碼方式

UTF-8是UNICODE的一種變長度的編碼表達方式一般UNICODE為雙位元組（指UCS2），它由肯·汤普逊（）于1992年建立，現在已經標準化為RFC 3629。UTF-8就是以8位为单元对UCS进行编码，而UTF-8不使用大尾序和小尾序的形式，每個使用UTF-8儲存的字符，除了第一個字節外，其餘字節的頭兩個位元都是以"10"開始，使文字處理器能夠較快地找出每個字符的開始位置。
但為了與以前的ASCII碼相容（ASCII為一個位元組），因此UTF-8選擇了使用可變長度字節來儲存Unicode：
（注意：不论是Unicode (Table 3.7) ，还是ISO 10646 (10.2 UTF-8) ，目前都只规定了最高码位是0x10FFFF的字元的编码。下表中表示大于0x10FFFF的UTF-8编码是不符合标准的。）
| 码点的位数 | 码点起值 | 码点终值 | 字节序列 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|   7 | U+0000 | U+007F | 1 | 0xxxxxxx |  |  |  |  |  |
| 11 | U+0080 | U+07FF | 2 | 110xxxxx | 10xxxxxx |  |  |  |  |
| 16 | U+0800 | U+FFFF | 3 | 1110xxxx | 10xxxxxx | 10xxxxxx |  |  |  |
| 21 | U+10000 | U+1FFFFF | 4 | 11110xxx | 10xxxxxx | 10xxxxxx | 10xxxxxx |  |  |
| 26 | U+200000 | U+3FFFFFF | 5 | 111110xx | 10xxxxxx | 10xxxxxx | 10xxxxxx | 10xxxxxx |  |
| 31 | U+4000000 | U+7FFFFFFF | 6 | 1111110x | 10xxxxxx | 10xxxxxx | 10xxxxxx | 10xxxxxx | 10xxxxxx |
在ASCII碼的範圍，用一個位元組表示，超出ASCII碼的範圍就用位元組表示，這就形成了我們上面看到的UTF-8的表示方法，這樣的好處是當UNICODE文件中有ASCII碼時，儲存的文件都為一個位元組，所以就是普通的ASCII文件無異，讀取的時候也是如此，所以能與以前的ASCII文件相容。
大於ASCII碼的，就會由上面的第一位元組的前幾位表示該unicode字元的長度，比如110xxxxx前三位的二進位表示告訴我們這是個2BYTE的UNICODE字元；1110xxxx是個三位的UNICODE字元，依此類推；xxx的位置由字符編碼數的二進製表示的位填入。越靠右的x具有越少的特殊意義。只用最短的那個足夠表達一個字符編碼數的多字節串。注意在多字節串中，第一個字節的開頭"1"的數目就是整個串中字節的數目。
ASCII字母繼續使用1字節儲存，重音文字、希臘字母或西里爾字母等使用2字節來儲存，而常用的漢字就要使用3字節。辅助平面字元則使用4字節。
在UTF-8+BOM格式文件的開首，很多時都放置一個U+FEFF字符（UTF-8以EF,BB,BF代表），以顯示這個文字檔案是以UTF-8編碼。
UTF-8的特性

|  | UTF-8 |
| --- | --- |
最小码位: 0000
最大码位: 10FFFF
每字节所占位数: 8 bits
Byte order: N/A
每个字符最小字节数: 1
每个字符最大字节数: 4
UCS字符U+0000到U+007F（ASCII）被編碼為字節0x00到0x7F（ASCII兼容），這也意味著只包含7位ASCII字符的文件在ASCII和UTF-8兩種編碼方式下是一樣的。
所有>U+007F的UCS字符被編碼為一個多個字節的串，每個字節都有標記位集。因此，ASCII字節（0x00-0x7F）不可能作為任何其他字符的一部分。
表示非ASCII字符的多字節串的第一個字節總是在0xC0到0xFD的範圍裡，並指出這個字符包含多少個字節。多字節串的其餘字節都在0x80到0xBF範圍裡，這使得重新同步非常容易，並使編碼無國界，且很少受丟失字節的影響。
可以編入所有可能的231個UCS代碼
UTF-8編碼字符理論上可以最多到6個字節長，然而16位BMP字符最多只用到3字節長。
Bigendian UCS-4字節串的排列順序是預定的。
字節0xFE和0xFF在UTF-8編碼中從未用到，同時，UTF-8以位元組為編碼單元，它的位元組順序在所有系統中都是一様的，没有位元組序的問題，也因此它實際上并不需要BOM。
與UTF-16或其他Unicode編碼相比，對於不支持Unicode和XML的系統，UTF-8更不容易造成問題。
UTF-8編碼的優點

总体来说，在Unicode字符串中不可能由码点数量决定显示它所需要的长度，或者显示字符串之后在文本缓冲区中光标应该放置的位置；组合字符、变宽字体、不可打印字符和从右至左的文字都是其归因。
所以尽管在UTF-8字符串中字元数量与码点数量的关系比UTF-32更为复杂，在实际中很少会遇到有不同的情形。
更詳細的說，UTF-8編碼具有以下幾點優點：
ASCII是UTF-8的一个子集。因为一个纯ASCII字符串也是一个合法的UTF-8字符串，所以现存的ASCII文本不需要转换。为传统的扩展ASCII字符集设计的软件通常可以不经修改或很少修改就能与UTF-8一起使用。
使用标准的面向字节的排序例程对UTF-8排序将产生与基于Unicode代码点排序相同的结果。（尽管这有有限的有用性，因为在任何特定语言或文化下都不太可能有仍可接受的文字排列顺序。）
UTF-8和UTF-16都是可扩展标记语言文档的标准编码。所有其它编码都必须通过显式或文本声明来指定。（页面存档备份，存于）
任何面向字节的字符串搜索算法都可以用于UTF-8的数据（要输入仅由完整的UTF-8字符组成）。但是，对于包含字符记数的正则表达式或其它结构必须小心。
UTF-8字符串可以由一个简单的算法可靠地识别出来。就是，一个字符串在任何其它编码中表现为合法的UTF-8的可能性很低，并随字符串长度增长而减小。举例说，字元值C0,C1,F5至FF从来没有出现。为了更好的可靠性，可以使用正则表达式来统计非法过长和替代值（可以查看W3 FAQ: Multilingual Forms （页面存档备份，存于）上的验证UTF-8字符串的正则表达式）。
與UCS-2的比較：ASCII轉换成UCS-2，在編碼前插入一個0x0。用這些編碼，會含括一些控制符，比如"或 '/'，這在UNIX和一些C函數中，將會產生嚴重錯誤。因此可以肯定，UCS-2不適合作為Unicode的外部編碼，也因此誕生了UTF-8。
UTF-8 編碼的缺點 > 編寫不良的解析器

如果一个 UTF-8 解析器写得很差（并且与当前标准的版本不兼容），那么它接收到一些伪 UTF-8 时会将其转换成看似正确实则错误的 Unicode 输出。处理八位表示的校验例程可能遗漏一些信息。
UTF-8 編碼的缺點 > 不利于正则表达式检索

正则表达式可以进行很多高级的英文模糊检索。例如，[a-h]表示 a 到 h 间所有字母。
同样 GBK 编码的中文也可以这样利用正则表达式，比如在只知道一个字的读音而不知道怎么写的情况下，也可用正则表达式检索，因为 GBK 编码是按读音排序的。但是 Unicode 汉字不是按读音排序的，所以不利于用正则表达式检索。虽然正则表达式检索并未考虑中文的多音字，但是由于中文的多音字数量不多，不少多音字还是同音不同调类型的多音字，所以大多数情况下正则表达式检索是还可以接受的。不过 Unicode 汉字按部首排序，因此在只知道一個字的部首而不知道如何發音的情况下，UTF-8 可用正则表达式检索而 GBK 不行。
UTF-8 編碼的缺點 > 可能無法用舊的 C 語言函式庫讀寫

由於UTF-8在編碼中可能有著空字元（null character，U+0000），這會導致C語言函示庫以及其延伸的程式解析失敗，因為這些舊有的程式庫使用這個字元來標記字串的結束。然而，之所以說「可能」，是因為這個字元是控制字元，理論上不會出現在 XML 等純文字檔案中。當萬不得已要使用空字元的時候，可能的解決方法是考慮使用 Java 的變種UTF-8 ——使用 0xc0 0x80 來編碼空字元。
UTF-8 編碼的缺點 > 其他

UTF-8 的 ASCII 字元占用一个字节，比较节省空间，但是更多字元的 UTF-8 編碼佔用的空間就要多出1/2，特別是中文、日文和韓文（CJK）這樣的方塊文字，它们大多需要三个字节。
UTF-8的衍生物 > Windows

雖然不是標準，但許多Windows程序（包括Windows记事本）在UTF-8編碼的檔案的開首加入一段位元組串EF BB BF。這是位元組順序記號U+FEFF的UTF-8編碼結果。對於沒有預期要處理UTF-8的文字編輯器和瀏覽器會顯示成ISO-8859-1字符串ï»¿。
UTF-8的衍生物 > Posix系统

Posix系统明确不建议使用字节序掩码EF BB BF。因为很多文本文件期望以 “#!”（Shebang）开头指示要运行的程序。Linux系统选择使用Unicode规范形式Normalization Form C（NFC），即优先使用预组装字符（precomposed character）而非组合字符序列（combining character sequence）。
2002年9月发布的Red Hat Linux 8.0才开始正式把大多数区域设置的默认编码设为UTF-8。此前是各种语言的但字节编码为主。2004年9月SuSE Linux 9.1开始，缺省编码迁移为UTF-8。
字符串处理时，使用UTF-8或locale依赖的多字节编码情形，比使用C语言wchar_t的宽字符固定宽度编码，要慢1至2个数量级。
UTF-8的衍生物 > Java

在通常用法下，Java程序语言在通过InputStreamReader和OutputStreamWriter读取和写入串的时候支持标准UTF-8。但是，Java也支持一种非标准的变体UTF-8，供对象的序列化，Java本地界面和在class文件中的嵌入常数時使用的modified UTF-8。
UTF-8的衍生物 > Java > 變種UTF-8

标准和變種的UTF-8有两个不同点。第一，空字符（null character，U+0000）使用雙字节的0xc0 0x80，而不是单字节的0x00。这保证了在已编码字串中没有嵌入空字节。因为C语言等语言程序中，单字节空字符是用来标志字串结尾的。当已编码字串放到这样的语言中處理，一个嵌入的空字符将把字串一刀两断。
第二个不同点是基本多文種平面之外字符的编码的方法。在标准UTF-8中，这些字符使用4字节形式编码，而在修正的UTF-8中，这些字符和UTF-16一样首先表示为代理对（surrogate pairs），然后再像CESU-8那样按照代理对分别编码。这样修正的原因更是微妙。Java中的字符为16位长，因此一些Unicode字符需要两个Java字符来表示。语言的这个性质蓋過了Unicode的增补平面的要求。尽管如此，為了要保持良好的向后兼容、要改變也不容易了。这个修正的编码系統保证了一个已编码字串可以一次编为一个UTF-16码，而不是一次一个Unicode码点。不幸的是，这也意味着UTF-8中需要4字节的字符在變種UTF-8中变成需要6字节。
因为變種UTF-8并不是UTF-8，所以用户在交换信息和使用互联网的时候需要特别注意不要误把變種UTF-8當成UTF-8数据。
UTF-8的衍生物 > Mac OS X

参见：统一码等价性
Mac OS X操作系统使用統一碼正規形式中的分解式標準等價（canonically decomposed Unicode），在文件系统中使用UTF-8编码进行文件命名，這做法通常被称为UTF-8-MAC。分解式標準等價中，预组合字符是被禁止使用的，必须以组合字符取代。
这种方法使分类变得非常简单，但是会搞混那些使用预组合字符为标准、组合字符用来显示特殊字符的软件。Mac系统的这种NFD数据是統一碼正規形式（Unicode normalization）的一种格式。而其他系统，包括Windows和Linux，使用統一碼规范的NFC形式，也是W3C标准使用的形式。所以通常NFD数据必须转换成NFC才能被其他平台或者网络使用。
苹果开发者专区有关于此问题的讨论：Apple Q&A 1173 （页面存档备份，存于）。
UTF-8的衍生物 > MySQL

MySQL字符编码集中有两套UTF-8编码实现：“utf8”和“utf8mb4”，其中“utf8”是一个字最多占据3字节空间的编码实现；而“utf8mb4”则是一个字最多占据4字节空间的编码实现，也就是UTF-8的完整实现。这是由于MySQL在4.1版本开始支持UTF-8编码（当时参考UTF-8草案版本为RFC 2279）时，为2003年，并且在同年9月限制了其实现的UTF-8编码的空间占用最多为3字节，而UTF-8正式形成标准化文档（RFC 3629）是其之后。限制UTF-8编码实现的编码空间占用一般被认为是考虑到数据库文件设计的兼容性和读取最优化，但实际上并没有达到目的，而且在UTF-8编码开始出现需要存入非基本多文种平面的Unicode字符（例如emoji字符）时导致无法存入（由于3字节的实现只能存入基本多文种平面内的字符）。直到2010年在5.5版本推出“utf8mb4”来代替、“utf8”重命名为“utf8mb3”并调整“utf8”为“utf8mb3”的别名，并不建议使用旧“utf8”编码，以此修正遗留问题。
参閱

Alt码
ASCII
位元組順序記號
Comparison of email clients#Features
Comparison of Unicode encodings
Character encodings in HTML
ISO/IEC 8859
GB18030
iconv
Unicode and e-mail
Unicode and HTML
通用字符集
UTF-16
UTF-9和UTF-18
寬字元
外部連結

RFC 3629：UTF-8標準
RFC 2277：IETF policy on character sets and languages
Rob Pike tells the story of UTF-8's creation（页面存档备份，存于）
Original UTF-8 paper
UTF-8 test pages by University Hannover （页面存档备份，存于） and the World Wide Web Consortium （页面存档备份，存于）
Unix/Linux: UTF-8和Unicode的常見問題集（页面存档备份，存于），Linux Unicode HOWTO，UTF-8 and Gentoo （页面存档备份，存于）
The Unicode/UTF-8-character table （页面存档备份，存于） displays UTF-8 in a variety of formats（with Unicode and HTML encoding information）
Online Tool for URL encoding/decoding according to RFC 3986 and RFC 3629（JavaScript，GPL）
UTF-8測試頁
UTF-8 （页面存档备份，存于）
2047年香港前途問題

2047年香港前途問題是因應《香港特別行政區基本法》第5條所指“香港特别行政区不实行社会主义制度和政策，保持原有的资本主义制度和生活方式，五十年不变”和《中英聯合聲明》中有關條文。香港本土派等政治人物曾經提出該理論，香港特別行政區政府則反對2047年會有問題。
背景

中国是信守自己的诺言的。我们讲“五十年”，不是随随便便，感情冲动而讲的，是考虑到中国的现实和发展的需要。如果说本世纪内我们需要实行开放政策，那么在下世纪的前五十年内中国要接近发达国家的水平，也不能离开这个政策。
“
”
雖然中華民國擁有清朝和英國簽署的《南京條約》、《北京條約》和《展拓香港界址專條》，於1984年，英國選擇和中華人民共和國簽署中英聯合聲明承諾英方於1997年7月1日移交香港主權給中華人民共和國。根據中英联合声明第三条及附件一，香港於1997年7月1日後將按照《基本法》確保香港實行一國兩制和資本主義制度，並擁有「港人治港，高度自治」的權利，而且社會制度和生活方式保持50年不變。
基本法第5条规定“香港特别行政区不实行社会主义制度和政策，保持原有的资本主义制度和生活方式，五十年不变。”如此香港50年後會否繼續實行一國兩制與資本主義制度，擁有「港人治港，高度自治」權利就成為問題。
影响 > 香港土地契約續期

条目：香港地租和官地
香港特別行政區境內的土地和自然資源屬於國家所有，由香港特別行政區政府負責管理、使用、開發、出租或批給個人、法人或團體使用或開發，其收入全歸香港特別行政區政府支配。
“
”
香港特別行政區成立以前已批出、決定、或續期的超越一九九七年六月三十日年期的所有土地契約和與土地契約有關的一切權利，均按香港特別行政區的法律繼續予以承認和保護。
“
”
香港特別行政區成立以後滿期而沒有續期權利的土地契約，由香港特別行政區自行制定法律和政策處理。
“
”
根據香港特別行政區政府於1997年7月15日公布的政策聲明，沒有續期權利的契約（不包括特殊用途契約），在期滿時可由香港特別行政區政府全權酌情決定續期50年而無須補繳地價，惟須每年繳納租金，款額相當於有關土地應課差餉租值的3%；租金其後亦會隨應課差餉的改變而調整。自香港特別行政區成立以來，地政總署一直按上述的政策處理1997年後屆滿的契約之續期事宜，獲根據原有契約條款續期的契約無須補繳地價，但須每年繳納有關地段的地租。是否續期會考慮相關因素，包括契約屆滿時地段是否需要作公共用途或原有契約是否出現嚴重違反地契的情況等。
現時續期或新批出的50年土地契約，年期均超越2047年。換言之，在新批出土地上，2047年並不是一個期限。當然，由於大量現成的土地契約將於2047年到期，且繼契價格未定，政府在適當時候需要作出安排以應對屆時岀現的大量續期工作。其後，政府於2024年訂立《政府租契續期條例》，容許沒有續期權利的適用地契在到期前六年，通過刊憲方式批量續期50年，而毋須逐一考慮。
香港特区政府认为，政府藉基本法第七条獲賦予憲法權力和職能，可根據其土地政策管理和批出香港特別行政區境內的土地。該項權力的有效期並無受到規限，亦不會在2047年屆滿。特区政府指出，基本法第一百二十条所赋予的权利包括再行續期至超越2047年的權利。基本法第一百二十三条的对特区政府自行立法解决待续期土地问题的授权是整體授權，並沒有對香港特別行政區批出年期跨越2047年的契約的權力施加任何限制。
影响 > 深圳湾口岸港方口岸区土地续期

条目：深圳灣口岸
深圳湾口岸港方口岸区的土地使用权，由香港特别行政区政府同广东省深圳市人民政府签订国有土地租赁合同，以租赁的方式取得，土地使用期限自口岸启用之日起至2047年6月30日止。
“
”
《国务院关于授权香港特别行政区实施管辖的深圳湾口岸港方口岸区范围和土地使用期限的批复》（国函〔2006〕132号）指出，深圳湾口岸港方口岸区土地使用期限自口岸启用之日起至2047年6月30日止。香港法例第591章《深圳灣口岸港方口岸區條例》规定，该条例於2047年6月30日午夜12時期滿失效，同租賃土地使用期限期滿之日。如土地使用權提前終止或租賃在期滿後續期，香港特別行政區政府保安局局長須在香港特別行政區政府憲報公告土地使用權或租賃期滿的新日期，而本條例於該日期午夜12時期滿失效。
观点与反应 > 香港特区政府

政制及內地事務局副局長陳岳鵬在2016年12月14日的香港立法會會議上答覆議員的提問時，引述全国人大常委会委员长张德江的演講：
首先要坚定对“一国两制”事业的信心。最根本的理由有三条：第一条，“一国两制”是我国的一项基本国策，是战略抉择而不是权宜之计，不会改变。第二条，“一国两制”有坚实的民意基础，是祖国内地和香港之间的最大公约数，不应改变。第三条，香港回归祖国以来的实践证明，“一国两制”是做得到、行得通的，是经过实践检验的好制度，没必要改变。过去，我们按照“一国两制”方针，实现了香港的顺利回归，保持了繁荣稳定，促进了祖国内地与香港的共同发展。未来，我们仍需坚持“一国两制”，继续发挥香港的独特作用。那些所谓中央要把香港“内地化”，甚至变“一国两制”为“一国一制”的说法，完全没有根据。广大的香港同胞是希望“一国两制”坚持下去的。“一国两制”对国家、对香港都最为有利，中央必定会坚定不移地贯彻下去，香港社会完全可以放心。
“
”
副局長表示，香港特別行政區是中國不可分離的部分，這個事實是沒有時限的。中國對香港的主權在回歸50年後不會變，中國對香港的基本方針政策亦不會在回歸50年後改變，因此並不存在《基本法》在2047年後失效的問題。至於《基本法》第5條指「香港特別行政區不實行社會主義制度和政策，保持原有的資本主義制度和生活方式，五十年不變」，這主要是為了明確肯定保持香港原有的資本主義制度和生活方式，而不是為了訂定一個限期。
观点与反应 > 本土派

熱血公民、普羅政治學苑和香港復興會認為2047年問題牽涉香港的法治、國際投資、信貸能力、樓宇按揭和繁榮安定，包括認為土地契約私有產權繫於資本主義制度， 並提出以全民制憲和永續基本法的方式去解決2047年問題，陳根亦在《紐約時報》專欄寫過關於2047年的問題，其後《南華早報》、《金融時報》、《華爾街日報》和《紐約時報》亦有報導。
2016年立法會選舉，香港眾志和熱普城分別提出「民主自決」和「永續基本法、城邦自治」主張，希望可以解決2047年問題。
观点与反应 > 建制派

至於建制派方面，大部分建制派的立法會議員都認為2047的大限是民主派制造出來的偽命題。
前香港立法会主席曾鈺成發表《跨越四七》的文章中，也曾经提及香港年轻人需要注意2047年前途问题，但是他认为“五十年不变”只在其所在的第五条条款中出现，其作用只在该条款中，不会影响到其他条款的实施。
前香港行政长官梁振英则认为2047年的资本主义生活方式会得到延续，认为不擔心2047年後的香港。
前律政司司長梁愛詩在2016年10月6日於香港電台的節目指：「基本法提出50年不變，初衷是考慮到港人利益，相信到2047年，中央亦同樣會考慮港人利益」；但「屆時是內地和香港的制度合一，還是繼續一國兩制，要看香港怎走未來30年的路」。
在2017年5月，梁愛詩再度接受電台訪問，其認為香港人權和自由等都比回歸前進步，一國兩成功落實，又指2047年後香港的前途問題不可能重新討論，只可跟隨基本法，認為回歸20年時憂慮是太早。
观点与反应 > 法律界

在2012年末到2013年中，终审法院前首席法官李国能就提出2047年后“一国两制”何去何从的问题，曾经在2013年5月接受《南华早报》采访时指出，“今后十五至二十年内，有必要讨论并解决香港在2047年之后的未来”。
观点与反应 > 民调与传媒

香港中文大学在第九輪「香港民意與政治發展」調查中显示，近七成受访者「支持」香港2047年後仍「維持一國兩制」。
2018年3月3日，中国人民政治协商会议全国委员会報告刪除「一國兩制」、「港人治港」、「高度自治」等慣例提法，《香港蘋果日報》批评称，五十年不變名存實亡。
參考文獻

↑  .   [2017-09-12]. （原始内容存档于2020-04-24）.
↑   . 维基文库 （中文）.
↑  UC. . 2016-10-14  [2017-09-12]. （原始内容存档于2020-06-07）.
↑  .   [2017-09-12]. （原始内容存档于2020-06-07）.
↑  . 香港01. 2023-12-07  [2024-01-24].
↑  中华人民共和国国务院. . 中华人民共和国中央人民政府门户网站.   [2019-01-03]. （原始内容存档于2019-01-03）.
↑  . www.elegislation.gov.hk.   [2019-01-03]. （原始内容存档于2022-01-03）.
↑  .   [2017-09-12]. （原始内容存档于2020-06-07）.
↑  .   [2017-09-12]. （原始内容存档于2017-03-03）.
↑  .   [2017-02-14]. （原始内容存档于2017-02-14）.
↑  . 即時新聞 instant news. 2017-01-16  [2017-02-22]. （原始内容存档于2017-02-22） （中文（臺灣））.
↑  . 頭條日報 Headline Daily. 2016-09-17  [2017-02-22]. （原始内容存档于2017-02-22） （中文（香港））.
↑  . 明報新聞網 - 每日明報 daily news.   [2017-09-12]. （原始内容存档于2017-09-09）.
↑  梁愛詩：不用太早討論2047後問題 （页面存档备份，存于） now新聞台 （粵語）
↑  . book.sohu.com.   [2017-02-22]. （原始内容存档于2017-02-22）.
↑  . www.takungpao.com.hk.   [2017-02-22]. （原始内容存档于2016-10-19）.
↑  . 香港蘋果日報. 2018-03-04  [2019-01-03]. （原始内容存档于2018-03-04）.
里亞布希

50°55′21″N 33°0′14″E﻿ / ﻿50.92250°N 33.00389°E﻿ / 50.92250; 33.00389
里亞布希（烏克蘭語：），是烏克蘭北部的村莊，隸屬切爾尼希夫州的普里盧基區。該村始建於1629年，面積1.46平方公里，海拔高度131米，2001年人口377，人口密度每平方公里258.6人。
參考資料

Погода в селі Рябухи （页面存档备份，存于）
Unknown Mother Goose

| Unknown Mother-Goose  |
| --- | --- |
Hitorie版本的单曲封面
Wowaka的歌曲
收录于专辑《Hatsune Miku 10th Anniversary Album「Re:Start」》
语言: 日語
发行日期: 2017年8月30日 (2017-08-30)
时长: 4:39
唱片公司: U&R Records
词曲: Wowaka

音乐
YouTube上的〈Unknown Mother Goose〉
 
〈Unknown Mother-Goose〉（）}}是日本创作歌手Wowaka的歌曲，收录于初音未来十周年纪念合辑《Re:Start》。此曲的主要人声使用Vocaloid歌声库初音未来合成，音乐视频于2017年8月22日公开。此外，由本人演唱的版本收录于Hitorie第三张迷你专辑《ai/Solate》与第四张专辑《4》，还曾发行《アンノウン・マザーグース》的单曲唱片，作为单曲于2017年10月22日通过日本索尼音樂娛樂发行。
此曲是wowaka继《Unhappy Refrain》间隔大约六年后投稿的最后一首VOCALOID作品。于2023年4月1日在Niconico达成VOCALOID神话曲（一千万播放次数）。
关于商业表现，此曲在Billboard Japan的综合歌曲排行榜Japan Hot 100最高位列第91。
背景

Wowaka在推出他的首张录音室专辑《Unhappy Refrain》之后，因为恐慌自己在Vocaloid圈子停滞不前以及厌倦对自己的贡献缺少归属感，而陷入六个月的封闭状态，他想到只有自己的歌喉才能拯救濒临崩溃的他，于是离开Vocaloid圈子组建起Hitorie开展自己的乐队生涯。五年后，Wowaka收到参与制作初音未来十周年纪念合辑《Re:Start》的邀请，联系之人在过去帮助Wowaka许多，在会面交谈时也用热情打动了Wowaka，Wowaka答应之后，怀着「我现在能使用初音未来做什么？」的心情花费三个月的时间写下此曲，如同六年前的歌曲〈Prism Cube〉一样，Wowaka在歌曲中再次担任初音未来的和声。
创作

此曲时长3分49秒，每分钟222拍，人声音域在F♯3（mid1F♯）至C♯6（hihiC♯）之间，Hitorie版本低一个八度。此曲是由Wowaka创作，Hitorie编曲，使用Vocaloid歌声库《初音未来》合成主要人声，Wowaka演唱和声。此曲的风格如Vocalo流派（日语：）一贯的快节奏、高音域，在B旋律（日语：）采用陷阱音乐的风格处理。
音乐视频

此曲的音乐视频于2017年8月22日公开，是附带歌词字幕的静态灰度图像，由Wowaka绘制和制作。此视频的图案虽然与〈Unhappy Refrain〉一样是心形，但是是由碎片组成。
2023年4月1日，此曲的音乐视频在Niconico动画上创下了一千万的播放量，获得了神话达成（）的荣誉标签。
排行榜

| 排行榜（2017年） | 最高排名 |
| --- | --- |
日本（Japan Hot 100）: 91
排行榜（2019年）: 最高排名
日本下载（日语：）（Billboard Japan） （Hitorie版本）: 93
排行榜（2022年）: 最高排名
日本Vocaloid（Billboard Japan）: 12
排行榜（2023年）: 最高排名
日本Vocaloid（Billboard Japan）: 3
三烯丙基胺

| 三烯丙基胺 |
| --- | --- |

IUPAC名 N,N-bis(prop-2-enyl)prop-2-en-1-amine
识别
CAS号: 102-70-5
PubChem: 7617
ChemSpider: 7335
SMILES:    C=CCN(CC=C)CC=C 
UN编号: 2610
RTECS: XX5950000
性质
化学式: C9H15N
摩尔质量: 137.22 g·mol−1
外观: colorless liquid
密度: 0.809 g/cm3
沸点: 155.5 °C（429 K）
危险性
GHS危险性符号 
GHS提示词: Danger
H-术语: H226, H302, H311, H312, H314, H331, H332, H412
P-术语: P210, P233, P240, P241, P242, P243, P260, P261, P264, P270, P271, P273, P280, P301+317
若非注明，所有数据均出自标准状态（25 ℃，100 kPa）下。
三烯丙基胺（英語：）是一种含氮有机化合物，结构简式N(CH2CH=CH2)3，属于一种叔胺，常温常压下为无色液体，有氨的气味 。
萬虞愷

| 萬虞愷 |
| --- | --- |
大明南京刑部右侍郎
籍貫: 江西南昌府南昌縣
字號: 字懋卿
出生: 弘治十八年（1505年）乙丑三月十三日 
逝世: 萬曆十六年（1588年）戊子六月十七日 
配偶: 娶蕭氏
親屬: 子 萬廷言、萬廷謙，孫萬建崑
出身
 嘉靖十年辛卯科舉人  嘉靖十七年戊戌科同進士出身 
萬虞愷（1505年—1588年），字懋卿，號楓潭（楓塘），江西南昌府南昌縣人，民籍，明朝政治人物。
生平

嘉靖十年（1531年）辛卯科江西鄉試第八十六名舉人，十七年（1538年）戊戌科会试第一百三十九名，三甲一百七十名進士。授無錫縣知縣。二十二年十二月擢授南京兵科給事中，出為山東布政司參議，歷福建按察司副使、貴州右參政、湖廣按察使、福建右布政使、山西左布政使，四十年閏五月升南京都察院右僉都御史、提督操江兼管巡江，右副都御史，升南京都察院右副都御史總督漕儲，所至著政績。四十二年三月升南京刑部右侍郎，四十四年三月以考察致仕，卒年八十四。
家族

曾祖萬景星；祖父萬必昌；父萬廣載，母傅氏；繼母李氏。具庆下。兄虞託、虞詩、弟虞瑞、虞鄰。
有子萬廷言，嘉靖進士，學者。孫萬建崑，萬曆進士。
弗朗西斯科

弗朗西斯科（西班牙語：），为西班牙語人名。
西班牙文人名

弗朗西斯科·塔雷加（Francisco Tarrega）西班牙吉他演奏家、作曲家
弗朗西斯科·佛朗哥（Francisco Franco）西班牙长枪党党魁
弗朗西斯科·皮萨罗（Francisco Pizarro）西班牙探险家
弗朗西斯科·吉列尔莫·弗洛雷斯·佩雷斯（Francisco Guillermo Flores Pérez）1999-2004年萨尔瓦多总统
弗朗西斯科·德保拉·桑坦德尔（Francisco de Paula Santander）新格拉纳达共和国总统