Giúp code kiểm tra tên đường dẫn có tồn tại hay không ( có tiếng việt)

Liên hệ QC

minhtuan55

Thành viên bị đình chỉ hoạt động
Thành viên bị đình chỉ hoạt động
Tham gia
23/3/16
Bài viết
705
Được thích
52
Chào cả nhà GPE . Em cần 1 đoạn code để kiểm tra tên đường dẫn có tồn tại hay không. Nếu tồn tại = True , Ngược lại False. Em có thử vài code nhưng thấy chưa đúng như sau

Cụ thể ô A1 em có đường dẫn là:
C:\Users\Administrator\Desktop\Excel Hinh anh\Hinh anh\Mẫn tú\Những Mẫn.jpg

1551255689212.png


1. Code ở diễn đàn ( Bị lỗi khi đường dẫn rỗng và có tiếng việt Kết quả = #value )

Mã:
Private Function FileExists(fname) As Boolean
Dim x As String
x = Dir(fname)
If x <> "" Then FileExists = True _
     Else FileExists = False
End Function

2. Code ở diễn đàn ( Bị lỗi khi đường dẫn và tên File và có tiếng việt Kết quả = False )

Mã:
Private Function PathExists(pname) As Boolean
Dim x As String
On Error Resume Next

x = GetAttr(pname) And 0
If Err = 0 Then PathExists = True _
         Else PathExists = False
End Function

Mong cả nhà giúp em 1 đoạn code phải cực kỳ chính xác kể cả đường dẫn có tiềng việt hay tên tiếng việt Nếu có tồn tại thì True ngược lại False ( Kể cả Rổng cũng = False ). Xin đa tạ mong mọi người Hoan hỷ từ bi giúp chúng sanh. Xin cảm ơn +++N cảm ơn
 
Lần chỉnh sửa cuối:
...
Theo tôi nhớ là phải khai báo và viết lại hàm DirW cho trường hợp này mới dùng được nhưng tôi chưa viết bao giờ.
...
Thì ở bài #8 tôi đã đề nghị để cho thớt viết hàm bằng Xê Cọng Cọng mà hổng ai tin.
Mình ở đây chỉ tàn chiên da VBA cho nên chỉ nên viết cái code VBA gọi nó thôi.
 
Upvote 0
:) Chính xác là nó sẽ ra FALSE đối với tất cả các code dùng Dir hoặc FSO vì các hàm này không dùng được cho tên Folder hoặc File tiếng Việt có dấu (Non-English name).
Mọi người hiểu sai trong trường hợp của bạn minhtuan55. Mọi người cứ dựa vào cái "text" đường dẫn trong ô A1 trong Excel nên các hàm Dir, FSO đều chạy ra TRUE. Nếu nó là đường dẫn thực tế có folder là tiếng Việt và file jpg thật ngay trên máy của bạn thì nó sẽ báo FALSE ngay. Các bạn tự đổi file ảnh nào đó trên máy bạn rồi copy đường dẫn vô ô A1 đi sẽ thấy.

Lần đầu tiên trong đời nghe thấy nói là fso không chấp nhận unicode. Dir của VBA thì đúng rồi. Nhưng fso không phục vụ unicode?

Nói là một chuyện nhưng cần đưa ra ví dụ để chứng minh.

Vấn đề không nằm ở fso. Cũng không nằm ở unicode. Nó nằm ở sự khác biệt giữa 2 dạng unicode tham gia vào quá trình so sánh. Vấn đề là trong tiếng Việt có thể dùng unicode tổ hợp và unicode dựng sẵn. Nếu bạn khi tạo các thư mục trên đĩa bạn gõ bằng unicode dựng sẵn. Nhưng khi bạn gõ vào A1 lại dùng unicode tổ hợp thì dùng mắt bạn không thể phát hiện là 2 đường dẫn khác nhau. Nhưng chúng là khác nhau. Và lúc đó thì code vd.

Workbooks.Open <đường dẫn trong A1> chắc chắn sẽ có lỗi.

Lúc này không thể đổ tội cho Excel, VBA là không chấp nhận unicode vì nó chấp nhận, nó mở được các tập tin có đường dẫn unicode. Chỉ là phải cung cấp đường dẫn y hệt như trên đĩa. Y hệt ở đây không phải là "mặt mũi" như nhau mà là "nội dung". Cũng không thể đổ lỗi cho Dir, cho fso vì chúng không được dùng. Vậy thì đổ tội cho "ai"? Do đường dẫn trên đĩa là một dạng unicode còn nhập vào A1 lại là dạng unicode khác. Đó mới chính là nguyên nhân. Nếu muốn đổ lỗi cho fso thì phải đưa ra chứng cứ.

Tôi đính kèm ví du.

Trong tập tin có A1 = "đây là thư mục tiếng Việt nhé\Excel Hinh anh\Hinh anh\Mẫn tú\Những Mẫn.jpg".

Tại sao không có đoạn đầu? Đơn giản vì mỗi người tải tập tin của tôi về và giải nén thì sẽ có đoạn đầu của đường dẫn khác nhau. Đoạn đầu này code sẽ lấy từ ThisWorkbook.Path để thêm vào và tạo đường dẫn hoàn chỉnh.

ThisWorkbook.Path & "\" & Range("A1").Value chắc chắn tồn tại, vì A1 được tôi copy và dán bằng tay từ thanh địa chỉ của Explorer.

Code sẽ convert A1 sang unicode dựng sẵn. Tức bất luận A1 là unicode tổ hợp hay unicode dựng sẵn thì kết quả convert luôn luôn là unicode dựng sẵn. Kết quả này code sẽ nhập vào A2.

Khi chạy code test thì tôi có thông báo:

- "Tap tin A1 ton tai"
- "Tap tin A2 khong ton tai"

Điều này dễ hiểu vì tuy 2 đường dẫn nhìn như nhau nhưng "lõi" khác nhau. Len(A1) = 79. Len(A2) = 74.

Nếu bạn cho là fso không phục vụ unicode thì hãy đưa ra ví dụ cho người khác kiểm tra.

Nguyên nhân không nằm ở fso. Nguyên nhân ở chỗ là trong tiếng Việt có thể dùng unicode tổ hợp và dựng sẵn. Vì thế 2 đoạn text là y hệt nhau về mặt văn bản nhưng có thể khác nhau khi ghi trên đĩa, vd. trong tập tin TXT, khi dùng trong vd. Excel. Vì VBA không nhìn bằng "mắt" mà nó "cân đo đong đếm" nội dung, "lõi".

Cũng có thể khắc phục trường hợp khi đường dẫn trên đĩa và đường dẫn cần kiểm tra là 2 loại unicode khác nhau, nhưng code không ngắn gọn được. Có thể có nhiều ý tưởng. Nếu là tôi thì cho tới khi nghĩ ra cái hay hơn thì tôi sẽ dùng thuật toán như sau:
0. Code convert A1 sang unicode dựng sẵn -> ghi kết quả vào biến A1dungsan.

1. Code sẽ xác định thư mục cuối cùng trong đường dẫn A1 mà đoạn đầu tới nó chỉ chứa ký tự ANSI. Trong tập tin vd. thì đó là thư mục mà con của nó là thư mục "đây là thư mục tiếng Việt nhé". Ta gọi đó là startDir. Vd. startDir = "C:\Users\Administrator\Desktop\Excel Hinh anh\Hinh anh" (đường dẫn tới ảnh là "C:\Users\Administrator\Desktop\Excel Hinh anh\Hinh anh\đây là thư mục tiếng Việt nhé\Excel Hinh anh\Hinh anh\Mẫn tú\Những Mẫn.jpg")

2. Code sẽ tìm và liệt kê tất cả các tập tin có trong startDir và các thư mục con, vd. nhập vào listFiles. Mục đích của điểm 1 để listFiles ngắn nhất. Bởi nếu tìm trong "C:\", trong "C:\Users", trong "C:\Users\Administrator" ... thì listFiles sẽ dài. Mà thực ra ta chỉ cần các tập tin trong startDir, vì các tập tin vd. trong "C:\Users\Administrator" thì đâu cần quan tâm.

3. Code sẽ duyệt từng đường dẫn trong listFiles -> convert sang unicode dựng sẵn -> so sánh với A1dungsan. Nếu kết quả là bằng nhau thì hàm trả về TRUE và đồng thời ghi vào B1 giá trị của đường dẫn đang xét lấy từ listFiles (tức dạng đường dẫn trên đĩa). Hoặc ghi đường dẫn thực trên đĩa vào tham số được truyền bởi ByRef. Và code kết thúc.
Nếu code duyệt hết listFiles (vòng FOR) mà không có kết quả so sánh nào bằng nhau thì dĩ nhiên là đường dẫn không tồn tại.
 

File đính kèm

Lần chỉnh sửa cuối:
Upvote 0
Thì ở bài #8 tôi đã đề nghị để cho thớt viết hàm bằng Xê Cọng Cọng mà hổng ai tin.
Viết trong Xê Cọng Cọng hay Delphi hay gì thì cũng thế thôi.

Vấn đề không nằm ở FSO. Nếu FSO trả về FALSE (TRUE) thì DirW cũng sẽ trả về FALSE (TRUE).

Nếu ai còn nghi ngờ thì hãy tải tập tin của tôi ở bài #23 về giải nén -> mở tập tin -> thêm Module2 với nội dung
Mã:
Option Explicit

Private Const MAX_PATH = 260

Private Type FILETIME
    dwLowDateTime As Long
    dwHighDateTime As Long
End Type
Public Type WIN32_FIND_DATA
    dwFileAttributes As Long
    ftCreationTime As FILETIME
    ftLastAccessTime As FILETIME
    ftLastWriteTime As FILETIME
    nFileSizeHigh As Long
    nFileSizeLow As Long
    dwReserved0 As Long
    dwReserved1 As Long
    cFileName As String * MAX_PATH
    cAlternate As String * 14
End Type
Private Type FIND_DATAW
    dwFileAttributes As Long
    ftCreationTime As FILETIME
    ftLastAccessTime As FILETIME
    ftLastWriteTime As FILETIME
    nFileSizeHigh As Long
    nFileSizeLow As Long
    dwReserved0 As Long
    dwReserved1 As Long
    cFileName((MAX_PATH * 2) - 1) As Byte ' 519
    cAlternateFileName(27) As Byte
End Type
'
Private Declare Function GetLongPathNameW Lib "kernel32.dll" (ByRef lpszShortPath As Byte, ByRef lpszLongPath As Byte, ByVal cchBuffer As Long) As Long
Private Declare Function FindFirstFileW Lib "kernel32" (ByVal lpFileName As Long, ByRef lpFindFileData As FIND_DATAW) As Long
Private Declare Function FindNextFileW Lib "kernel32" (ByVal hFindFile As Long, ByRef lpFindFileData As FIND_DATAW) As Long
Private Declare Function FindFirstFile Lib "kernel32" Alias "FindFirstFileA" (ByVal lpFileName As String, lpFindFileData As WIN32_FIND_DATA) As Long
Private Declare Function FindNextFile Lib "kernel32" Alias "FindNextFileA" (ByVal hFindFile As Long, lpFindFileData As WIN32_FIND_DATA) As Long
Private Declare Function FindClose Lib "kernel32" (ByVal hFindFile As Long) As Long
'
Public DirExFindInfo As WIN32_FIND_DATA
Public DirWFindInfo As FIND_DATAW
'


Public Function DirW(Optional sParam As String) As Boolean
   
    Static hSearch As Long
    Dim iRet As Long
    Dim s As String
    Dim sFileNm As String
   
    If Len(sParam) Then
        iRet = FindClose(hSearch)
        hSearch = FindFirstFileW(StrPtr(sParam), DirWFindInfo)
        If hSearch <> 0 And hSearch <> -1 Then
            s = DirWFindInfo.cFileName
            sFileNm = Left$(s, InStr(s, Chr$(0)) - 1)
            Debug.Print sFileNm
       
            DirW = True
            Debug.Print "Dir:" & DirW
        End If
        Exit Function
    Else
        DirW = False
        Debug.Print "Dir:" & DirW
    End If
End Function

Sub FSOandDirW1()
    MsgBox FileExists(ThisWorkbook.Path & "\" & Range("A1").Value)
    MsgBox DirW(ThisWorkbook.Path & "\" & Range("A1").Value)
End Sub

Sub FSOandDirW2()
    MsgBox FileExists(ThisWorkbook.Path & "\" & Range("A2").Value)
    MsgBox DirW(ThisWorkbook.Path & "\" & Range("A2").Value)
End Sub

Chạy FSOandDirW1 sẽ có 2 lần TRUE. Chạy FSOandDirW2 sẽ có 2 lần FALSE. Đơn giản vì vấn đề không nằm ở FSO hay DirW mà ở chỗ:
1. Trong trường hợp FSOandDirW1 thì đường dẫn trên đĩa và A1 là cùng dạng unicode (tổ hợp hoặc tổ hợp và dựng sẵn hỗn hợp)

2. FSOandDirW2 thì đường dẫn trên đĩa là tổ hợp hoặc tổ hợp và dựng sẵn hỗn hợp còn trong A2 là unicode dựng sẵn.

Nhắc lại:
1. Vấn đề nằm ở sự khác biệt giữa 2 dạng unicode. Khi "nhìn bằng mắt" thấy đường dẫn "chắc chắn" phải tồn tại mà FileExist lại trả về FALSE (lúc này DirW cũng sẽ trả về FALSE) thì có nghĩa là đường dẫn trên đĩa và đường dẫn trong ô trên trang tính ở 2 dạng unicode khác nhau.

2. Nếu FileExist trả về TRUE thì chắc chắn DirW sẽ trả về TRUE. Nếu FileExists trả về FALSE thì DirW chắc chắn trả về FALSE. Nếu vậy thì viết một đống code DirW làm gì?

3. Nếu ai đó nhìn vào A1 thấy"chắc chắn" đường dẫn A1 phải tồn tại nhưng FileExists lại trả về FALSE thì tôi đề nghị: Mở thư mục có tập tin mà đường dẫn "nhìn thấy" ở A1 -> copy đường dẫn tới thư mục từ thanh địa chỉ của Explorer -> về Excel -> chọn A1 -> Ctrl + V -> vào lại thư mục có tập tin -> phải chuột trên tập tin -> Rename -> Ctrl + C -> về lại Excel -> chọn A1 -> click cuối nội dung trong A1 -> gõ ký tự \ -> Ctrl + V.
Sau những thao tác như trên thì chắc chắn đường dẫn trên đĩa và trong A1 cùng có 1 dạng unicode. Lúc này thì FileExists chắc chắn sẽ trả về TRUE.
 
Upvote 0
@batman1 Vậy làm sao để Fso nó chấp nhận đường dẫn tại A2 Anh nhỉ ??!
 
Upvote 0
@batman1 Vậy làm sao để Fso nó chấp nhận đường dẫn tại A2 Anh nhỉ ??!
Dùng FSO, DirW hay gì khác không quan trọng. Muốn chấp nhận đường dẫn A2, chỉ khác A1 ở dạng unicode, thì tôi đã đưa ra tạm 1 thuật toán rồi. Code để làm từng điểm của thuật toán đó không khó và trên GPE cũng có nhiều.
Cũng có thể khắc phục trường hợp khi đường dẫn trên đĩa và đường dẫn cần kiểm tra là 2 loại unicode khác nhau, nhưng code không ngắn gọn được. Có thể có nhiều ý tưởng. Nếu là tôi thì cho tới khi nghĩ ra cái hay hơn thì tôi sẽ dùng thuật toán như sau:
0. Code convert A1 sang unicode dựng sẵn -> ghi kết quả vào biến A1dungsan.

1. Code sẽ xác định thư mục cuối cùng trong đường dẫn A1 mà đoạn đầu tới nó chỉ chứa ký tự ANSI. Trong tập tin vd. thì đó là thư mục mà con của nó là thư mục "đây là thư mục tiếng Việt nhé". Ta gọi đó là startDir. Vd. startDir = "C:\Users\Administrator\Desktop\Excel Hinh anh\Hinh anh" (đường dẫn tới ảnh là "C:\Users\Administrator\Desktop\Excel Hinh anh\Hinh anh\đây là thư mục tiếng Việt nhé\Excel Hinh anh\Hinh anh\Mẫn tú\Những Mẫn.jpg")

2. Code sẽ tìm và liệt kê tất cả các tập tin có trong startDir và các thư mục con, vd. nhập vào listFiles. Mục đích của điểm 1 để listFiles ngắn nhất. Bởi nếu tìm trong "C:\", trong "C:\Users", trong "C:\Users\Administrator" ... thì listFiles sẽ dài. Mà thực ra ta chỉ cần các tập tin trong startDir, vì các tập tin vd. trong "C:\Users\Administrator" thì đâu cần quan tâm.

3. Code sẽ duyệt từng đường dẫn trong listFiles -> convert sang unicode dựng sẵn -> so sánh với A1dungsan. Nếu kết quả là bằng nhau thì hàm trả về TRUE và đồng thời ghi vào B1 giá trị của đường dẫn đang xét lấy từ listFiles (tức dạng đường dẫn trên đĩa). Hoặc ghi đường dẫn thực trên đĩa vào tham số được truyền bởi ByRef. Và code kết thúc.
Nếu code duyệt hết listFiles (vòng FOR) mà không có kết quả so sánh nào bằng nhau thì dĩ nhiên là đường dẫn không tồn tại.

Suy nghĩ một chút tôi tìm ra cách tối ưu hơn. Liệt kê listFiles sẽ tốn điện nước hơn. Chỉ việc kiểm tra từng thư mục liên tiếp xem có không, và nếu tất cả các thư mục liên tiếp đều có thì kiểm tra xem tập tin có không. Thế thôi.
 
Lần chỉnh sửa cuối:
Upvote 0
Viết trong Xê Cọng Cọng hay Delphi hay gì thì cũng thế thôi.
...
Khác nhau xa lắm bác ơi.
Ở một số bài trước đây, thớt đã tự xưng mình là chuyên gia Xê Cọng Cọng, và chỉ không biết hoặc không có thì giờ viết VBA thôi.
Mấy cái hàm API của Windows thì cũng có nhiều cái viết từ Xê Cọng Cọng. Điển hình là nếu thớt viết bằng ngôn ngữ này thì mớ pointers kia cũng có cả một thư viện (Xê Cọng Cọng gọi là header).
Như vậy, giải pháp hữu hiệu nhất thớt cứ việc tự viết hàm, tự test cho thật vừa ý rồi đưa lên đây bà con sẽ giúp cho cái phần kết nối vào VBA.
Về sau này bà con cứ việc lấy cái Dll ấy mà xài. Quả là dịp tốt để thớt tự tạo cho mình chút "công đức" thực tiễn thay vì phải mua chiếc mada giấy mà đốt cúng.

Thớt không hề đề cập đến Delphi cho nên tôi cũng không nghĩ đến Delphi.
 
Upvote 0
quả thực mắt thường nhìn a1 như a2 mà khi len(a1) thì khác a2 .... nhức đầu ... lần đầu Mạnh biết
Nghe chừng còn tốn giấy mực đây :p:p
 
Upvote 0
Thank bác. bác viết dài quá huhu sám hối. Túm lại là bác cũng chưa hiễu ý của em. Em xin nói lại 1 lần cuối cùng
File excel nằm tại đường dẫn C:\Users\Administrator\Desktop\Excel Hinh anh\Hinh anh.xlsb .
Tại ô A1 ( của file Hinh anh.xlsb ) có giá trị là
C:\Users\Administrator\Desktop\Excel Hinh anh\Hinh anh\Mẫn tú\Những Mẫn.jpg
Ý em là Làm sao để kiểm tra đường dẫn tại ô A1 có tồn tại hay không ( sau nay lở đâu người ta đổi tên file ảnh hay đổi tên các thư mục thì là mục địch là nếu nó tồn tại thì TRUE còn Ngược lại là FAlse . Còn chuyện TRUE hay False thì em áp dụng chuyện khác của em, Em chỉ hỏi 5% vấn đề của thôi

View attachment 212941
Bài đã được tự động gộp:



Bạn biết thì giúp. Không giúp thì đừng có nói xấu làm gì. Đức phật dạy bạn làm sao. Phải hoan hỹ, từ bi, giúp đở mọi người. Bạn không hơn ai đâu đừng có ***** người ta. Tôi hỏi ớ đây chỉ là 5% vấn đề của tôi thôi. Còn 95% tôi tự sử bằng C++ nên ai từ bi thì giúp thì tôi cầu công đức gia hộ Vô lượng kiếp. Còn anh ghét thì Nhân quả tự giái quyết. Túm váy lại 1 câu ngắn gọn dành cho Bạn là
=if( And( Biết code giúp tôi, Phải hoan hỷ )) , Tôi chân thành cảm ơn và chúc bạn 1 ngày rực rỡ lên BMW hay Mec hay Audi, Thôi đừng bình luận làm chi ) Bạn thử Enter xem bạn TRUE hay FALSE của hàm này. tự tìm đáp án đi nhé.
Nếu thế bạn nên sám hôi trước đi. Nhờ người khác mà còn tham sân nữa.
Vì viết C++ bài này ngắn gọn và đẹp code hơn nhiều cái việc đưa vào đường vòng excel vba
 
Lần chỉnh sửa cuối:
Upvote 0
Nếu thế bạn nên sám hôi trước đi. Nhờ người khác mà còn tham sân nữa.
Vì viết C++ bài này ngắn gọn và đẹp code hơn nhiều cái việc đưa vào đường vòng excel vba
Thì lô gic tích đức nó vậy đó.
Thớt cung cấp cái Dll cho bà con cùng dùng. Thế là thớt đầy công đức.
Bạn nào đó đó viết VBA cho thớt gọi cái Dll kia. Thế là bạn ấy thêm công đức.
Tôi nặn óc nghĩ ra cách cho hai người tụ đức. Chắc là sẽ cấy đức, nhưng mà tôi sợ có đức lắm, ai muốn tôi nhường luôn.
 
Upvote 0
Lần đầu tiên trong đời nghe thấy nói là fso không chấp nhận unicode. Dir của VBA thì đúng rồi. Nhưng fso không phục vụ unicode?

Nói là một chuyện nhưng cần đưa ra ví dụ để chứng minh.

Vấn đề không nằm ở fso. Cũng không nằm ở unicode. Nó nằm ở sự khác biệt giữa 2 dạng unicode tham gia vào quá trình so sánh. Vấn đề là trong tiếng Việt có thể dùng unicode tổ hợp và unicode dựng sẵn. Nếu bạn khi tạo các thư mục trên đĩa bạn gõ bằng unicode dựng sẵn. Nhưng khi bạn gõ vào A1 lại dùng unicode tổ hợp thì dùng mắt bạn không thể phát hiện là 2 đường dẫn khác nhau. Nhưng chúng là khác nhau. Và lúc đó thì code vd.

:) Đúng là tôi đã xớn xác không kiểm tra tới trường hợp dùng bộ mã nào để gõ tiếng Việt nên phán sai như trên. Xin lỗi mọi người vì thông tin kết luận sai ở post trước nhé.
Túm lại là bây giờ đã xác định được nguyên nhân gốc rễ vấn đề này là sự khác nhau trong việc thể hiện tiếng Việt cho đường dẫn file. Đây là kinh nghiệm cần để ý khi viết ứng dụng. Để khắc phục trường hợp này thì ứng dụng tôi thường không để người dùng tạo folder/ file mà chỉ để người dùng copy file ảnh/ file văn bản mà họ muốn vào thư mục mặc định của ứng dụng + đổi tên file theo qui ước luôn. Khi đó tên file cũng đồng bộ (không dùng tiếng Việt có dấu) và cũng đỡ phải code cho việc nhận dạng sai tiếng Việt :).
 
Upvote 0
:)Đúng là tôi đã xớn xác không kiểm tra tới trường hợp dùng bộ mã nào để gõ tiếng Việt nên phán sai như trên. Xin lỗi mọi người vì thông tin kết luận sai ở post trước nhé.
Túm lại là bây giờ đã xác định được nguyên nhân gốc rễ vấn đề này là sự khác nhau trong việc thể hiện tiếng Việt cho đường dẫn file. Đây là kinh nghiệm cần để ý khi viết ứng dụng. Để khắc phục trường hợp này thì ứng dụng tôi thường không để người dùng tạo folder/ file mà chỉ để người dùng copy file ảnh/ file văn bản mà họ muốn vào thư mục mặc định của ứng dụng + đổi tên file theo qui ước luôn. Khi đó tên file cũng đồng bộ (không dùng tiếng Việt có dấu) và cũng đỡ phải code cho việc nhận dạng sai tiếng Việt :).
Như tôi đã viết
Dính đến tiếng việt có dấu thì là lại dính bảng mã bác ah, có khi tên file hay đường dẫn ngoài 1 bảng mã , dữ liệu trong A1 lại là sử dụng bảng mã (tiếng việt) khác thì so sánh FALSE là chính xác rồi. Nhưng anh ta có thử thế nào thì trời biết , anh ta biết, kêu oai oái mà không có thông tin chứng cớ, cứ code sai rồi, #VALUE rồi thì ai mà biết

Tiếng việt có dấu là phải quan tâm đã gõ bảng mã nào
 
Upvote 0
quả thực mắt thường nhìn a1 như a2 mà khi len(a1) thì khác a2 .... nhức đầu ... lần đầu Mạnh biết
Nghe chừng còn tốn giấy mực đây :p:p
Chưa hoa mắt đâu, đó mới là 2 bảng mã Unicode tổ hợp và dựng sẵn, .... tiếng việt còn nhiều bảng mã khác nữa tồn tại từ xưa như TCVN3, VNI, Viet.., BK.... vv gì đó không nhớ hết được,
Những tưởng chúng ta thống nhất được thành bảng mã chung nhất là unicode ấy vậy lại để ra bảng mã unicode tổ hợp và dựng sẵn... Đó là công nghệ thông tin (nhanh chuẩn như điện) ... vấn đề thực tế thì thôi rồi .... Thế nên mãi cứ hỏi tại sao dân ta đôi khi buộc phải lái xe lên lề ....
 
Upvote 0
Chưa hoa mắt đâu, đó mới là 2 bảng mã Unicode tổ hợp và dựng sẵn, .... tiếng việt còn nhiều bảng mã khác nữa tồn tại từ xưa như TCVN3, VNI, Viet.., BK.... vv gì đó không nhớ hết được,
Những tưởng chúng ta thống nhất được thành bảng mã chung nhất là unicode ấy vậy lại để ra bảng mã unicode tổ hợp và dựng sẵn... Đó là công nghệ thông tin (nhanh chuẩn như điện) ... vấn đề thực tế thì thôi rồi .... Thế nên mãi cứ hỏi tại sao dân ta đôi khi buộc phải lái xe lên lề ....
THÌ TỪ XƯA tới nay nó vẫn thế ... ngay cái vụ Msgbox đó đúng trên máy này sai trên máy khác
nếu nhớ ko lộn khoãng 2 năm trước Mạnh có nêu ở thớt nào đó có người phản bác lại mạnh nói bạy .... nhưng thức tế nó vẫn cứ đúng trên máy này sai trên máy khác vậy ( có điều khả năng của mạnh thấy sao nói vậy chứ chưa đủ trình để phân tích nó tại sao ???)

Tại Mạnh ngày nào cũng thế rất rảnh nhiều lúc ngồi chơi với máy tính cả ngày nên hay quậy link tinh nhiều lúc thấy đầy code trên này viết nó trúng ở khúc nay sai ở khúc khác mặc dù hàm đó viết rất bao quát vv... nhưng ròi kệ nó người dùng nếu thật sự đam mê khắc sẻ tìm ra ... còn cứ ngồi đó hóng thì cứ hóng thui

nói chung tâm sự vậy chứ tùy trường hợp Mạnh vẫn hướng dẫn nhiệt tình-0-0-0-===\.
 
Lần chỉnh sửa cuối:
Upvote 0
quả thực mắt thường nhìn a1 như a2 mà khi len(a1) thì khác a2 .... nhức đầu ... lần đầu Mạnh biết
Nghe chừng còn tốn giấy mực đây :p:p
Tôi tin chắc là bạn đã từng gặp chứ không phải lần đầu. Có thể bạn gặp cái khác nhưng về bản chất nó như trường hợp này.

Trên GPE chắc chắn bạn đã từng gặp người ta kêu trời, người ta khóc hu hu vì: "Tại sao trong cột A rõ ràng nhìn thấy có 10 "Đỗ Mai Diễm XYZ" mà COUNTIF trả về 8?", "Tại sao trong cột B rõ ràng nhìn thấy có 10 "Cá lóc" mà COUNTIF trả về 7?"

Đường dẫn, họ tên, tên hàng là những phạm trù khác nhau nhưng 3 vấn đề cùng 1 bản chất, có cùng nguyên nhân. Đó là: nhiều đoạn văn bản tuy nhìn thì y hệt nhau nhưng "lõi" không y hệt nhau do một số chứa unicode dựng sẵn, một số chứa unicode tổ hợp, số còn lại chứa vừa dựng sẵn vừa tổ hợp lẫn lộn.
 
Upvote 0
Chưa hoa mắt đâu, đó mới là 2 bảng mã Unicode tổ hợp và dựng sẵn, .... tiếng việt còn nhiều bảng mã khác nữa tồn tại từ xưa như TCVN3, VNI, Viet.., BK.... vv gì đó không nhớ hết được,
Những tưởng chúng ta thống nhất được thành bảng mã chung nhất là unicode ấy vậy lại để ra bảng mã unicode tổ hợp và dựng sẵn... Đó là công nghệ thông tin (nhanh chuẩn như điện) ... vấn đề thực tế thì thôi rồi .... Thế nên mãi cứ hỏi tại sao dân ta đôi khi buộc phải lái xe lên lề ....
Không phải do Việt Nam đâu. Đừng nói thế mà tội cho Việt Nam, thương Việt Nam lắm :D

Khái niệm unicode tổ hợp và dựng sẵn có ngay trong Windows.

Nếu nói về bảng mã qui định để dùng trong các cơ quan nhà nước khi viết văn bản chính thức thì Việt Nam có TCVN 6909. Theo TCVN 6909 thì tất cả các ký tự đều là unicode dựng sẵn dùng 2 bai để mã mỗi ký tự.

https://vanbanphapluat.co/tcvn-6909-2001-cong-nghe-thong-tin-bo-ma-ki-tu-tieng-viet-16-bit

Lấy vd. ký tự "à".

1. Hình TCVN 6909.jpg cho thấy tiêu chuẩn qui định ký tự "à" có điểm mã là &H00E0 = 224, dùng 2 bai là &H00 và &HE0 để mã. Đây là "à" dựng sẵn.

Tải "a huyen dung san.txt" về và mở bằng Hex Editor sẽ thấy FF FE E0 00. Trừ 2 bai "signature" FF FE thông báo là văn bản được mã bằng unicode thì còn lại 2 bai 00 E0 (trong Windows mặc định thì bai low ghi trước bai high ghi sau, word (kiểu WORD trong Delphi, Integer trong VBA) low ghi trước word high ghi sau) chính là "à" trong TCVN 6909. "à" trong trường hợp này dùng 2 bai để mã.

2. Tải tập tin "a huyen to hop.txt" về và mở xem thì cũng nhìn thấy "à". Tôi đã làm thế nào? Tôi mở notepad của Windows -> chọn bàn phím Vietnamese của Windows (tôi không dùng Unikey) -> nhấn phím a -> nhìn thấy hiện "a" -> nhấn tiếp phím 5 -> "a" đổi thành "à" (nếu muốn có 5 thì phải nhấn Alt phải + phím 5) -> chọn ghi với tên "a huyen to hop.txt" và lựa chọn mã Unicode.

Khi mở "a huyen to hop.txt" bằng Hex Editor thì sẽ thấy FF FE 61 00 00 03. 2 bai đầu là &H0061 chính là điểm mã của ký tự "a". 2 bai sau là &H0300 chính là điểm mã của dấu huyền trong bảng mà Unicode (trong bảng mã Unicode mỗi ký tự đều có tên. Ký tự có điểm mã 0300, tức dấu huyền theo TCVN 8909, có tên là Combining grave accent). Thế thì văn bản có 2 ký tự này lẽ ra phải được hiển thị với 2 ký tự liền nhau là a và ̀ mới phải chứ nhỉ? Nhưng khi văn bản được hiển thị bởi trình soạn thảo văn bản thì do ký tự ̀ là dấu thanh nên 2 ký tự được "ghép" thành 1 (đưa ký tự Combining grave accent lên trên ký tự "a". Thực ra phông chữ được chọn phải có chứa ký tự "à" (glyph) thì mới có chuyện "ghép", tức thay 2 ký tự kia bằng ký tự có trong phông chữ hiện hành.). Và ta có "à". "à" trong trường hợp này dùng tới 4 bai để mã.

Lỗi không do TCVN 6909. Lỗi phát sinh do có cách để gõ ra unicode tổ hợp nên mỗi người gõ một kiểu. Như tôi đã gõ trong notepad bằng bàn phím Viernamese của Windows (sẽ luôn là unicode tổ hợp). Nhưng nếu gõ dùng Unikey với bảng mã Unicode + telex và gõ "af" thì cũng có "à" nhưng đây là unicode dựng sẵn y như trong TCVN 6909. Khi ghi ra thì chỉ có FF FE E0 00. Tức "à" đươc mã bằng 2 bai.

TCVN6909-1.JPG

TCVN6909.JPG
 

File đính kèm

Lần chỉnh sửa cuối:
Upvote 0
Túm váy lại 1 câu ngắn gọn dành cho Bạn là
=if( And( Biết code giúp tôi, Phải hoan hỷ )) , Tôi chân thành cảm ơn và chúc bạn 1 ngày rực rỡ lên BMW hay Mec hay Audi, Thôi đừng bình luận làm chi ) Bạn thử Enter xem bạn TRUE hay FALSE của hàm này. tự tìm đáp án đi nhé.

Theo tôi chả TRUE hay FALSE. Excel không chấp nhận công thức đó do thừa 1 ")" sau "hỷ" :D
 
Upvote 0
Theo tôi chả TRUE hay FALSE. Excel không chấp nhận công thức đó do thừa 1 ")" sau "hỷ" :D
Tôi xoá bớt một ")" mà Enter nó cũng chả chịu ra.
Nó báo là:
Nếu ông code giúp và phải hoan hỉ thì vẫn không có ngày nào lên Bê Em hay Méc đâu, tự dối lòng nghe lời chúc chi cho mệt.
Gú gồ lý do thì gú gồ nó hỏi ngược lại là:
Hồi nào đến giờ có thấy một thằng cốt đơ nào kiếm đủ tiền mua Méc xê đăng bạc tỷ (*) chưa?

Chú: Méc xê đăng bạc tỷ thì mới mơ. Chứ Méc xe đò tôi cỡi thường xuyên đi lục tỉnh, khôgn cần phải mơ.
 
Upvote 0
Không phải do Việt Nam đâu. Đừng nói thế mà tội cho Việt Nam, thương Việt Nam lắm :D

Khái niệm unicode tổ hợp và dựng sẵn có ngay trong Windows.

Nếu nói về bảng mã qui định để dùng trong các cơ quan nhà nước khi viết văn bản chính thức thì Việt Nam có TCVN 6909. Theo TCVN 6909 thì tất cả các ký tự đều là unicode dựng sẵn dùng 2 bai để mã mỗi ký tự.

https://vanbanphapluat.co/tcvn-6909-2001-cong-nghe-thong-tin-bo-ma-ki-tu-tieng-viet-16-bit

Lấy vd. ký tự "à".

1. Hình TCVN 6909.jpg cho thấy tiêu chuẩn qui định ký tự "à" có điểm mã là &H00E0 = 224, dùng 2 bai là &H00 và &HE0 để mã. Đây là "à" dựng sẵn.

Tải "a huyen dung san.txt" về và mở bằng Hex Editor sẽ thấy FF FE E0 00. Trừ 2 bai "signature" FF FE thông báo là văn bản được mã bằng unicode thì còn lại 2 bai 00 E0 (trong Windows mặc định thì bai low ghi trước bai high ghi sau, word (kiểu WORD trong Delphi, Integer trong VBA) low ghi trước word high ghi sau) chính là "à" trong TCVN 6909. "à" trong trường hợp này dùng 2 bai để mã.

2. Tải tập tin "a huyen to hop.txt" về và mở xem thì cũng nhìn thấy "à". Tôi đã làm thế nào? Tôi mở notepad của Windows -> chọn bàn phím Vietnamese của Windows (tôi không dùng Unikey) -> nhấn phím a -> nhìn thấy hiện "a" -> nhấn tiếp phím 5 -> "a" đổi thành "à" (nếu muốn có 5 thì phải nhấn Alt phải + phím 5) -> chọn ghi với tên "a huyen to hop.txt" và lựa chọn mã Unicode.

Khi mở "a huyen to hop.txt" bằng Hex Editor thì sẽ thấy FF FE 61 00 00 03. 2 bai đầu là &H0061 chính là điểm mã của ký tự "a". 2 bai sau là &H0300 chính là điểm mã của dấu huyền trong bảng mà Unicode (trong bảng mã Unicode mỗi ký tự đều có tên. Ký tự có điểm mã 0300, tức dấu huyền theo TCVN 8909, có tên là Combining grave accent). Thế thì văn bản có 2 ký tự này lẽ ra phải được hiển thị với 2 ký tự liền nhau là a và ̀ mới phải chứ nhỉ? Nhưng khi văn bản được hiển thị bởi trình soạn thảo văn bản thì do ký tự ̀ là dấu thanh nên 2 ký tự được "ghép" thành 1 (đưa ký tự Combining grave accent lên trên ký tự "a". Thực ra phông chữ được chọn phải có chứa ký tự "à" (glyph) thì mới có chuyện "ghép", tức thay 2 ký tự kia bằng ký tự có trong phông chữ hiện hành.). Và ta có "à". "à" trong trường hợp này dùng tới 4 bai để mã.

Lỗi không do TCVN 6909. Lỗi phát sinh do có cách để gõ ra unicode tổ hợp nên mỗi người gõ một kiểu. Như tôi đã gõ trong notepad bằng bàn phím Viernamese của Windows (sẽ luôn là unicode tổ hợp). Nhưng nếu gõ dùng Unikey với bảng mã Unicode + telex và gõ "af" thì cũng có "à" nhưng đây là unicode dựng sẵn y như trong TCVN 6909. Khi ghi ra thì chỉ có FF FE E0 00. Tức "à" đươc mã bằng 2 bai.

View attachment 213005

View attachment 213006
trời giờ em mới biết cái dụ này, máy bữa trước em làm cái bảng tổng hợp tài sản dùng counif đếm thì bằng 1 mà dùng mắt dò thì nó có tới 2 danh mục hichichic
 
Upvote 0
Web KT

Bài viết mới nhất

Back
Top Bottom