常用的工具軟體




Thunder Video Converter 

閃電視頻轉換器是支持 macOS 平台的一款視頻格式轉換工具,於 Apple App Store 上有免費版。




IINA 是一款基于 mpv 的自由及开源媒体播放器,以 GNU 通用公共许可证版本3(GPLv3)发布,用Swift编写,仅支持 macOS 平台。

https://iina.io




LibreOffice

https://www.libreoffice.org




Sublime Text 是一套跨平台的文字編輯器

https://www.sublimetext.com/





ExFAT 在 Win 與 macOS 交替使用容易損毀

如果要在 macOS 和 Windows 之間交替使用外接硬碟時,一定要在 macOS 上將硬碟格式化,因為 macOS 並未支援所有的 Windows 配置單位大小,而會導致無法掛接硬碟

如何在 macOS 格式化 ExFAT:https://www.seagate.com/tw/zh/support/kb/how-to-format-your-drive-exfat-on-macos-1011-el-capitan-and-higher/


然而,根據網友的使用經驗,ExFAT 在 Win 與 macOS 交替使用容易損毀

https://www.mobile01.com/topicdetail.php?f=481&t=2844693

災情詳如網友討論,

簡言之,兩個 OS 都試圖要管理同一顆硬碟的 partitions,容易出問題。

最好還是由其中一方 OS 來管理這顆硬碟 (專用於那一方的檔案系統),然後另一方安裝當三方軟體來存取。


1. 在 Windows 中安裝 MacDrvie (付費軟體)

2. 在 macOS 中安裝 MacFUSE (免費軟體)、NFTS-3G (免費軟體)、或 Paragon NTFS for Mac (付費軟體)




APFS 是設計給 SSD 使用的,HFS+ 只支援到 2040年

https://masasaboy.blogspot.com/2018/09/High-Sierra-without-APFS.html

隨著macOS Mojave的釋出,Apple也停止了對El Capitan的維護,因此我也在最近將系統更新到了High Sierra(我跳過了Sierra,主要原因是Sierra不支援外接螢幕HiDPi)。

屏除你在官方介紹就能看到的東西以外,High Sierra有幾個非常值得提出來的優點。第一是安裝完就會立刻發現的是作業系統佔的容量比El Capitan小了很多,對於當時買MacBook時選了比較小容量機型的人應該是一大福音;另外整體的速度也比El Capitan快... 當然也有可能是因為硬碟容量清出來了所以比較快啦。

第二個優點非常重要,那就是High Sierra原生支援NVMe (Non-Volatile Memory Express) SSD。假如你的MacBook是2015年(包括)以前的機型,其實主機板上的PCIe SSD是可以更換的。然而PCIe SSD規格非常混亂,加上Apple自己又喜歡搞特規,所以以往MacBook即使可以更換SSD,你也只能買特殊規格的SSD來換,像是OWC,或是臺灣就是找創見。當時能夠更換的稱為AHCI (Advanced Host Controller Interface) SSD ,這種SSD非常昂貴,而且你能找到的AHCI SSD通常速度跟品質都不如Apple原廠的(Apple原廠的AHCI SSD一般為SanDisk或Samsung),使得當時自己更換MacBook內的SSD非常不划算。

相較於AHCI,NVMe SSD就便宜許多了,當然價格還是不可能跟SATA SSD相比啦,但NVMe SSD有著超越AHCI的超高速度,如果機器完整支援PCIe 3.0的4條通道,讀寫速度可以到3000MB/sec這麼爽快的速度啊!而且也有廠商做出了轉接頭,所以想買個可以負擔的SSD替換MacBook的內建硬碟再也不是夢想啦!

不過因為我還沒有時間處理轉移的問題,而且雖然硬碟空間是有點拮据,但也還夠用,因此暫時沒有要對更換SSD一事做更多的著墨,但就先提供一個可能性,附上一些連結讓有需要的人可以自己嘗試看看。一如以往,話先說在前頭:Use at your own risk.

HOW TO: MACBOOK PRO RETINA M.2 SSD STORAGE REPLACEMENT AND UPGRADE
Do MacBooks support NVMe SSD drives via the use of a Sintech adapter?


除了原生支援NVMe以外,High Sierra還有一件重要的更新,那就是APFS (Apple File System)。當你從任何舊版的macOS升級成High Sierra時,假如你機器的硬碟是SSD,那麼升級的過程將會自動將檔案系統從過往的HFS+ (Mac OS Extended) 升級為APFS,傳統硬碟以及混合硬碟則不會自動升級,因為APFS就是設計給SSD使用的。

HFS+終將走向終點,因為當時設計時有個限制,那就是檔案日期只支援到2040年的二月6號。然而,APFS現階段看來也還是有各種缺點,尤其根據一份非常詳盡的測試,其效能並不如官方宣稱比HFS+來得高。雖然像是搬檔案這種動作在APFS中會瞬間完成,因為只是換個檔案的位址,不再是像以往把整個檔案從區塊A寫到區塊B,但你總不會永遠只有在搬檔案吧?

另外,由於過往的macOS使用的檔案系統都是HFS+,這同時也造成一個問題,那就是當你升級成High Sierra之後,會發現過去用Time machine備份的檔案全都不能用了!更尷尬的是,High Sierra並沒有辦法直接安裝在APFS格式的SSD上 (What?),所以如果得重灌,使用者得利用Recovery先重灌機器自帶的作業系統版本,然後才能升級上High Sierra。(來源

總之,各種我得到的資訊都讓我認為先停在HFS+是比較好的做法,畢竟Apple的產品照過往的經驗,通常第一代還是別碰的好。幸好,High Sierra確實可以在安裝的時候避開將檔案系統升級成APFS(畢竟如果是傳統硬碟跟混合硬碟的機型本來就不會轉換了嘛),但就得下點指令了。

我主要是參考這篇的做法來進行。在你下載完High Sierra的完整安裝檔之後,對安裝檔 (.app檔) 點右鍵選擇 "Show Package Contents" ,照著網站的指示在Resources資料夾中找到startosinstall這個檔案。接著打開Terminal,最簡單的作法就是把剛才那個startosinstall從Finder直接拖進Terminal,接一格空格,然後給上參數 --converttoapfs NO ,按下Enter整個安裝過程就會開始進行了。完整的指令會像是:

/Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/startosinstall --converttoapfs NO

注意,我參考的那個網站真的很落漆,不但在指令那行把兩個減號(-)變成一個連字號(–),converttoapfs還忘記加s(但在Terminal的截圖中卻是正確的...),使用的時候要注意一下。不過你打錯它也不會讓你跑就是了啦。

我目前在升級成High Sierra使用的過程中幾乎沒有遇到任何相容性問題,整體來說我還蠻滿意的,祝大家也能在升級後使用愉快。



網站開發的前端技術變化

 



2021/10/9 整理

現在前端已經進入了 MVVM 時代,但 jQuery 並不會退出歷史舞台,即使沒人用 XP、Win7 操作系統,即使所有人都用 Chrome 也不會。jQuery 手工操作已經存在的 DOM,操作比較精細,性能好但開發效率低,瀏覽器兼容較好,各個門戶主要還是用 jQuery。


MVVM 解決的是開發效率問題,構建複雜表單比較順手,大大降低了手工操作 DOM 的代碼量,適合內部應用,管理後台,但 MVVM 不是萬能的,缺點是

1. 要實現 DATA 變化的雙向綁定,一般瀏覽器兼容差

2. DOM 動態生成無法 SEO,搜索引擎搜不到

3. 通過數據操作 DOM 實質上不夠精細,有一點性能上的損耗


jQuery 解決的是遠古時代的瀏覽器兼容問題,將 DOM 操作做了一層兼容性封裝,但其用法本質上與直接使用原生 JS 接口沒有什麼不同。

1. 原生操作 DOM 不可能消失,雖然已經有了 document.querySelectorAll(selector),但有沒有覺得還是 $(selector) 更方便?雖然有了 element.addEventListener(event, handler) 但 $(select).on(event, handler) 是不是更簡潔?

2. jQuery 有一個強大的前端生態

畢竟流行了十幾年,目前很多複雜前端組件、框架都基於 jQuery,比如說編輯器,日期選擇器,自動提示等,你可以用 MVVM 來重寫,但動態渲染 DOM 與穩定性 DOM 有先天的性能差距,越複雜的控件,MVVM 的性能損失越明顯。

而且基於 jQuery 相當於基於原生 JavaScript,jQuery 可以視為原生 API 的一層封裝,以後沒有瀏覽器兼容問題了,自己實現一個 jQuery 適配器即可,比如 zepto,所有基於 jQuery 的組件可以直接用。







JavaScript 和 jQuery 混用

JavaScript window.onload 和 jQuery $(document).ready() 的差異

在撰寫頁面的 JavaScript 或 jQuery 時,通常會利用 window.onload 事件或 $(document).ready() 事件來確保 DOM 完全載入,不過兩者仍有以下差異。


window.onload 會等網頁的全部內容,包括圖片,CSS及 <iframe> 等外部內容都載入後才會觸發,但 $(document).ready() 在 Document Object Model (DOM) 載入後就會觸發,所以順序上$(document).ready() 會比 window.onload 先執行。


window.onload 是 JavaScript 的原生事件,而 $(document).ready() 是 jQuery 的事件(其實是透過監聽 JavaScript 的 DOMContentLoaded 事件來實現)。


window.onload 的用法如下:

window.onload = function() {

  // console.log("window loaded")

};


$(document).ready() 的用法如下:

$(document).ready(function() {

  console.log("document ready");

});

// 也可簡寫成

$(function() {

  console.log("document ready");

});



jQuery 轉為 JavaScript: var jsObject=$("#id").get(0);

JavaScript 轉為 jQuery: var $object=$(document.getElementById("id"));



JavaScript 呼叫 jQuery 方法:

function getResult(){

    $().getFuc();

};

$(function(){

    $.fn.getFuc=function(){

        alert("1111111111111");

    }

});


 jQuery 呼叫 JavaScript 方法:

$("#button3").click(function () {

        getFuc();

    });

function getFuc(){

       alert("111111");

}



在 HTML 中使用 onclick 方法與 jQuery 的事件監聽有何差異 (JS 亦能實現) ?

onclick 通常是在滿足以下條件時才優先於 .click 的方法:

1. 只有一個事件要為 click 事件註冊
2. 擔心移動性能/電池壽命

jQuery 以犧牲性能為代價來綁定所有事件。

如果我們談論性能,在任何情況下直接使用總是更快。


但倡導事件監聽的理由是 JavaScript 和 佈局(HTML) 應該分開
提倡者認為任何這些事件創建 evenHandler 是更好,一個事件可以捕獲多個項目,而不是為每個事件創建單獨的腳本



防禦利用 iframe 的站點劫持攻擊

https://paper.seebug.org/papers/Archive/drops2/Clickjacking%E7%AE%80%E5%8D%95%E4%BB%8B%E7%BB%8D.html



各種防禦與破解的方法整理


推荐的防御方法:


一、X-FRAME-OPTIONS

X-FRAME-OPTIONS是微软提出的一个http头,专门用来防御利用iframe嵌套的点击劫持攻击。

并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。

这个头有三个值:

DENY               // 拒绝任何域加载

SAMEORIGIN         // 允许同源域下加载

ALLOW-FROM         // 可以定义允许frame加载的页面地址

php中设置示例:

header ( "X-FRAME-OPTIONS:DENY");

二、目前最好的 JavaScript 的防御方案为:

<head>
<style> body { display : none;} </style>
</head>
<body>
<script>
if (self == top) {
    var theBody = document.getElementsByTagName('body')[0];
    theBody.style.display = "block";
} else {
    top.location = self.location;
}
</script>




0x00 相关背景介绍

Clickjacking(点击劫持)是由互联网安全专家罗伯特·汉森和耶利米·格劳斯曼在2008年首创的。

是一种视觉欺骗手段,在web端就是iframe嵌套一个透明不可见的页面,让用户在不知情的情况下,点击攻击者想要欺骗用户点击的位置。

由于点击劫持的出现,便出现了反frame嵌套的方式,因为点击劫持需要iframe嵌套页面来攻击。

下面代码是最常见的防止frame嵌套的例子:

if(top.location!=location)
    top.location=self.location;

事实上,这种代码很容易被绕过,在后文中讨论。

0x01 防御的几种方式

防止frame嵌套的js使用代码由高到低比例:

if (top != self)
if (top.location != self.location)
if (top.location != location)
if (parent.frames.length > 0)
if (window != top)
if (window.top !== window.self)
if (window.self != window.top)
if (parent && parent != window)
if (parent && parent.frames && parent.frames.length>0)
if((self.parent&&!(self.parent===self))&&(self.parent.frames.length!=0))

检测到后的处理方案:

top.location = self.location
top.location.href = document.location.href
top.location.href = self.location.href
top.location.replace(self.location)
top.location.href = window.location.href
top.location.replace(document.location)
top.location.href = window.location.href
top.location.href = "URL"
document.write('')
top.location = location
top.location.replace(document.location)
top.location.replace('URL')
top.location.href = document.location
top.location.replace(window.location.href)
top.location.href = location.href
self.parent.location = document.location
parent.location.href = self.document.location
top.location.href = self.location
top.location = window.location
top.location.replace(window.location.pathname)
window.top.location = window.self.location
setTimeout(function(){document.body.innerHTML='';},1);
window.self.onload = function(evt){document.body.innerHTML='';}
var url = window.location.href; top.location.replace(url)

0x02 绕过的几种方式

对于使用parent.location来防御的可以使用多层嵌套的方式绕过。

一、例如防御代码为:

if(top.location!=self.location){
     parent.location = self.location;
}

建立两个页面:

1.html代码为:

<iframe src="2.html">

2.html代码为:

<iframe src="http://www.victim.com">

访问1.html之后可以看到页面并无跳转等动作。

http://static.wooyun.org/20141017/2014101711515250154.png

二、onBeforeUnload函数的利用:

onBeforeUnload的介绍以及各种浏览器的支持情况请见:

http://w3help.org/zh-cn/causes/BX2047

如下的防御代码:

if(top != self) top.location.replace(location);

新建立页面,代码如下:

<script>
var framekiller = true;
window.onbeforeunload = function() { if(framekiller) { return
"Write something here to keep people stay!";} };
</script>
<iframe src="http://www.victim.com/">

打开页面显示如下:

http://static.wooyun.org/20141017/2014101711515274922.png

欺骗用户点击留在此页后显示:

http://static.wooyun.org/20141017/2014101711515228109.png

三、XSS filter的利用

IE8以上以及Chrome浏览器都有XSS筛选器,这些可以用来对付防御frame嵌套的代码。

防御代码如下:

if(top!=self){
    top.location=self.location;
}

新建立页面,代码如下:

<iframe src="http://www.victim.com/?<script>">

访问后页面显示:

http://static.wooyun.org/20141017/2014101711515211018.png

IE的xss筛选器自动拦截了跳转。

斯坦福的文章里写了Chrome也会出现这种情况,并给出了攻击代码:

<iframe src=http://www.victim.com/?v=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7D">

但是测试发现,新版的Chrome并不会拦截了,会直接跳转过去。

如果跟的参数中有变量在页面中显示的,会把变量过滤一遍再输出,但不会阻止跳转。

四、Referer检查的问题

有一些站点允许自己的域名嵌套自己,禁止外站对自己的嵌套。

通常是用document.referer来检测来源是否为自己的域名。

if(top.location!=location){
    if(document.referrer && document.referrer.indexOf("aaa.com")==1)
    {
        top.location.replace(document.location.href);
    }
}

判断字符串中是否含有本域名是常见的错误用法,利用二级域名的方式便可绕过,如:

http://aaa.com.bbb.com

注:从https域下post数据到http域的时候,浏览器不带Referer。

IE有个属性可以设置security为restricted可以禁止iframe里执行js脚本,但是要达到点击劫持的效果,必须要能够执行js所以很鸡肋。

代码如下:

<iframe src="http://www.victim.com/iframe.html" security="restricted"></iframe>

重点是手机站点,很多主站做的很不错,但是手机站点没有做任何防护,很容易造成点击劫持。

五、location劫持

在IE浏览器中,如果能够在防御代码的前面可以插入form表单的话,可以利用form表单对location进行劫持。

<form name=self location="javascript:alert(1)"></form>
<script>
if(top!=self){
   top.location=self.location
}
</script>

用iframe嵌套此代码,可以看到没有跳转,执行了alert(1)。



程式語言編年史

程式語言編年史原文 下面這張圖片描繪了整個程式語言的歷史。包括各種程式語言的發明人、程式語言的特點和適用領域、被什麼網站或公司使用等 (檢視 完整高清圖 )。 之所以會有那麼多不同的程式語言是因為設計程式語言的初衷不同、對語言學習曲線的追求不同、不同程式之間的執行成本差異...