เว็บเบราเซอร์ Pure Java มันใช้งานได้จริงหรือ? [ปิด]


29

ฉันรู้ว่าเว็บเบราว์เซอร์ Java เป็นไปได้ แต่จริงหรือ? ฉันเคยเห็นโครงการ Loboและต้องยอมรับว่าฉันประทับใจ แต่จากสิ่งที่ฉันรวบรวมมันดูเหมือนว่าการพัฒนาหยุดชะงักในปี 2009 เบราว์เซอร์ที่เข้ารหัสใน Java บริสุทธิ์ (ไม่มีการผูก WebKit ทุกประเภท) สามารถแข่งขันกับ ผู้ที่อยู่ในอันดับต้น ๆ ของ Chrome หรือ Firefox หรือจะช้ากว่าเดิมขัดขวางผู้ใช้?


5
คำถามที่น่าสนใจเพราะเว็บเบราว์เซอร์ที่เรียกว่า HotJava เป็นแอปสาธิต Java รุ่นแรก
user16764

3
มันไม่ได้เป็นเพียงแอพตัวอย่างมันเป็นส่วนสำคัญของกลยุทธ์ Sun Java เชิงพาณิชย์ช่วงปลายปี 90 และต้นปี 2000 และพวกเขาผลักดันให้พันธมิตรมีความสัมพันธ์ที่ดี เพิ่มในรายการแปลกประหลาด Java จากดวงอาทิตย์ในยุคเดียวกัน: JavaOS / JavaStation
JustinC

3
ในทางเทคนิคแล้ว Opera, Chrome & FF เวอร์ชัน Android จะไม่ถูกเขียนใน Java หรือไม่? ยังไม่ได้ลอง FF แต่ได้รับอุปกรณ์ที่ดี Chrome & Opera ทำงานได้ค่อนข้างดี
TC1

2
@ TC1 ฉันคิดว่าพวกเขาเขียนด้วย C \ C ++ พร้อมชุดพัฒนาระบบ Android
Wesley Wiser

ปิดอีกครั้งเนื่องจากการใช้เหตุผลที่ไร้เหตุผล ดังนั้นคุณ (SE) คาดหวังเพียง 'ผู้เชี่ยวชาญ' ที่จะตอบ? และผู้เชี่ยวชาญจะตอบอย่างไรเมื่อคุณปิดมัน? ทุกคนไม่ควรตอบฟอรัมชุมชน มันไม่เกินไซต์ที่จะแสดงคำตอบที่โหวต 'ขึ้น' ก่อนหรือไม่ คำตอบที่ไม่ถูกต้องและลงคะแนนสามารถซ่อนหรือเก็บถาวรได้ คุณไม่ควรให้ความเห็นและเชื่อถือได้
killjoy

คำตอบ:


44

ภาษาการเขียนโปรแกรมน่าจะไม่ใช่บล็อกที่สะดุด การจัดการหน่วยความจำที่จำเป็นของ JVM อาจเสียเปรียบในบางส่วนที่สำคัญต่อประสิทธิภาพ (เช่นความหิวของหน่วยความจำ แต่จริงๆแล้ว GC ของ Java อาจดีกว่าในการป้องกันการรั่วไหลของหน่วยความจำมากกว่าสิ่งใดก็ตามที่คุณทำได้ แต่นอกเหนือจากนั้นฉันไม่เห็น stoppers การแสดงที่ชัดเจน

อย่างไรก็ตาม

เว็บเบราว์เซอร์ในระดับ Firefox หรือ Chromium เป็นโครงการขนาดใหญ่และทั้งสองโครงการมีประสบการณ์มากมายเบื้องหลัง - Mozilla สร้างขึ้นจากการสร้างเบราว์เซอร์หลายทศวรรษ (และความล้มเหลวที่มีชื่อเสียง) และ Chrome / Chromium มีทั้ง Google และ Apple (เป็นกำลังสำคัญในการพัฒนา WebKit) ที่อยู่เบื้องหลังมันและดูดซับความรู้และประสบการณ์มากมายจาก KDE และโครงการโอเพ่นซอร์สหินขนาดใหญ่อื่น ๆ ทั้งสองใช้ประโยชน์จากห้องสมุดที่พิสูจน์แล้วในการต่อสู้ไม่เพียง แต่สร้างเอนจิ้นเท่านั้น แต่ยังมีสิ่งต่าง ๆ อีกมากมาย กราฟิกแบบเวกเตอร์การแสดงตัวอักษรการแยกการจัดการ XML DOM Tree ระบบเครือข่ายการแคชการเข้ารหัสรายการไปเรื่อย ๆ และคุณไม่ต้องการบูรณาการสิ่งเหล่านี้ด้วยตัวเองเพราะยากที่จะทำและผิดพลาดได้ง่าย .

ในระยะสั้นการสร้างเว็บเบราว์เซอร์ที่มีความแข็งแกร่งในอุตสาหกรรมนั้นค่อนข้างยากและนั่นคือเหตุผลที่มีเพียงไม่กี่เรื่องที่ประสบความสำเร็จในเวทีนี้ ภาษาการเขียนโปรแกรมมีความเกี่ยวข้องน้อยมากแม้ว่า C และ C ++ จะมีความได้เปรียบทั้งทางด้านเทคนิคและด้านสังคม


11

ในทางทฤษฎีมันสามารถทำได้อย่างไม่ต้องสงสัย จากมุมมองที่ใช้งานได้จริงดูเหมือนว่าจะมีข้อสงสัยมากกว่านี้ loboไม่ได้ใกล้เคียงกับครั้งแรกที่ถูกลอง ในความเป็นจริงหนึ่งในโชว์ผลงานเริ่มต้นของความเหนือกว่าของ Java ที่ควรจะเป็นเบราว์เซอร์ HotJava - ซึ่งกำลังจะเปลี่ยนแปลงโลกและทำให้ "โมเสครุ่น" เบราว์เซอร์ที่ล้าสมัย

แน่นอนว่าเราทุกคนรู้ดีว่าสิ่งที่ตรงกันข้ามนั้นเป็นจริง: HotJava นั้นตายแล้วและไม่เคยเป็นคู่แข่งที่ร้ายแรงในสงครามเบราว์เซอร์ (จริงๆแล้วถ้าคุณค้นหา "เบราว์เซอร์ HotJava" การติดอันดับสูงสุดสำหรับรายงานบั๊ก เกี่ยวกับวิธีการทำงานที่ไม่ถูกต้องแม้กระทั่งสำหรับเว็บแอปของซันเอง)

โดยส่วนตัวฉันคิดว่าสงสัยว่าเป็นไปได้หรือในทางปฏิบัติคือ (ส่วนใหญ่) มองและคิดในทิศทางที่ผิด คำถามไม่ได้ว่า Java ดำเนินการลงโทษอย่างมากสำหรับโครงการดังกล่าวหรือไม่ คำถามคือว่า Java มีข้อดีเพียงพอที่จะพิสูจน์โครงการ

ข้อเท็จจริงง่ายๆคือ webkit (เพื่อใช้เป็นตัวอย่างของคุณ) คือโค้ดขนาดใหญ่และซับซ้อน แม้ว่าเราจะสมมติว่า Java นั้นยอดเยี่ยมยิ่งกว่าที่เราสามารถทำได้เช่นเดียวกับการพูดขนาดครึ่งหนึ่งและความซับซ้อนผลที่ได้ยังคงเป็นโค้ดที่ซับซ้อนขนาดใหญ่ (เช่น V8 และอื่น ๆ )

ฉันคิดว่าก่อนทำซ้ำจำนวนงานนั้นคนส่วนใหญ่ต้องการความมั่นใจมากกว่า: "เราคิดว่าผลิตภัณฑ์ของเรามีแนวโน้มที่จะแข่งขันอย่างเป็นธรรม"

หากคุณเริ่มต้นจากชุดของคุณลักษณะที่ผู้ใช้มองเห็นได้สำหรับเบราว์เซอร์แล้วลองกำหนดวิธีที่มีประสิทธิภาพที่สุดในการสร้างเบราว์เซอร์ด้วยคุณสมบัติเหล่านั้น "Java" อาจไม่ได้เป็นส่วนหนึ่งของคำตอบนั้นยกเว้นเป็นส่วนหนึ่งของ " จาวาสคริ" หากประวัติศาสตร์ทำงานแตกต่างกันไปอาจไม่มีเหตุผลที่มันไม่สามารถ (อย่างน้อยในทางทฤษฎี) เป็นส่วนหนึ่งของคำตอบ แต่ให้สถานการณ์ปัจจุบันมันไม่ได้

นอกจากนี้ฉันเห็นโอกาสน้อยมากที่การเปลี่ยนแปลงนั้น ฉันแทบจะไม่เห็นว่ามันเกิดขึ้นถ้า Oracle (หรืออาจเป็น IBM) ตัดสินใจว่ามันมีประโยชน์ในการรักษาท่าทางการแข่งขันของ Java เทียบกับ (สำหรับตัวอย่างที่ชัดเจน) Microsoft .NET แต่ดูเหมือนว่าจะสงสัยว่าเว้นแต่. NET เริ่มคุกคามตลาดหลักของ Java

นอกเหนือจากนั้นคุณลักษณะใด ๆ ที่คุณสามารถจินตนาการได้ (นอกเหนือจาก "การเขียนใน Pure Java" เป็นคุณสมบัติในตัวเอง) สามารถทำได้อย่างรวดเร็วและง่ายขึ้นในวิธีอื่นนอกเหนือจากการเขียนเบราว์เซอร์ใน Java ทั้งหมด


1
ฉันได้กลิ่นหนังสือเก่า ๆ อยู่ในจมูกของฉันเมื่ออ่านผ่านลิงก์ HotJava นั้น
MarioDS

2
โปรดจำไว้ว่าในวันที่ HotJava Java มีข้อบกพร่องในแง่ของห้องสมุดที่มีอยู่ประสบการณ์นักพัฒนาซอฟต์แวร์และความเร็ว (บางครั้งช้าลง 10-15 เท่า) วันนี้มันค่อนข้างตรงกันข้ามในแต่ละพื้นที่ มีแม้กระทั่งตอนนี้โปรเซสเซอร์ Java (คุณสามารถพูดได้ว่าลูกค้าบางเบราว์เซอร์ Java บนหน่วยประมวลผลจาวา? พริบ) ผมคิดว่า HotJava ล้มเหลวเพียง B / C แพลตฟอร์ม Java ไม่ดีพอแล้ว
Nick P

5

ฉันเชื่อโดยสุจริตว่าทีมงานที่มีความรู้และทุ่มเทสามารถสร้างเว็บเบราว์เซอร์ที่มีประสิทธิภาพใน Java คำถามที่แท้จริงคือทำไม การมีเบราว์เซอร์ที่เขียนด้วยภาษาที่เฉพาะเจาะจงไม่ใช่คุณสมบัติ คนจะใช้ Chrome เพราะเร็วหรือ Firefox เพราะมันขยายได้ แต่พวกเขาจะไม่ใช้ JBrowser เพียงเพราะมันเขียนด้วยภาษาจาวา ดังนั้นคำถามที่แท้จริงจะกลายเป็นปัญหาที่คุณพยายามที่จะแก้ปัญหา?

คำถามต่อไปสมมติว่าคุณมีเหตุผลในการเขียน JBrowser คือ "การใช้ Java ทำให้งานง่ายขึ้นหรือยากขึ้น" Google เมื่อสร้าง Chrome เขียนเป็นหลักใน C / C ++ แม้ว่าพวกเขาจะเป็นร้านค้ามืออาชีพมาก ดูเหมือนว่าพวกเขาเชื่อว่าประโยชน์ของ Java จะไม่เพิ่มขึ้นตามกำหนดเวลา


2

ด้วย Nashorn (The Javascript บน JVM แทนที่ Rhino) มาถึง JVM ในฐานะเป็นส่วนหนึ่งของ Java 8 สิ่งนี้สามารถทำได้อย่างชัดเจน อย่างไรก็ตามดังที่คนอื่น ๆ สังเกตเห็น - มีเว็บเบราว์เซอร์ที่ทันสมัยอยู่มากมายและดูเหมือนจะง่ายกว่าที่จะฝัง WebKit หากคุณต้องการโฮสต์ความสามารถในการเรียกดูภายในแอป Java :-)


1

คำตอบยอดนิยมในปัจจุบันเป็นเลิศ แต่ฉันจะเพิ่มที่ไม่จำเป็นต้อง recode บางสิ่งบางอย่างใน Java มีเครื่องมือที่แปลงแหล่งกำเนิดดั้งเดิมให้เป็นจาวา bytecodes ด้วยองศาที่แตกต่างของการทำงานร่วมกัน พวกเขามักจะสร้างล่ามแปลก ๆ หรือใช้ตัวแทนที่เหมือน JVM เช่น MIPS เป็นหินก้าว หนึ่งอาจแบ่งการพัฒนาเบราว์เซอร์ Java เป็นหลายขั้นตอนโดยการแปลงไลบรารี่ที่สำคัญเป็น Java bytecode รวมเข้ากับซอร์สเบราว์เซอร์ Java ที่บริสุทธิ์และค่อยๆใช้โค้ดไลบรารีมากขึ้นเป็นซอร์ส Java บริสุทธิ์

สิ่งนี้อนุญาตให้คุณมีทุกสิ่งภายใน JVM ที่ปลอดภัยยิ่งขึ้น อย่างไรก็ตามมันจะเป็นความเจ็บปวดในก้นมั่นใจประสิทธิภาพ มีแบบอย่างบางอย่างในการค่อย ๆ refactoring ขนาดใหญ่ pre-Agile / OOP แอปพลิเคชันแบบดั้งเดิม นอกจากนี้ส่วนประกอบบางส่วนมีการใช้งานจาวาที่ดีอยู่แล้วและสามารถใช้งานได้เช่นกันเพื่อลดแรงงาน


0

ฉันต้องบอกว่าฉันลำเอียงเล็กน้อยที่นี่ แต่ไปเลย ฉันไม่ชอบนักเทศน์ C / C ++ ฉันรู้ว่ามีแอปพลิเคชั่นที่ออกแบบมาอย่างดี แต่มันเป็นแค่เครื่องมือ A บ่อยครั้งที่ฉันได้รับความประทับใจหลาย ๆ คนพูดถึง C / C ++ สำหรับวิธีแก้ปัญหาที่ขาดไป http://www.paulgraham.com/avg.html ดู bulb paradox) ฉันพยายามที่จะดูข้อเท็จจริง: Java เป็นเร็ว C / C ++ แต่ต้องการหน่วยความจำเพิ่มเติม หรือให้ฉันใช้ถ้อยคำใหม่คุณสามารถเขียนโค้ดจาวาที่เร็วเท่ากับ C / C ++ แต่โปรแกรมนั้นจะใช้หน่วยความจำมากขึ้น ฉันหวังว่าเราจะเห็นด้วยกับเรื่องนี้

หากคุณดูที่ประสิทธิภาพการทำงานคุณสามารถสร้างโซลูชัน Java สำหรับปัญหาบางอย่าง (บอกว่า enterprise java) ค่อนข้างง่ายเมื่อเทียบกับโซลูชัน C ++ เว็บเบราว์เซอร์เป็นสิ่งที่แตกต่างอย่างสิ้นเชิง ฉันเห็นข้อกำหนดนายกเทศมนตรีสอง / สามข้อ:

  • ต้องสอดคล้องกับข้อกำหนดขนาดใหญ่, HTML, JavaScript และอื่น ๆ ซึ่งเกี่ยวข้องกับปัญหาเช่น 2D Drawing APIs หรือวิธีที่จะได้รับจากการเรียกใช้ระบบปฏิบัติการ (เป็นการวาดดั้งเดิม) ไปยังการแสดงข้อความหรือแบบอักษร (“ การเรนเดอร์”) ดูห้องสมุดเช่นไคโร (C) และความพยายามอื่น ๆ เช่น gezira (www.youtube.com/watch?v=P97O8osukZ0, https://github.com/damelang/gezira )
  • มันต้อง "รู้สึก" คล่องแคล่วซึ่งหมายความว่าการดำเนินการบางอย่างเท่านั้นที่มี ms ที่จะดำเนินการ
  • ต้องสร้างแนวคิด UI ซึ่งก่อให้เกิดประสบการณ์ที่ไม่เหมือนใครเพื่อแข่งขันใน 'สงครามเบราว์เซอร์' ในปัจจุบันซึ่งค่อนข้างท้าทาย

ในการสรุป: ใช่คุณทำได้คุณสามารถสร้างเบราว์เซอร์ในเกือบทุกภาษาการเขียนโปรแกรมที่มีผลลัพธ์เกือบเหมือนกันเมื่อเทียบกับการค้าขายในปัจจุบันของ C ++ แต่การทำเช่นนั้นคุณจะต้องใช้ความพยายามเป็นพิเศษ ฉันไม่รู้ว่า (ในล้าน) ฉันจะไม่อยากเดาด้วยซ้ำ บางทีเราอาจได้รับบรรทัดล่างนี้: คนไม่ชอบการเพิ่มประสิทธิภาพในภาษาระดับสูงหรืออาจจะถูกกว่าเพื่อรับคนที่ต้องการเพิ่มประสิทธิภาพใน C / C ++ เพราะมีจำนวนมาก (เมื่อเทียบกับผู้เชี่ยวชาญด้านภาษาอื่น ๆ ที่สามารถเพิ่มประสิทธิภาพใน ระดับที่คล้ายกัน)


2
ฉันอยากลงคะแนนเพราะคุณไม่ได้แบ่งคำตอบออกเป็นหลายย่อหน้า โปรดทำลายกำแพงข้อความด้วยช่องว่างสีขาว
Gilbert Le Blanc

2
ดีที่ฉันเขียนจากมือถือและนั่นเป็นสิ่งที่ดีที่สุดที่ฉันสามารถทำได้ด้วยอินเทอร์เฟซมือถือขอโทษ
AndreasScheinert

1
ไปแล็ปท็อปและแก้ไขมัน
AndreasScheinert

2
"หรือให้ฉันใช้ถ้อยคำใหม่คุณสามารถเขียนโค้ดจาวาที่เร็วเท่ากับ C / C ++ แต่โปรแกรมนั้นจะใช้หน่วยความจำมากขึ้นฉันหวังว่าเราจะเห็นด้วยกับเรื่องนี้" ไม่เราอย่างน้อยก็ไม่สามารถทำได้ในทุกกรณี Java จะไม่อนุญาตให้คุณใช้ตัวจัดการหน่วยความจำแบบกำหนดเองหลายตัวสำหรับรูปแบบการจัดสรรหน่วยความจำที่แตกต่างกัน คุณไม่สามารถปิดการตรวจสอบขอบเขตของอาเรย์เมื่อคุณตัดสินใจว่าไม่จำเป็นคุณเพียงแค่ต้องหวังว่า JIT จะรับรู้เมื่อไม่จำเป็น ปัญหาเหล่านี้ไม่ได้เกิดขึ้นในโปรแกรมส่วนใหญ่ แต่อาจมีความสำคัญในแอปพลิเคชันที่ต้องการประสิทธิภาพในระดับนาโนวินาทีทุกวินาที
Charles E. Grant

1
อาร์กิวเมนต์ที่ทำซ้ำของคุณที่นี่ว่าการรวบรวมขยะมีความเกี่ยวข้องกับประสิทธิภาพ ฉันเห็นด้วยกับที่ แต่มันเป็นเพียงแง่มุมเดียว
AndreasScheinert

0

มันจะเปรียบได้กับแนวคิดใน Windows 9x วันของการใช้งานซอฟต์แวร์ OpenGL เทียบกับ OpenGL ที่เร่งด้วยฮาร์ดแวร์ ปัญหาเกี่ยวกับการใช้ Java สำหรับบางอย่างเช่นเว็บเบราว์เซอร์คือคุณอาจใช้วงจรนาฬิกาพิเศษจำนวนมากในการทำบางสิ่งบางอย่างที่อาจเป็นไปได้ในภาษาที่เป็นเจ้าของภาษาน้อยลง นั่นคือแนวคิดของ OpenGL เช่นกัน - คุณสามารถทำงานให้เสร็จ แต่ต้องใช้เวลาในการประมวลผลมากขึ้น

เป็นไปได้ไหม ที่อาจเกิดขึ้น มันจะแข่งขันหรือไม่ ไม่น่าเป็นไปได้ - บางสิ่งในรหัสที่ขึ้นกับแพลตฟอร์มที่มีประสิทธิภาพสูงสุดนั้นมีแนวโน้มว่าจะมีข้อได้เปรียบด้านความเร็วที่สำคัญ

นี่เป็นเพียงการคาดเดา


-1

เกี่ยวกับความเป็นไปได้ของเว็บเบราว์เซอร์ Java ที่เขียนด้วยภาษาจาวาอาจมีการถามคำถามที่ผิด

ฉันไม่จำเป็นต้องคิดค้นล้อหมุนใหม่อีกครั้งและเขียนเบราว์เซอร์ที่มีคุณสมบัติครบถ้วนเมื่อส่วนใหญ่ที่มีอยู่นั้นว่างและมีคุณสมบัติมากมาย

ที่กล่าวว่าสิ่งที่ฉัน (เรา?) ควรจะมองหาคือ "สิ่ง" ดีพอที่จะอ่านหน้าเว็บโดยไม่ต้องอึทั้งหมด (โฆษณาวิดีโอวิดีโอ GIFs) ที่ได้รับการซ้อน

Google เป็นผู้กระทำความผิดหลักที่นี่พร้อมโฆษณาและสิ่งเหล่านี้ทั้งหมด

เพื่อที่อยู่ที่ฉันเขียนเบราว์เซอร์ Java ที่ใช้ Java HTMLEditorKit กับการใช้งาน HTML 3.2 และอ่านหน้าเว็บเป็นข้อความ, ตัดจาวาสคริปต์ทั้งหมด, รหัสสไตล์, ลิงค์, ข้อมูลเมตา โหลดซ้ำ) และพยายามแก้ไขอักขระพิเศษและลิงก์รูปภาพที่ตั้งค่าผ่าน javascripts ไฮเปอร์ลิงก์และการนำทางทำงาน สำหรับการอ่านเนื้อหาต่าง ๆ เช่น LA Times, NY Times, Il Corriere.it, ElPais.es, LeMonde.fr แม้แต่การค้นหา Bing และ Google ก็ยังผ่านมา ในที่สุดหรือเมื่อถูกถามฉันจะให้บริการฟรี มันไม่มาก แต่มันเป็นการเริ่มต้น


-4

แน่นอนมันสามารถทำได้ และมันก็สมเหตุสมผลเช่นกัน ไม่มีเบราว์เซอร์ที่รองรับมาตรฐาน w3c แบบเต็มเนื่องจากเหตุผลที่ไม่ชัดเจน ในส่วนของ css3 รองรับ บริษัท เบราว์เซอร์ไม่สนับสนุนมาตรฐานเช่นกัน -moz- * และ -webkit- * จะไม่เป็นส่วนหนึ่งของมาตรฐาน ดังนั้นเบราว์เซอร์ที่เป็นไปตามมาตรฐานแบบเต็มควรละเว้นพวกเขา หนึ่งในข้อผิดพลาดที่ใหญ่ที่สุดจาก w3c คือการขาดข้อกำหนดการแสดงผลโดยรวม ดังนั้นมาตรฐานเดียวกันกับหน้าเว็บจึงมีลักษณะแตกต่างกันไปในทุกเบราว์เซอร์ซึ่งเป็นฝันร้ายในการออกแบบกราฟิก ความล้มเหลวของ w3c อื่นคือการขาดความเร็ว การสนทนา 5 ปีและยังคงเป็นเพียงร่างมาตรฐานสำหรับ html5 หรือไม่ จากนั้นองค์กรของคุณกำลังปิดกั้นนวัตกรรมที่ร้ายแรง

ฉันคิดว่าเราควรเพิกเฉย w3c ละเว้นข้อกำหนดของพวกเขาและสร้างมาตรฐานชุมชนภายในครึ่งปีสำหรับภาษามาร์กอัปแอปพลิเคชันเว็บที่มีข้อกำหนดการแสดงผลและความปลอดภัยในใจ โปรดจำไว้ว่า HTML นั้นไม่เคยออกแบบมาสำหรับเว็บแอปพลิเคชันเนื่องจากไม่มีเว็บแอปพลิเคชันในขณะนั้น sgml ถูกใช้เป็นพื้นฐานสำหรับ HTML


1
หากนี่เป็นถ้อยคำที่ถากถางก็ไม่ได้เกิดขึ้นอย่างชัดเจนเพียงพอ คุณไม่ชี้ให้เห็นถึงข้อผิดพลาดที่หลีกเลี่ยงไม่ได้กับสิ่งที่คุณกำลังแนะนำ หากนี่ไม่ใช่การถากถางผมขอแนะนำให้คุณศึกษาวิธีการสร้างมาตรฐาน

ใช่มันเป็นการเสียดสี แต่ภาษาอังกฤษไม่ใช่ภาษาพื้นเมืองของฉันและไม่ใช่การเสียดสีเนื่องจากมาตรฐานที่ใช้เวลานานกว่า 5 ปีในการส่งมอบเฉพาะร่างจดหมายเท่านั้นที่ไม่สามารถใช้งานได้อย่างเต็มที่ตามมาตรฐานในทางปฏิบัติ
Vicky Ronnen

ไม่ได้อยู่ที่นี่และไม่ได้ตอบคำถาม ไม่เหน็บแนม
scravy
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.