# Intro 在很多實務上的需求, 需要了解 client 過來的請求是來自哪裡或來自哪個國家
最常見的方式就是依靠來源的 IP 判斷(這裡排除 proxy, VPN 或造假來源的因素)
而在 HTTP protocol 中, 會把 IP 附在 header(至於帶在哪個 header 與支援哪些 header 主要取決於各個語言對 HTTP 的實作)
header Sample
上述範例只是取幾個比較常見的會帶上去的 header
至於更加詳細的 header 支援與取得 IP 時需要注意哪些事情可以參考以下文章
Refer - 如何正確的取得使用者 IP？
而為何可以用 IP 能夠確認出是在哪個地區國家甚至城市呢?
主要是因為有 IANA(Internet Assigned Numbers Authority) 進行了 IP 網段的分配
又有細分 ABCDE 級網段
這裡先大略講一下
相關資訊可以去看網路概論等相關的資料
Refer - 各國IPv4位址分配列表
Refer - 已分配的/8 IPv4位址網段列表
# 方法 現在有幾種方法可以處理這件事情
但是經有上述的介紹可以知道其實最主要的基本判斷就是得知道哪些 IP 段對應哪些國家
那接下來就是有哪些方法可以來做這件事了
...
# Intro 又是久違的寫爬蟲…
這次是接手大大們的 code
寫的是 PHP 版本
研究了一下寫法
才發現現在可以不使用第三方套件就可以處理了
所以這裡紀錄一下
# 取得 HTML 內容 使用 curl 使用 file_get_contents curl 是我常用的方式 看了大大們的 code 才知道原來 file_get_contents 也可以取 http/https 內容…
這邊簡單貼一下兩種作法的範例
## curl function httpGet($url) { $ch = curl_init(); curl_setopt($ch,CURLOPT_URL,$url); curl_setopt($ch,CURLOPT_RETURNTRANSFER,true); curl_setopt($ch,CURLOPT_HEADER, [ 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36' ]); $output=curl_exec($ch); curl_close($ch); return $output; } ## file_get_contents function htmlContentGet($url) { $opts = [ "http" => [ "method" => "GET", "header" => "User-Agent: Mozilla/5.
...
# 前言 在 web 的世界中有一個需要處理的是文字排版的呈現
因為從電腦到整個計算機科學的領域都是在拉丁語系為主宗的國家發展的
所以在介面的文字排版上自然以從左到右為主
但是在這世界上的文字排版有從左到右, 上到下, 右到左等呈現方式
所以需要依照需求或不同語系的文字上有相對應的處理, 尤其是在多語系的情況下
上到下的排版大多是書面用的排版, 相對在資訊領域比較少呈現, 且因為上到下的排版方式也大多是亞洲地區的國家, 在標準化的話語權不高
但也漸漸在 web 領域中有開始支援上到下的排版(writing-mode)
且在資訊領域也大多是用左到右的呈現, 所以影響相對小
額外補充一下大部分的方塊文字像是中文、日文、韓文等其實左到右、右到左、上到下都可以書寫與呈現
但在部份語系像是
阿拉伯文 烏爾都文 庫德文 波斯文 希伯來文 上述文字排版就固定都是從右到左
除了希伯來文以外都是從阿拉伯文字延伸的, 就像是英文、德文、法文都是拉丁文延伸出來一樣
至於為何在世界各地的文字排版會有差異其實主要是起源於早期該文字書寫的方式與被書寫在什麼材質上面為主
右到左主要起源於早期是文字是刻在石板上面, 左手拿鑿子, 右手拿錘子, 這樣從右到左是相對順手的
中文早期大多從上到下從右到左的排列主要起源於以前是在竹片上捲成冊的(竹簡)
在單片竹片上面書寫自然是上到下, 那捲成冊之後在閱讀時為了方便持握, 會是左手拿著竹簡, 右手打開來看內容, 自然就變成了右到左來閱讀
不過現在大多也因為資訊科學的發展後在電子載體上就沿用左到右的排版(前面提到電腦乃至資訊科學都是在拉丁語系的國家發展出來的)
不過在亞洲地區的國家部分書面印刷還是有保留上到下右到左的排版
不過有點扯遠了
# 實作 RTL(Right To Left) 的方式 這次主要是要處理 RTL 的問題
但其實在實作上也很好解
HTML tag 有個屬性是 dir 只要設定是 rtl 或是 ltr 就可以了
那麼要在什麼情況下設定這個東西?
大致上會在兩種情況設定
## 1. 多語系且有右到左語系 網站是多語系的網站且有右到左語系提供切換呈現
...
# Intro 有時在看 GA 的 Web 數據時會發現在 Safari 的點擊 click 事件似乎會比較少
其實這背後是有原因的
主要是各個瀏覽器再處理新 direct 時的行為不一致所導致的
在 Safari 上面發生 direct 到新的 URL 的行為(超連結或是 JS 處理) 時
事件觸發過程中的任何請求會中斷甚至不會發出請求
所以這就是為何在 GA 中的 Safari 的 click 數量會有些異常的原因
雖然 GA 預設會做 setTimeout 處理
但是也不一定是百分之百處理成功
所以最佳處理方式還是自己在用個 settimeout 包起來後再 direct
像是以下範例
link.addEventListener('click', (e) => { e.preventDefault(); window.gtag('event', 'click', { event_category: 'link' }); setTimeout(() => { location.href = e.target.href }, 250) }) 如果真的要確保 GA 送完才做 direct
GA 也有提供事件發送的 callback 處理
...
因為工作上的需要
需要把使用者輸入的訊息中含有 url 的部分把它取出來轉成超連結
參照以下範例
https://gist.github.com/metafeather/202974/34c2d31bd82f59c2486f38790054bbbc0b10ca8b
不知為何他的正規有點問題
所以又做了修正
function urlParse(str) { var urlArray = []; var urlRegex = /((http[s]?|ftp):\/)\/?([^:\/\s]+)(?::([0-9]+))?((\/\w+)*\/)?([\w\-\.]*)?([#?\w\=]+)?([\&\w=\w]+.*)?([\w\+\-\/\%]*)?[A-Za-z0-9_\/]/g; var arr = str.split(/[\n,' ']+/gm); for (let u = 0; u < arr.length; u++) { const element = arr[u]; var validate = element.match(urlRegex); if (validate) { urlArray.push(validate[0]); } } return urlArray; } url 格式遵循 RFC3986
refer - rfc3986
這邊可以在實作一個白名單機制限制只有白名單中的域名所屬的 url 才可以轉成超連結
function urlWhitrList(url) { var list = [ 'www.instagram.com/', 'youtu.be/', 'www.youtube.com/', 'www.
...
# 在 Web 中的 emoji 處理 在普遍的字串計算長度的部分
一個字元是單位是一
但是因為 emoji 的 unicode 是比較後面定義的
這超出了原有 JavaScript 原有定義的範圍
可以參照網站的介紹
Unicode – The World Standard for Text and Emoji
所以 emoji 的字串長度在 JavaScript 一率都是從 2 起跳
這在 Web 中會造成有需要處理字串長度的地方就會出現問題
例如:
input 文字的長度限制的使用
<input type="text" maxlength="10"> 字串需要計算長度時
string.length; 尤其是在現在行動裝置的普及, 內建的鍵盤已經有 emoji 的輸入可以使用
更會大大的增加在需要的邏輯處理會出現問題
# 如何解決 有一個方便的套件 runes 會把 emoji 識別出來
所以就可以解決掉 emoji 的問題了
# 背後原理 其實背後的原理也不難
就是去比對 emoji 的 unicode 碼
比對該字串是不是 emoji 的 unicode 碼
...
Refer - Firebase Remote Config API
取用和更新都需要以下 Google oauth2.0 的權限
https://www.googleapis.com/auth/firebase.remoteconfig https://www.googleapis.com/auth/cloud-platform
...
處理 CORS 算是許多 Web 開發者會處理的情況
其中要又有一個比較重要的部分就是要設定 Access-Control-Allow-Origin 這個允許來源的 header
通常為了安全性問題, 都是只會設定允許的 host 上去
但是常常設定而且在不同環境設定也是有點麻煩
所以這邊就用了直接在 server 設定的方式來處理
這樣直接看 server 的 rule 設定即可
也可以快速的條列不同環境的 host
# 用法 if ($http_referer ~* example.com) { add_header 'Access-Control-Allow-Origin' 'https://example.com'; } if ($http_referer ~* dev.example.com) { add_header 'Access-Control-Allow-Origin' 'https://dev.example.com'; } 這個判斷沒有固定的寫法
可以參考底下 Nginx 對 http_referer 的介紹來針對需要判斷 host 的方式進行修改
Refer - 跨來源資源共用（CORS）
Refer - Module ngx_http_referer_module
...
因為在 2020 年下半年 Google 更新的 GA4 的版本出來
基本上就是全新版本的 GA 了
和舊的 GA 使用方式與數據都不相容
主要是因為因應現在 App 記錄和觀察數據的方式和以前單純在 Web 上面不一樣
所以 Google 開發了新的 GA4 來對應這種情況
應該也是會漸漸的都要使用新的 GA4 了
舊的目前還可以繼續用, 開新的 GA 也可以使用通用型來切成開舊版的 GA
但是建議是在使用中的先繼續使用(有餘力再轉換)
新的話就開新的 GA4
這邊主要是記錄新版的使用
但大多也都是會參照其他網站的說明為主(因為很多網站介紹的很詳細)
Refer - 【最全 GA 攻略】2021 最新版 GA4 教學，從新舊比較到自訂報表都 OK！
這網站介紹的蠻詳細的
...
# 最近剛好遇到個問題就順便筆記一下(但是遇到的問題和要寫的內文無關就是了 XD) # 前言 基本上在 url query string 的 value 都要做 url encode
URL encode 會用到以下標準
RFC 1738
RFC 2396
RFC 3986
主要會使用 % 字符來針對需要 escape 的字元做編碼
ex: / -> %2F, + -> %2B 等
但是主要又有幾個問題是基於 HTTP GET 和 POST 與 application/x-www-form-urlencoded 的問題
基本上在使用 HTML form 表單使用時
採用的會是把 空格轉成 +
但這些都不算是大問題
因為基於 CGI 和程式語言的實作
會把 urldeode 回來
所以在程式語言接到 query string 時都是 urldecode 回來的值
問題是在於 browser 上發出到 server 的 URL(就是打開 server 的 access log 看到進來的 Path 拉)
...