美國政府 NLRB 給出競業及禁止挖角條款違法的判決

在「NLRB judge declares non-compete clause is an unfair labor practice (nlrbedge.com)」這邊看到的,原始文章是:「In First Case of its Kind, NLRB Judge Declares Non-Compete Clause Is an Unfair Labor Practice」。

NLRB (National Labor Relations Board) 這次是針對 J.O. Mory 的判決,原始判決本來想連結到 NLRB 的網站上,但發現現在連不上,先給這份好了:「09031d4583d765f7.pdf」。

裡面有兩個面向的判決,一個是競業的部分,另外一個是禁挖的部分。細節可以直接看原文,或是直接丟 Google Translate 或是叫 ChatGPT & Gemini 翻譯都可以。

競業條款的部分不算太意外,因為整個州政府與聯邦政府都在修法大幅限制企業在合約上面可以設定的競業條款,不再讓自由市場機制決定勞工的工作權益 (通常是弱勢方)。

禁挖條款的部分是這次看到覺得比較新鮮的,認定違法的原因與禁業的部分類似,都是以會影響勞工的工作權益而宣告違法。

這塊應該是進行式,這幾年應該還是可以看到不同的判決出現...

關於 Non-null string 的處理...

上一篇「Filter Input & Escape Output...」有提到 Non-null UTF-8 string 的 filter,結果剛剛洗澡的時候想了想,好像寫錯了?

問題在於「到底是先 de-null 再 iconv(),還是先 iconv() 再 de-null」的問題。

這個問題其實跟 iconv() 成 UTF-8 時遇到不合法字元時怎麼實做有關,也就是 undefined behavior... 由於 \0 是合法的 UTF-8 character,所以我們假設某一種實做是當 iconv() 遇到不合法字元時會用 \0 帶進去:

先 de-null 再 iconv()

這是上一篇文章提到的方法。但在上面提到的 iconv() 實做下卻是有問題的方法。原因很簡單,de-null 後沒有 \0 的字串,卻會因為 iconv() 而產生 \0

先 iconv() 再 de-null

這邊要考慮的是最後 de-null 後會不會變成 invalid UTF-8 string。答案是不可能,因為 iconv() 轉出來後保證是 UTF-8 string (不論如何處理非 UTF-8 character 的部份),而 UTF-8 string 內的 \0 一定可以當 separator,所以切下去一定還是 UTF-8 string。(可以參考下圖關於 UTF-8 character 的規則)

所以?

可能以現在的 iconv() 實做來說,兩者都不會有問題,但寫程式的時候總是要避免 side-effect,所以後者的方法會比前者好。