.數值型number
整數 10進制(默認) 8進制(前面加0) 16進制(前面加0x)
var num10 = 23; //十進制
var num8 = 023; //八進制 19
var num16 = 0x23; //十六進制 35
console.log("num10=", num10, "num8=", num8, 'num16=', num16);
浮點數 普通形式 指數形式(科學計數法) n乘以以10(寫成e)的m次方。
var floatp = 100.123; //100.123
var floatz = 3.456e6; //3456000
console.log("floatp=", floatp, "floatz=", floatz);
2.字符串類型string
var stra = '這么大一個國家,責任非常重、工作非常艱巨。我將無我,不負人民。我愿意做到一個“無我”的狀態,為中國的發展奉獻自己。';
var strb = "2019年3月22日,意大利眾議長菲科舉行會見時的講話。";
var strc = '我將無我,不負人民。';
document.write(strc, "</br>", stra, "</br>", strb);
3.布爾值boolean,只有 ture和false
0表示false,非0表示真。
轉換成數值時:true為1,false為假。
編在這里根據知識圖譜整理了CSDN站內的優質文章300篇,幫助見習工程提升技術能力、實現系統化學習!
基礎IT技術文章300篇大合集包含:
【信息/編碼】進制轉換25篇、數據編碼25篇;
【IP/組網】網關與網段25篇、IP協議26篇、主機與DNS 23篇、訪問控制37篇;
【程序邏輯】JavaScript 29篇、常用算法37篇;
【Web基礎】HTML 31篇、CSS 32篇、DOM與BOM 23篇
在如今這個時間和知識都是碎片化的時代,C站根據C1-C4認證的成長路徑,進行知識細化整理,形成系統化的知識圖譜。
歡迎關注訂閱csdn高校俱樂部,每天獲得最核心最新鮮的知識合集,助你穩過認證、通關大廠~
見習工程師要求具備“信息/編碼”、“IP/組網”、“程序邏輯”和“Web基礎”這四項基礎能力。這些基本技能都是目前一線大廠開發工作中會高頻接觸和使用的“底層邏輯”(其中程序邏輯使用 JavaScript 作為編程語言)
就軟件技術而言,熟練地進行不同進制間的計算和轉換,理解ASCII、UTF-8等字符編碼原理,掌握TCP/IP子網劃分、路由重組等計算機網絡技術,學會常用HTML標簽、CSS樣式表和基礎JavaScript語法,對于后續更高級知識的學習大有裨益。
1、進制轉換文章 (節選 )
我們為什么要學習進制
進制之間的轉換(二進制、八進制、十進制、十六進制)
計算機基礎進制轉換(二進制、八進制、十進制、十六進制)
進制轉換:二進制、八進制、十六進制、十進制之間的轉換
C語言算法之將十進制數轉換成二進制數
JAVA 進制轉換的幾個方法
C++中的各種進制轉換函數匯總
c/c++進制轉換方法匯總(含全部代碼)
2進制 , 8進制 , 10進制 , 16進制 , 介紹 及 相互轉換 及 快速轉換的方法
數據結構練習——棧(進制轉換)
2、數據編碼 (節選)
三種常用的數字數據編碼方式
一篇文章徹底弄懂Base64編碼原理
處理分類數據 非數值型編碼
Redis數據編碼方式詳解
關于http接口開發中json格式數據編碼問題處理
關于python中pymysql數據編碼問題
[Python模塊學習]使用base64模塊進行二進制數據編碼
柵格數據的編碼方法
UTF-8與GBK互轉,為什么會亂碼?
IP/組網】
1、網關與網段 (節選)
IP地址,子網掩碼、默認網關,DNS服務器是什么意思?
IP地址,子網掩碼、默認網關,DNS服務器之間的聯系與區別
VLAN基礎知識
網關和網段區別
VMware選擇VMnet8模式連接外網的方法
192.168.和10.0.開頭的IP、內網IP段、IP簡介、分類——(IP觀止)
計算機網絡: IP地址,子網掩碼,網段表示法,默認網關,DNS服務器詳解
指定網段走指定網卡網關方法
Vmware設置靜態ip連網 ( 使用自定義Vmnet8 net )
計算機網絡——不同網段下的主機通信
2、IP協議 (節選)
太厲害了,終于有人能把TCP/IP 協議講的明明白白了
實現基于 TCP/IP 協議簡單的客戶端、服務器通信程序實例
網絡協議、socket、webSocket
Windows 無法自動將 IP 協議堆棧綁定到網絡適配器
面試時,你被問到過 TCP/IP 協議嗎?
TCP/IP協議組——完整工作過程分析
《TCP/IP詳解 卷1:協議》PDF分享
TCP/IP協議簡述+常見面試題
wireshark抓包分析——TCP/IP協議
TCP/IP協議四層模型
以下是300篇文章的全部目錄哦
CSDN軟件工程師能力認證(以下簡稱C系列認證)是由中國軟件開發者網CSDN制定并推出的一個能力認證標準。C系列認證歷經近一年的實際線下調研、考察、迭代、測試,并梳理出軟件工程師開發過程中所需的各項技術技能,結合企業招聘需求和人才應聘痛點,基于公開、透明、公正的原則,甑別人才時確保真實業務場景、全部上機實操、所有過程留痕、存檔不可篡改。
熱點文章:
最受歡迎主流Java框架文章50篇:spring mvc、Hibernate、structs
普通本科生怎么進大廠?大廠招聘JD詳解
CSDN高校俱樂部名師百校行——河北站
版權聲明:本文為CSDN「高校俱樂部」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。
oo long; didn't read:
1. 大多數應用中,只需要用“絕對時間 DateTime”一種技術實現即可
2. 后端應統一用 UTC 時間(包括 DB 落盤、接口定義),不應當受用戶時區或服務器時區的影響
3. 前端輸入、展示的時間,根據具體業務場景進行時區調整,以及精度調整
4. 面對不帶時間的日期,要明確區分「紀念日」與「精度不高的絕對時間」兩種用途,大部分時候你看到的日期是后者,它也應當用“確定時區的 DateTime”來實現
日期時間的處理,一直是計算機系統中看似簡單,實則經常爆雷的問題。
例如,每隔幾年,都會爆出的「千年蟲問題」的各種變種,通常因為系統在設計之初,沒有設計好日期時間的數據存儲方式,或者低估了產品設計的生命周期,導致最初選型的數據結構不夠用了。
千年蟲問題:
年紀大的程序員,都知道千年蟲問題。在 2000 年之前,很多系統用 2 位數字表示年份,這樣 99 年是它能表達的最大數值。因此 1999 年之后的一年,在這些系統中是沒有定義的,甚至可能出現多種奇怪的情況,例如“1900”、“1:00”、“19:0”(為什么?感興趣的讀者可以自己推測)。
如果說,「千年蟲」是在時間維度上缺乏前瞻性的設計導致的,那么另一種缺乏前瞻性的問題,是空間維度的,即產品全球化、跨時區帶來的問題。
全球化的產品中,如果時間的處理沒有遵循統一的標準,會讓整個系統充斥著難以理解和維護的時間轉換。各種接口的對接文檔,都不得不明確說明「這個接口的時間是什么時區的?需要如何處理?」后端服務如果需要跨國部署在多個大洲的機房時,因為服務器的時區不同,需要做大量的改造。
遺憾的是,大多情況下,產品不會一開始就有「全球化」屬性。所以在一開始,產研團隊都不會重視全球化的設計問題,很容易留下缺乏前瞻性的設計問題。
通常情況下,我們都不鼓勵「過度設計」。然而,日期時間的設計,是最不怕「過度」的。這時因為,在技術上實現一個前瞻的時間日期方案,成本并不高;但如果一開始的設計不夠,后期的升級和數據遷移工作,卻是傷筋動骨的。
在微服務之間,以及在前后端之間,建議用字符串傳遞日期時間。字符串清晰易讀,易于人工調試,帶來的開銷通常也完全可以接受。(帶大量時間數據的接口,建議考慮用 Unix Timestamp。)
如果用字符串,格式就不要自己發明了。有個非常明確的國際標準:ISO 8601(wikipedia: https://en.wikipedia.org/wiki/ISO_8601)
下面舉例是符合規范的常用格式:
注意,MySQL 中使用的字符串格式(如 2022-02-09 12:36:42)并不符合規范,不建議使用。
不同數據庫在時間日期相關對象的處理差異很大。這里單說 MySQL,因為坑不小。
MySQL 的 DateTime 數據在存儲時并不包含時區信息,因此,在讀取時也不會做任何時區的轉換。
同時,每個 MySQL 連接會話,都有「會話時區」的概念,但這個概念只影響 MySQL 的 NOW() 等有關當前時間的函數的行為,對數據中已經保存的 DateTime 沒有任何影響。
例如:
SET time_zone = '+00:00' ;
UPDATE tab SET datetime_colume = '2020-01-01 00:00:00';
SET time_zone = '+08:00' ; -- 換一個會話時區
SELECT datetime_colume FROM tab;
-- 返回值仍然是 '2020-01-01 00:00:00',和寫入的數據一致,和會話時間無關
---------
SET time_zone = '+00:00' ;
SELECT NOW(); -- 假設返回 '2022-01-01 00:00:00'
UPDATE tab SET datetime_colume = NOW(); -- 存入的是 '2022-01-01 00:00:00'
SET time_zone = '+08:00' ; -- 換一個會話時區
SELECT NOW(); -- '2022-01-01 08:00:00' 根據時區變化了
SELECT datetime_colume FROM tab; -- '2022-01-01 00:00:00' 已經寫入的不會變
各語言一般都提供了原生的 DateTime 數據類型,以表達絕對的日期時間,并且都支持上面 ISO 8601 規范的解析和格式化。
處理相對時區時,各種語言通常都是使用操作系統的時區數據庫,來轉化為絕對時區。時區數據庫需要在聯網情況下,由操作系統負責定時更新。
Unix Timestamp 在存儲、計算、傳遞環節都可以使用,可謂萬能。它唯獨不適合表達紀念日日期。
它通過一個數值表示了一個絕對時間與 Unix Epoch 時間(定義為 1970-01-01T00:00:00Z)的差值秒數。Unix Timestamp 本身已經表達了絕對時間,并不需要時區信息。
使用 Unix Timestamp 時,應特別注意選用合適的數值類型,它會影響時間表示的范圍。稍不留神,你就可能種下一個新的千年蟲。
本著不重不漏的原則,我們可以按如下表格劃分產品中的所有日期時間對象:
日期+時間 | 僅時間 | 僅日期 | |
不指明時區,無需根據用戶所在時區做轉換 | ① 表示本地的確定時間點 | ③ 表示本地重復性時間 | ⑤ 表示紀念日、節日 |
指明時區,需根據用戶所在時區做轉換 | ② 表示全球唯一確定時間點 | ④ 表示全球可理解的重復性時間 | ? 不存在的場景 |
下面逐一解釋這五種場景。
信息量包含「年月日-時分秒-時區」。這樣,就可以完全確定歷史長河中的一個無歧義的時間點。這個時間點是完全客觀的,和訪問的用戶地理位置無關,和服務器的地理位置無關,和什么都無關。
產品表現上,通常會根據查看者所在的時區來重新調整時間的顯示。
用途舉例:
包含「年月日-時分秒」,因為沒有時區信息,所以它本身并不能確定一個精確的時間點,而是只在特定的情境下才有意義。
所謂特定的情境,是因為業務場景中蘊含了時區的信息,并且是大家公認的共識。因此,本質上它仍然表示了一個絕對時間。在產品表現上,因為對時區的共識,所以不需要根據查看者的時區來調整時間的展示。
用途舉例:
和前兩類相比,去掉了「日期」這個信息,是為了描述重復性的日程。它可以是指明了時區的,也可以不指明時區,而基于人們對時區的共識去理解。
用途舉例:
日期對象幾乎只有一個有意義的用途:表示紀念日/節日。它不會包含時區信息。
認為「日期」只能用于「紀念日」,有些絕對了。但我確實查閱了很多資料,也沒有看到任何非「紀念日」用途的日期。
例如:
產品體現上,不需要根據時區調整日期的顯示。本質上,「紀念日」的邏輯,其實是人腦的不嚴謹導致的一種習慣,是不嚴謹、不客觀的習慣。不包含時區信息,就是為了滿足這種不嚴謹的習慣。
上面說過,日期對象不能包含時區。你可能會問,我需要表示“北京時間 2022 年 3 月 22 日”呢?答案是:這不是一個日期,而是一個「精度不高的絕對時間」。
很多情況下,當你想用日期時,其實很可能需要的是個「精度不高的絕對時間」。在飛書人力套件的業務中,經常會遇到這種場景。
例如,一個在美國的同學與一個在日本的同學,都在 2022 年 3 月 22 日這天從公司離職了,由同一個在北京的 HR 辦理離職事項。
可見,從我們用戶視角理解的「一個事件發生的日期」,其實是我們忽略了時間的精度。在產品全球化之前,我們通過一些默認的簡化,忽略了時間精度的問題(例如把時間都填成 00:00:00)。一旦面臨產品的全球化,就需要補齊時間、提高精度。
而補齊時間、提高精度的方式,需要根據具體的產品形態具體考慮、明確定義。
例如,在上述離職場景下,就需要按照這個公司對離職的定義來補充,可以是當地時間當天的 23:59:59,也可以是當天下班時間,如 17:00:00。
又比如,對于跨團隊的業務,例如一個同學的上級匯報線從一個美國 Leader 轉到一個日本 Leader,那么為了避免歧義,通常會約定一個確定的生效時區,如統一按照公司的總部所在地的時間來計算。
適用于上面的 ①②③④ 四種場景。
所有后端暴露的接口中的時間對象,全部以 UTC 時間表示。
同時,所有后端在存儲、計算、傳輸時間時,也統一使用 UTC 時間。由于 DB 存儲時間時,時區信息會被丟掉,因此應保證丟掉的時區,是大家明確約定清楚的無歧義的,即 UTC。這樣一來,DB 中的所有時間字段也都沒有歧義。
接口內部產生的時間,例如 CreatedAt、UpdatedAt時間,都應該轉換為 UTC 再落盤。如果直接使用了 MySQL 的NOW()函數,應確保 MySQL Session 的時區設置正確。
在前端或 BFF 負責處理用戶輸入的時間,以及展示給客戶看到的時間。包括兩個步驟:
上述兩點,是一定需要在產品設計中定義清晰的,切忌含糊不清。
不要較真兒抬杠的幾點:
由于歷史原因,DB 里已經采用北京時間保存了,那么我們可以約定+0800 時區是我們所有后端接口的時間。只要用一個確定的絕對時區,就不會有歧義,不必非要時 UTC。
也可以在后端接口的網關層處理時間轉換。不要較真那算不算 BFF,我們需要的是,時區轉換邏輯應嚴禁深入到后端的下層去。
適用于上面的 ⑤,即紀念日場景。
輸入或展示時,都不對日期做任何處理。日期對象直接保存在 DB 中。
只有真正的紀念日有必要用這種方式,應當非常謹慎。例如保存一個聯系人的生日時。
使用絕對的時差來表示時區,例如:“東 8 區”表示比世界協調時間(UTC)早 8 個小時的時區。這是個客觀的時區。
很多時候,我們關注的是一個城市或地區的時區。例如:Asia/Shanghai 表示中國時間;三字母的縮寫 EST 表示美國東部標準時間。注意,這些根據地理位置定義的時區的時差是會發生變化的,變化因素包括:可能受到當地政策的影響,或夏令時影響。
對于歷史的時間,地理時區是可以確定客觀時區的,因為沒有人會重新定義已經過去的時間。
對于未來的時間,地理時區并不能確定客觀時區。因此,如果一個未來的事件是按照非絕對時區約定的,那么它很可能變化。并且,我們的產品需要考慮到處理這種變化。
例如,中國員工發起一個“每天早 8 點”的跨國會議,那么在美國,由于夏令時的改變,冬天開會的時間和夏天是不一樣的。反之,美國員工發起的一個“每天早 8 點”的跨國會議,由于美國夏令時的變化,對中國員工的時間也是夏天和冬天不一樣的。
某些國家在夏天,會把時間調快一小時(提前一小時)。這表現為,同一個地區,在冬天和夏天用不同的絕對時區。
這樣做,是因為夏天白天很長,調整后會在白天的更早的時段上班,從而下班后有更長的天亮的時間。注意,并不是把 10 點上班調整到 9 點上班,而是全社會重新定義了 10 點提前了一小時。
一個具體的例子,在美國:
在 2021 年 3 月 14 日凌晨 1:59:59 后,下一秒就是凌晨 3:00:00。因此,美國的 2021 年 3 月 14 日凌晨 2:10:00 這個時間實際上不存在。為了兼容,根據 RFC5545,如果日程約在了這個不存在的時間,會認為是 3:10:00。
在 2021 年 11 月 7 日凌晨 1:59:59 后,下一秒是凌晨 1:00:00。因此,美國的 2021 年 11 月 7 日凌晨 1:10:00 這個時間實際上會出現兩次。為了避免歧義,根據 RFC5545,看到這個時間時,會認為是靠前的時間點。因此,除非用別國的時區來約日程,否則,美國老板是不可能約你在重疊的第二個小時內開會的。
https://en.wikipedia.org/wiki/ISO_8601
https://www.rfc-editor.org/rfc/rfc3339
https://datatracker.ietf.org/doc/html/rfc5545
https://stackoverflow.com/questions/2532729/daylight-saving-time-and-time-zone-best-practices
https://medium.com/@vivekmadurai/how-to-deal-with-date-and-time-across-time-zones-39b1bd747f35
https://medium.com/@vivekmadurai/how-to-deal-with-date-and-time-across-time-zones-39b1bd747f35
https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/behavior-format-date-time-field?view=op-9-1
https://www.timeanddate.com/time/change/usa?year=2021
*請認真填寫需求信息,我們會在24小時內與您取得聯系。